Possible Lombok Incompatibility

[aelfric]

Sorry if this is not really a Quarkus bug. I'm a newcommer to Quarkus working on a proof of concept. I have a project that is making some minimal use of Lombok annotations. When running mvn quarkus:dev, occasionally after modifying one of the Lombok-annotated classes and trying to refresh the browser, I get a an error with the below stacktrace.

Expected behavior
Code recompiles successfully.

Actual behavior

    Can't initialize javac processor due to (most likely) a class loader problem: java.lang.NoClassDefFoundError: com/sun/tools/javac/processing/JavacProcessingEnvironment
  	at lombok.javac.apt.LombokProcessor.getJavacProcessingEnvironment(LombokProcessor.java:410)
  	at lombok.javac.apt.LombokProcessor.init(LombokProcessor.java:90)
  	at lombok.core.AnnotationProcessor$JavacDescriptor.want(AnnotationProcessor.java:124)
  	at lombok.core.AnnotationProcessor.init(AnnotationProcessor.java:177)
  	at lombok.launch.AnnotationProcessorHider$AnnotationProcessor.init(AnnotationProcessor.java:73)
  	at com.sun.tools.javac.processing.JavacProcessingEnvironment$ProcessorState.<init>(JavacProcessingEnvironment.java:500)
  	at com.sun.tools.javac.processing.JavacProcessingEnvironment$DiscoveredProcessors$ProcessorStateIterator.next(JavacProcessingEnvironment.java:597)
  	at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:690)
  	at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1800(JavacProcessingEnvironment.java:91)
  	at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1035)
  	at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1176)
  	at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170)
  	at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856)
  	at com.sun.tools.javac.main.Main.compile(Main.java:523)
  	at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:129)
  	at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:138)
  	at io.quarkus.dev.JavaCompilationProvider.compile(JavaCompilationProvider.java:55)
  	at io.quarkus.dev.ClassLoaderCompiler.compile(ClassLoaderCompiler.java:156)
  	at io.quarkus.dev.RuntimeUpdatesProcessor.checkForChangedClasses(RuntimeUpdatesProcessor.java:164)
  	at io.quarkus.dev.RuntimeUpdatesProcessor.doScan(RuntimeUpdatesProcessor.java:103)
  	at io.quarkus.undertow.deployment.devmode.UndertowHotReplacementSetup.handleHotDeploymentRequest(UndertowHotReplacementSetup.java:72)
  	at io.quarkus.undertow.deployment.devmode.UndertowHotReplacementSetup$1$1.handleRequest(UndertowHotReplacementSetup.java:61)
  	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
  	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
  	at io.quarkus.runtime.CleanableExecutor$CleaningRunnable.run(CleanableExecutor.java:224)
  	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
  	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
  	at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
  	at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:2011)
  	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1535)
  	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1426)
  	at org.jboss.threads.DelegatingRunnable.run(DelegatingRunnable.java:29)
  	at org.jboss.threads.ThreadLocalResettingRunnable.run(ThreadLocalResettingRunnable.java:29)
  	at java.lang.Thread.run(Thread.java:748)
  	at org.jboss.threads.JBossThread.run(JBossThread.java:479)

To Reproduce
Steps to reproduce the behavior:

1. Modify a file annotated with Lombok @Data
2. Refresh in the brower causing the code to re-compile.

Environment (please complete the following information):

• Output of uname -a or ver: This is on Windows 10 version 1903,
• Output of java -version:

openjdk version "1.8.0_212"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_212-b04)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.212-b04, mixed mode)

• GraalVM version (if different from Java): N/A
• Quarkus version or git rev: 0.21.3

Additional context
If it matters, this is a multi-module maven project with two modules web and service. web is the quarkus module. Both web and service have a few classes using Lombok.

[dmlloyd]

This does seem like a real Quarkus bug. If I had to spitball some ideas, I'd say maybe inconsistent TCCL contents might be a possible culprit, or maybe an error in how we assemble the app's class loader which is probably also inconsistent with how we do it in regular mode. Maybe it varies from run to run or something.

[jaikiran]

@aelfric Is there a project you can share, perhaps as a github repo, which helps reproduce this issue?

[aelfric]

Unfortunately, the project is closed source, but I'll see if I can make a minimal example with a similar structure that has the same unexpected behavior.

…

On Sun, Sep 29, 2019, 12:08 AM Jaikiran ***@***.***> wrote: @aelfric <https://github.com/aelfric> Is there a project you can share, perhaps as a github repo, which helps reproduce this issue? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4224?email_source=notifications&email_token=AAZTRYHKSPSQ5EXX6JDG6Y3QMAS3JA5CNFSM4I24D6YKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD73HWJA#issuecomment-536247076>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAZTRYFMPVK3FY5E3IUWAR3QMAS3JANCNFSM4I24D6YA> .

[matus-m]

Its probably related to #1502.

[stale]

This issue/pullrequest has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[tobad357]

Any luck with this as we are hitting the same issue?

[aelfric]

No luck on my side. As a (albeit poor) workaround, we've resorted to minimizing use of Lombok in new code, but we have just been restarting maven whenever we make changes to older code with Lombok annotations.

[jaikiran]

Hello @tobad357, Any chance you can share a reproducer for this (maybe as a github repo with the source)?

[tobad357]

@jaikiran please see https://github.com/tobad357/quarkus-lombok-test
To trigger the issue do the following

1. Start quarkus dev (./gradlew quarkusDev)
2. Edit src/main/java/org/acme/ExampleResource.java and change the log message
3. Reload the url http://0.0.0.0:8080/hello

This will give you the error if using the following JVM

OpenJDK 64-Bit GraalVM CE 19.2.1 (build 25.232-b07-jvmci-19.2-b03, mixed mode)

It will work without issue using the following JVM
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.4+11, mixed mode)

[aelfric]

Sorry I was never able to contribute a minimal reproducer, but this one from tobad357 is behaving the same for me as the issue we're encountering in our project. We are not using GraalVM, though. I'm running on Windows 10 with the following JVM.

openjdk version "1.8.0_212"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_212-b04)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.212-b04, mixed mode)

[ssindelar]

I have the same behavior with gradle on Windows. The missing Class is part of the Java Compiler.

I noticed that lombok trys to use the JRE as compiler because "Java.home" is set to the jre folder inside the jdk:

Java.home: C:\Program Files\Java\jdk8u222-b10\jre

I can't find a way to change it to the root of the JDK. Outside the lombok + Quarkus combination everything works fine and the correct path is used.

[jaikiran]

Sorry, I have been a bit busy and wasn't able to look into this sooner. I will try and find some time this weekend and see what's going on and if I can help.