EmptyLombokFileObject creates FileObject at root level and break modular builds

[MCMicS]

To force a new Round EmptyLombokFileObject is used. This creates a file in root.

It works if you compile without modules. With modular code (moduel-info.java exists) this will result in error.

javax.annotation.processing.FilerException: Cannot write to the given module.

Why not use the target or generated sources folder for ForceNewRound files?
Or maybe one of them ideas:

• add some logic in Javac9BaseFileObjectWrapper
• use some kind of MemoryJavaFileObject

Log from lombok.javac.apt.InterceptingJavaFileManager#getJavaFileForOutput I've added:

warning: getJavaFileForOutput javaFileObject: /lombok/dummy/ForceNewRound0.java
warning: getJavaFileForOutput javaFileObject: file:///lombok/dummy/ForceNewRound0.java

See Issues: #1723, #1572

[rzwitserloot]

#1572 seems unrelated.

First step is to have a self-contained reproduction. Presumably, something involving module-info and enough lombok usage to force new rounds. We're already late on a release so this will have to wait until the next one.

[MCMicS]

I think #1572 because the issue say that lobok not works if module-info.java exists.
This will lay on the ForceNewRound creation

I have tested it with my own annotation processor and use Memory File and it works

sample found at: https://gist.github.com/MCMicS/7763a0a9607ebd83adc328fc7ad52867

[rspilker]

I like to use a memory based file if possible. In your gist, you use the SimpleJavaFileObject. However, in our EmptyLombokFile object, a comment in the code suggests that at least some javac version, presumably 9, can't cope with that.

[rzwitserloot]

This bug report is very confusing to me:

1. Lombok ALREADY has code to deal with this issue: For every file it touches, it checks which module it is in. If it is in a (named) module it remembers this name and stops looking for module names. When there's a need to force a new round, it'll use this module name (if one was found). If you get this error in a recent version of lombok, apparently there's a bug in it. Your bug report suggests lombok is unaware of modules when forcing rounds.

2. Your snippet has a class named SourceMemoryJavaFileObject but you don't use it anywhere in the snippet. I'm not sure how to use this thing.

[rzwitserloot]

In the lombok source repo, there's the directory test/manual/moduleBasedMultiProject.

If you rebuild lombok and actually print what lombok makes (so, at line 362 at src/core/lombok/javac/apt/LombokProcessor.java inject System.out.println(name);) and then run the bash script in that test/manual dir you'll see lombok is making the dummy in module projB.

Seems to be working fine. The bug you are describing is evidently dependent on a weirder situation; possibly with one of the modules being read-only somehow, not quite sure how that works.

So, what we need is BOTH:

1. A self contained test case to reproduce this bug because I can't manage it, and

2. Explanation of this memory file thing, it sounds interesting.

Without further feedback, auto-close at 2018-12-10.

[MCMicS]

ok I have test with 1.18.4 and following command works:

javac --processor-path ../../../dist/lombok.jar -p ../../../dist/lombok.jar -d out/projA projA/module-info.java projA/pkgA/ClassA.java

But if I add sourcepath (or maven add this paramter) then it will fail:

javac --processor-path ../../../dist/lombok.jar -p ../../../dist/lombok.jar -sourcepath projA -d out/projA projA/module-info.java projA/pkgA/ClassA.java
projA/lombok.dummy.ForceNewRound0
/lombok/dummy/ForceNewRound0.java:1: error: file should be on source path, or on patch path for module
1 error

simple project can be found here: https://github.com/MCMicS/simple-lombok/tree/java-11

[rspilker]

We just released an edge release. Can you give it a try and report back:

• if it fixes the problem
• if everything else still works as expected

[MCMicS]

After a short test it seems to be fixed. Compiling with Maven works and Intellij also compile the source files correctly.

Tested with JJDK 11 and JDK 12

I'll will try a wider test later this day.
Thanks for fix so far.

Only works if annotation path is configured in pom (see #1723 (comment)).

In my opinion this issue is fixed because it works if you confiugre the annotation processor path

[binkley]

Does this work with Java 16, which makes the default to fail illegal access?