【踩坑日记】记一次静态导入引起Lombok失效，导致编译失败的惨案
背景
时间： 某个普通的周一
天气： 晴，万里无云
内容： 开开心心写完需求，提交代码，打包部署。
[INFO] --------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] cannot find symbol
[ERROR] non-static method cannot be referenced from a static context
[ERROR] invalid method reference
[ERROR] cannot find symbol
[ERROR] cannot find symbol
[ERROR] cannot find symbol
[ERROR] cannot find symbol
......
好家伙，突然爆了上百个编译错误，我寻思我也妹干啥啊，只是写了一些业务代码。遂检查了项目Pom、Maven私服、Jenkins配置，结果一切正常，打先前的分支压根没毛病。然而在本地和远程打这个新分支就是不行。
朔源
排除了环境问题，剩下的肯定就是代码问题了。这里观察Maven打包日志，错误发生在编译期，内容大致都是找不到符号、方法不存在等等。很容易想到是代码生成相关的组件出问题了，那么首当其冲就要问罪Lombok了。
初以为是Lombok版本冲突之类的问题，用IDEA的Dependencies Diagram没看到异样。难道这里面有坑？只能求助于StackOverflow了，果不其然...原来这是一个陈年老BUG了，并且Lombok开发组并没有任何意愿修复。
罪魁祸首
长话短说，罪魁祸首就是项目中的静态导入！ 我们可以简单复现下：
package com.mycompany.lombokutilityclassbug;
@UtilityClass
public class MyUtilityClass {
void foo() { System.out.println ("hi"); }
}
这里创建一个类，加上 @UtilityClass 注解，使其成员方法自动加上static修饰符。
package com.mycompany.lombokutilityclassbug;
import static com.mycompany.lombokutilityclassbug.MyUtilityClass.foo;
public class Main { }
然后在别处 静态导入 这个工具类下一个或多个类方法。
注意，只有静态导入指定类成员，而不是使用通配符才能复现错误！也就是使用通配符是没有任何问题的！
import static com.mycompany.lombokutilityclassbug.MyUtilityClass.*; //works pretty fine.
import static com.mycompany.lombokutilityclassbug.MyUtilityClass.foo; //broken
然后编译一波，就会看到和本文开头一样的错误了。
但奇怪的是开发时Idea并不会报错，简直是波澜不惊，错误只发生在编译时。
Why？
下面摘录Lombok开发组大佬的一段话
This is a known bug, and not something that's easy to fix. Static imports are resolved before the annotation processors are run. This is a problem in javac, not lombok.
简单阐述下，这是一个已知的Bug，并且很难修复。静态导入在 注解处理器(annotaion processors) 运行之前就被编译器解析了，这是javac的问题，这锅爷不背。
注解处理器
那么什么是注解处理器呢（Annotation Processor）？
在定义自己的注解时，必须用到Java预置的一组元注解，其中呢有个东西叫 @Retention，用于声明你创建的这个注解的保留周期，可接受RetentionPolicy枚举。
/**
* Annotation retention policy. The constants of this enumerated type
* describe the various policies for retaining annotations. They are used
* in conjunction with the {@link Retention} meta-annotation type to specify
* how long annotations are to be retained.
*
* @author Joshua Bloch
* @since 1.5
*/
public enum RetentionPolicy {
/**
* Annotations are to be discarded by the compiler.
*/
SOURCE,
/**
* Annotations are to be recorded in the class file by the compiler
* but need not be retained by the VM at run time. This is the default
* behavior.
*/
CLASS,
/**
* Annotations are to be recorded in the class file by the compiler and
* retained by the VM at run time, so they may be read reflectively.
*
* @see java.lang.reflect.AnnotatedElement
*/
RUNTIME
}
默认行为呢，是选用CLASS级别，意味着注解将在编译期保留于class文件中，但运行时不会加载到JVM内存里。
RUNTIME级别，同时保留于class文件和JVM中，反射组件 能且仅能 扫描到的注解就是这一类。
SOURCE级别，注解在编译期就会被遗弃，相比于CLASS更多是用于开发辅助和代码生成。
可见度：SOURCE < CLASS < RUNTIME
而注解处理器就主要应用于SOURCE级别，在编译阶段通过向编译器注册自定义的注解处理器，可以进行一些额外操作，如代码生成、代码检查。
如@Override就是一个SOURCE注解，现代IDE可以在识别到未覆盖父类方法的就打上@Override注解时进行报错标识，其原理便是注解处理器。
不难发现Lombok的所有注解其保留周期都是SOURCE，因为其也是使用注解处理器来生成模板代码的。
结合上述概念，为什么这个锅大佬不背我们似乎有点眉目了。java编译过程似乎存在着一种时序问题，下面对编译器工作时序作一次大胆的猜测（还没修炼到精通编译器阶段，大佬轻喷）：
- 编译代码元素
- 组织包定义、导入语句
- 加载注解处理器
- etc...
在这种时序下，静态导入语句的编译先于注解处理器的运行，这时模板代码还没生成，自然就会报一堆编译错误了~
那为什么在IDE中没有报此类错误呢？我们在IDEA使用Lombok还需要安装特定的插件。就结果来看其编译过程和原生JDK的有所不同，或许这其中存在某些干预和优化，导致了错误被掩盖。
如何避免
鉴于官方已经甩锅不修，也修不了。我们只能修改开发代码来规避问题了，对于这类问题我们总结一个通解（java工具书风格）：
使用静态导入时，如果导入的代码元素是通过注解处理器动态生成的，不要使用具名静态导入，可以使用通配符。鉴于IDE通常会自动优化导入语句，可能会将通配符缩减成具名，而又不会报告这个编译器级别的漏洞，最佳方案是两者不要同时使用。
What's More
关于Lombok的时序问题，Lombok作者撰写了一篇Wiki： Lombok概念：解析，有兴趣的同学可以研究一下。作者将之比喻为“先有鸡还是先有蛋的问题”。了解其背后的矛盾后，也就能解释Lombok的一些局限性了，比如Builder/AllArgsConstructor/...为何不能继承父类字段等等。
参考：
[1] static import not working in lombok builder in intelliJ - (2017/12/06)
https://stackoverflow.com/questions/47674264/static-import-not-working-in-lombok-builder-in-intellij
[2] @Builder not work with static import in Intellij 2016.2.4 - (2016/09/27)
https://github.com/mplushnikov/lombok-intellij-plugin/issues/291
[3] JEP 216: Process Import Statements Correctly - (2014/08/26)
http://openjdk.java.net/jeps/216
[4] LOMBOK CONCEPT: Resolution - (2018/06/12)
https://github.com/rzwitserloot/lombok/wiki/LOMBOK-CONCEPT:-Resolution
