【踩坑日记】记一次静态导入引起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

原文地址:https://www.cnblogs.com/notayeser/p/12654551.html