答案显然是肯定的，只要进行修改，就不可避免会有 bug 的隐患。目前最有效的方案就是人工 review+测试保护，对任何修改都是适用的。

annotation processor 用得很广泛了，lombok 实际上也是 hack 了一些东西。。类似功能的还有 Autovalue 之类一大堆工具（ java 程序员为了少写代码做了很多工作）。。

仅仅是用到 javac 的 api 的话，阿里的 arthas 基本上算是个百科全书了。。

@18258226728 #26 根据参数类型划分接口么。。。我们的思路是根据功能划分接口。

@yanyueio #15
@daveze #12
@Freeego #11
@neptuno #10
@lurenw #9

一个接口的原因是希望这部分逻辑对客户端隐藏，客户端也只需要把自己本地的 sdk 传给它的数据传到服务器就行。采用哪种 sdk 是由环境决定的，基本上在构建期间就会把这个配置同步到前后端。

说用 bean 的各位大佬，有个场景看怎么用 bean：

一个接口需要适配若干种 sdk，每种 sdk 需要的参数都不一致（基本没什么共同点），接口参数就是 sdk 需要的参数，具体用哪种 sdk 由配置决定。

这个入参怎么用 bean 呢？

这应该放在推广结点

原来那个.js 是库名的一部分。。一直以为是源码包的文件后缀。。。

纯 java 做不到。。只能 jni，GPU 相关的逻辑用 C 实现。

@LowBCoder #4 说 FilterInputStream 是 InputStream 的代理而不是装饰器的原因如下：
1. FilterInputStream 并没有给 InputStream 扩展任何功能，只是持有了一个 InputStream 的实例，所有的操作都转交给持有的这个 InputStream 的实例去做；
2. BufferedInputStream 和 BufferedInputStream 可以说是装饰器模式，都为 InputStream 增加了不属于它的特性；

抽象出一个用于代理的实现类而不是把同样的方法按照挨个在 BufferedInputStream 和 BufferedInputStream 里实现一遍，最显而易见的原因就是为了使代码简介，使用到了代理这个特性，所以抽象出一个代理者。

FilterInputStream 是代理模式，DataInputStream 和 BufferedInputStream 都使用了代理这个特性。

reviewer 告诉你不行肯定会告诉原因的，如果你觉得不合理可以刚啊。。

不要 catch throwable，全局设置一个默认的异常回调
```java
Thread.setDefaultUncaughtExceptionHandler((thread, throwable) -> {...});
```

不可以，此题完结。

把她的 vx 推给我，我帮你教育她

这样就可以了，方法签名的参数类型信息是带泛型信息的。

@lihongjie0209 #2 根据约定，JavaBeans 一定是可以被序列化的，你展示的注解给序列化和反序列化带来了不确定和不一致，由此可能产生无数 bug。

没有。感觉这种东西不但没办法解决问题，还会造成问题。。

源代码的编码和运行期的内存毫无关系。

技术本身不会带来变革，需求才会带来变革。。

5G 能带来的需求无非就是高清晰度视频、物联网、云游戏之类，对现有服务端技术感觉不会带来颠覆。。现代 CDN、函数即服务这些都很成熟了。。