TL;DR

Lombok did not support Java9 + IntelliJ, so I sent a fix pull request and had it imported (my name was entered in AUTHORS)
Explain what kind of change was made (who got it)
Lombok relies heavily on the internal classes of the JDK, so it's hard to keep up with every JDK version upgrade. It depends not only on the JDK but also on the implementation of the IDE.
It will be even more difficult as the JDK life cycle will change in the future. There is a good chance that the follow-up will be delayed.
You should be aware that there is such a risk if you rely heavily on Lombok.

About Lombok

Lombok is a very useful development tool that creates Setters and Getters just by annotating Java code.
Lombok is designed to add necessary functions by changing the AST (Abstract Syntax Tree) at compile time. It does not convert source code or bytecode.
This article is not an introductory article about Lombok, so the rest is around Honke and Lombok usage memo. Please see.

Lombok Java9 + IntelliJ support

There was a problem that the build did not pass with Java9 + IntelliJ, so I fixed it, but I will write what kind of fix I made.

I have prepared a simple class diagram because I can not explain it without knowing the internal structure of the related part (only the part related to this correction. A small part of the whole)

Classes in the JDK

First, there are the following classes in the javax.tools package as public classes for the JDK. All are classes used to manipulate source code and class files.

JavaFileObject: Interface for manipulating files (.java, .class, etc.).
JavaFileManager: Interface for generating JavaFileObject.
StandardJavaFileManager: An interface that inherits JavaFileManager and adds standard methods.

The implementation class for the above interface is under the com.sun.tools.javac package. This is the inner class of the JDK.

BaseFileManager: JavaFileManager implementation
BaseFileObject: JavaFileObject implementation (packages are different for javac6 and javac7)
PathFileObject: JavaFileObject implementation

Lombok implementation around file access

LombokFileObject Lombok uses Annotation Processor for AST conversion, but it interrupts class file writing as well as AST conversion processing. (See PostCompiler.wrapOutputStream () for details. Bytecode rewriting is done. Delete unnecessary code around @SneakyThrows and null check.) (2018/2/22 Corrected because there was a recognition error)

InterceptiongJavaFileObject provides an interrupt to write a file. This class is reflected on the Javac side when initializing LombokProcessor It has become like. This class implements the LombokFileObject interface. LombokFileObject inherits from JavaFileObject.

Lombok passes this to javac for processing, but there is one problem. The javac side is supposed to request the above BaseFileObject or PathFileObject internally (cast inside), so it will not accept the implementation of JavaFileObject interface (honestly, this is a shit implementation of javac) I think,,,) Therefore, you need to prepare a class that inherits BaseFileObject or PathFileObject and transfer it to the Lombok side. Lombok provides the following three Wrapper classes to do this.

Javac6BaseFileObjectWrapper extends com.sun.tools.javac.util.BaseFileObject
Javac7BaseFileObjectWrapper extends com.sun.tools.javac.file.BaseFileObject
Javac9BaseFileObjectWrapper extends com.sun.tools.javac.file.PathFileObject

At this point, I feel a little unpleasant, but the point is that we have prepared wrappers with different implementations for each version of javac. It is undeniable that there will be more and more in the future as the JDK version goes up. Both classes simply delegate all methods to LombokFileObject.

LombokFileObjects It's finally the production from here. Use LombokFileObjects to do things like wrap JavaFileManager.

First, LombokFileObjects has a Compiler interface. This is a class for wrapping a JavaFileObject and returning a LombokFileObject (implemented with the wrap () method). This also has a different class implementation for javac 6, 7, 9. Each is an implementation that returns the above Javac [679] BaseFileObjectWrapper.

The Compiler returns the LombokFileObjects.getCompiler (JavaFileManager jfm) method. The implementation looks at the JavaFileManager implementation class passed as an argument and returns the appropriate Compiler. There is a list of known JavaFileManager implementation class names called KNOWN_JAVA9_FILE_MANAGERS, which is full of unpleasant feelings.

Problems and workarounds in JDK9

The compiler implementation for javac9 is Java9Compiler. This implementation is a bit more complicated than 6 and 7. This is because PathFileObject, the base class of Java9BaseFileObjectWrapper, requires BaseFileManager in the constructor.

If the JavaFileManager passed to getCompiler () is an instance of BaseFileManager, it's okay (just cast it). But this can be another class. For example, when called from IntelliJ, a class that implements StandardJavaFileManager is passed. In this case, just casting will not work.

For this reason, I have created a new FileManagerWrapper class that inherits from BaseFileManager and modified it to use it for delegation. The pull request is here. This fix has been successfully incorporated and is currently released as 1.16.20. Now I managed to get the build to pass correctly in IntelliJ.

Where

Since the internal operation changes depending on the implementation of JDK, tracking is difficult.
Even if I try to fix it, debugging is difficult in the first place.
You can't stop at a breakpoint in the IDE (because it's in the build process inside the IDE in the first place).
So there is no choice but to print debug.
For Eclipse, it seems that Eclipse itself can be debugged (?). But other IDEs don't have it for now.

Future tasks

Lombok relies heavily on the JDK's inner class (com.sun.), So it won't work if the internal structure changes with a JDK update. In particular, Java's update cycle has been relatively long until now, but in the future it will be updated every 6 months (although it is every 3 years for LTS), so I think it will have a big impact. In fact, it's already stuck in OpenJDK10 Early Access. Ugh.

Another problem is that it is affected not only by the JDK but also by the implementation of IDEs and build tools (such as Maven / Gradle). Since the core development members of Lombok are based on Eclipse, support for IntelliJ, Netbeans, etc. may be delayed. I'm IntelliJ main, so I'm planning to fix it and contribute.

If you use Lombok firmly, you should be aware that there are such risks.

Lombok's Java 9+ support story