Latest Java Extension for VS Code Causes java.lang.NoClassDefFoundError with Lombok

[timmy0123]

After updating to the latest version of the Java extension for Visual Studio Code (released last night), the following error occurs during compilation when using Lombok:

Can't initialize javac processor due to (most likely) a class loader problem: java.lang.NoClassDefFoundError: Could not initialize class lombok.javac.Javac at lombok.javac.apt.LombokProcessor.placePostCompileAndDontMakeForceRoundDummiesHook(LombokProcessor.java:174) at lombok.javac.apt.LombokProcessor.init(LombokProcessor.java:96) at lombok.core.AnnotationProcessor$JavacDescriptor.want(AnnotationProcessor.java:160) at lombok.core.AnnotationProcessor.init(AnnotationProcessor.java:213) at lombok.launch.AnnotationProcessorHider$AnnotationProcessor.init(AnnotationProcessor.java:64) at org.netbeans.modules.java.source.indexing.APTUtils$ErrorToleratingProcessor.init(APTUtils.java:995) at com.sun.tools.javac.processing.JavacProcessingEnvironment$ProcessorState.<init>(JavacProcessingEnvironment.java:623) at com.sun.tools.javac.processing.JavacProcessingEnvironment$DiscoveredProcessors$ProcessorStateIterator.next(JavacProcessingEnvironment.java:752) at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:846) at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$2200(JavacProcessingEnvironment.java:109) at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1189) at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1302) at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1272) at org.netbeans.lib.nbjavac.services.NBJavaCompiler.processAnnotations(NBJavaCompiler.java:64) at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1174) at com.sun.tools.javac.api.JavacTaskImpl.enter(JavacTaskImpl.java:348) at com.sun.tools.javac.api.JavacTaskImpl.enter(JavacTaskImpl.java:282) at org.netbeans.modules.java.source.parsing.JavacParser.moveToPhase(JavacParser.java:742) at org.netbeans.modules.java.source.parsing.CompilationInfoImpl.toPhase(CompilationInfoImpl.java:426) at org.netbeans.api.java.source.CompilationController.toPhase(CompilationController.java:90) at org.netbeans.modules.java.hints.infrastructure.JavaErrorProvider$1.run(JavaErrorProvider.java:108) at org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProcessor.java:586) at org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:197) at org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:180) at org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:181) at org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:178) at org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153) at org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:335) at org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(DataObjectEnvFactory.java:118) at org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:67) at org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:178) at org.netbeans.modules.parsing.api.ParserManager.parse(ParserManager.java:83) at org.netbeans.modules.java.hints.infrastructure.JavaErrorProvider.computeErrors(JavaErrorProvider.java:100) at org.netbeans.modules.java.lsp.server.protocol.TextDocumentServiceImpl.lambda$computeDiags$49(TextDocumentServiceImpl.java:2208) at java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:273) at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682) at org.netbeans.modules.java.lsp.server.protocol.TextDocumentServiceImpl.computeDiags(TextDocumentServiceImpl.java:2213) at org.netbeans.modules.java.lsp.server.protocol.TextDocumentServiceImpl.lambda$runDiagnosticTasks$46(TextDocumentServiceImpl.java:2106) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1403) at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45) at org.openide.util.lookup.Lookups.executeWith(Lookups.java:287) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2018) Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.NoSuchFieldException: com.sun.tools.javac.code.TypeTag :: UNKNOWN [in thread "org.netbeans.modules.java.lsp.server.protocol.TextDocumentServiceImpl"] at lombok.permit.Permit.getField(Permit.java:144) at lombok.javac.JavacTreeMaker$SchroedingerType.getFieldCached(JavacTreeMaker.java:171) at lombok.javac.JavacTreeMaker$TypeTag.typeTag(JavacTreeMaker.java:259) at lombok.javac.Javac.<clinit>(Javac.java:187) ... 47 more

Reverting to the previous version(23.1.0) of the Java extension resolves the issue.

Java Extension Version: 24.0.0
Lombok Version: 1.18.36
Java Version: 17

[TiredDom]

Same here, but my project runs fine. Hate seeing these yellow and red squiggly lines that are not there a few days ago.

[sid-srini]

Hi @timmy0123 and @TiredDom. Thanks for reaching out.

Lombok utilises JDK internal code and thus is fragile to changes in Java internal implementation. For some details, you may refer to the Controversy section of the article given as the textual primer on project lombok's home page. (Note that in the error above this is due to Lombok trying to access a now non-existent field com.sun.tools.javac.code.TypeTag resulting in java.lang.NoSuchFieldException)

Thus if your version of Lombok works alright with some version of JDK, you may use the extension's feature of a separate project JDK. Keep the jdk.jdkhome set to a JDK that would be used to run the extension (Java 17+) while including a jdk.project.jdkhome set to the JDK you wish to use with your project. Please refer to the Selecting the JDK section of the extension readme for further guidance on this.

You may also refer to issue-tracking in Project Lombok, such as 3772, which may guide you to work around such Lombok limitations.

I hope this helps you.

P.S. Closing this issue as this theme is also discussed in other issues here.