正文
Lombok插件看法浅谈
小程序：扫一扫查出行【扫一扫了解最新限行尾号】
复制小程序
背景
最近接触的几个工程中Lombok插件出现频率比较高，趁机了解一下原理。
简要说明：
受益于JSR 269 API，程序可以在编译阶段对AST进行节点的操作，从而注入相关的功能结点，从而包含在最终的字节码文件里。
优点：- 减少了coding过程中的一些Getter/Setter等代码的生成。
缺点：- 代码可读性差；
- 代码调试不方便；
- IDE需要插件支持。
总结：- 整体而言，个人认为使用lombok弊大于利，不建议使用；
- JSR 269是个比较有意思的东西，做一些分析类的工具应该有帮助。
扩展思考：
- 代码可读性差；
- 代码调试不方便；
- IDE需要插件支持。
总结：- 整体而言，个人认为使用lombok弊大于利，不建议使用；
- JSR 269是个比较有意思的东西，做一些分析类的工具应该有帮助。
扩展思考：
Spring AOP的部分是否可以使用JSR 269原理生成字节码，而不是运行时动态生成呢？
我认为是可以的，Spring的AOP是基于动态代理实现的，根据实际场景和具体配置不同有JDK原生动态代理和Cglib两种不同的实现。在Spring之前就已经有AOP的成熟实现了，而且也是在编译期使用字节码织入的方式，思路与lombok一致，那就是大名鼎鼎的AspectJ了，现在Spring中还沿用着它的AOP注解和语法。
不过AspectJ在JDK5就有了，那个时候JSR269还没出现，所以它并不是使用这种方式实现的。
看了下AspectJ的使用，发现跟lombok一样，需要IDE支持，增强的部分要写一些代码。但是如果没有Spring的话，我很乐意使用AspectJ来实现AOP的使用，因为给代码开发维护带来的便利和灵活性非常高，总体而言，利大于弊。
