[BUG] java.lang.NoClassDefFoundError: lombok/launch/PatchFixesHider$Transform with eclipse 2019-12 and SonarLint-Plugin

[razilein]

Describe the bug
When using eclipse and the SonarLint-Plugin I get an error every time I save the file and sonar begins to analyze.

To Reproduce
Install the latest eclipse version 2019-12 and the SonarLint-Plugin and the current lombok-Version.
Bind a project to sonar and change a file and save it.

!ENTRY org.eclipse.core.jobs 4 2 2020-01-30 09:05:28.589 !MESSAGE An internal error occurred during: "SonarLint processing file /newd-web/src/main/java/de/data_team/newd/inspektor/verjaehrung/service/VerjaehrungsAgentSchuldnerHforProcessor.java". !STACK 0 java.lang.NoClassDefFoundError: lombok/launch/PatchFixesHider$Transform at org.eclipse.jdt.internal.compiler.parser.Parser.endParse(Parser.java:10882) at org.eclipse.jdt.internal.core.util.CommentRecorderParser.endParse(CommentRecorderParser.java:135) at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:12065) at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:12289) at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:12246) at org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java:10654) at org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:849) at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:394) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1173) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:714) at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1217) at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:832) at org.sonar.java.model.JParser.parse(JParser.java:289) at org.sonar.java.model.JParser.parse(JParser.java:249) at org.sonar.java.ast.JavaAstScanner.simpleScan(JavaAstScanner.java:93) at org.sonar.java.ast.JavaAstScanner.scan(JavaAstScanner.java:65) at org.sonar.java.JavaSquid.scanSources(JavaSquid.java:111) at org.sonar.java.JavaSquid.scan(JavaSquid.java:105) at org.sonar.plugins.java.JavaSquidSensor.execute(JavaSquidSensor.java:88) at org.sonarsource.sonarlint.core.analyzer.sensor.SensorsExecutor.executeSensor(SensorsExecutor.java:81) at org.sonarsource.sonarlint.core.analyzer.sensor.SensorsExecutor.execute(SensorsExecutor.java:72) at org.sonarsource.sonarlint.core.container.analysis.AnalysisContainer.doAfterStart(AnalysisContainer.java:134) at org.sonarsource.sonarlint.core.container.ComponentContainer.startComponents(ComponentContainer.java:125) at org.sonarsource.sonarlint.core.container.ComponentContainer.execute(ComponentContainer.java:110) at org.sonarsource.sonarlint.core.container.storage.StorageAnalyzer.analyze(StorageAnalyzer.java:75) at org.sonarsource.sonarlint.core.container.storage.StorageContainerHandler.analyze(StorageContainerHandler.java:81) at org.sonarsource.sonarlint.core.ConnectedSonarLintEngineImpl.lambda$analyze$0(ConnectedSonarLintEngineImpl.java:152) at org.sonarsource.sonarlint.core.ConnectedSonarLintEngineImpl.withReadLock(ConnectedSonarLintEngineImpl.java:344) at org.sonarsource.sonarlint.core.ConnectedSonarLintEngineImpl.withReadLock(ConnectedSonarLintEngineImpl.java:334) at org.sonarsource.sonarlint.core.ConnectedSonarLintEngineImpl.analyze(ConnectedSonarLintEngineImpl.java:149) at org.sonarlint.eclipse.core.internal.server.Server.runAnalysis(Server.java:327) at org.sonarlint.eclipse.core.internal.jobs.AnalyzeConnectedProjectJob.runAnalysis(AnalyzeConnectedProjectJob.java:72) at org.sonarlint.eclipse.core.internal.jobs.AnalyzeConnectedProjectJob.runAnalysis(AnalyzeConnectedProjectJob.java:1) at org.sonarlint.eclipse.core.internal.jobs.AbstractAnalyzeProjectJob.run(AbstractAnalyzeProjectJob.java:399) at org.sonarlint.eclipse.core.internal.jobs.AbstractAnalyzeProjectJob.runAnalysisAndUpdateMarkers(AbstractAnalyzeProjectJob.java:207) at org.sonarlint.eclipse.core.internal.jobs.AbstractAnalyzeProjectJob.doRun(AbstractAnalyzeProjectJob.java:169) at org.sonarlint.eclipse.core.internal.jobs.AbstractSonarProjectJob.run(AbstractSonarProjectJob.java:45) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) Caused by: java.lang.ClassNotFoundException: lombok.launch.PatchFixesHider$Transform at org.sonar.classloader.ParentFirstStrategy.loadClass(ParentFirstStrategy.java:39) at org.sonar.classloader.ClassRealm.loadClass(ClassRealm.java:87) at org.sonar.classloader.ClassRealm.loadClass(ClassRealm.java:76) ... 38 more

Expected behavior
Sonar should analyze the file.

Version info (please complete the following information):

• Lombok version: 1.18.10
• eclipse 2019-12 (4.14.0)
• SonarLint 4.3.0.12432

[rzwitserloot]

Almost looks like sonar is using its own classloader architecture, which is a bit superfluous (eclipse is built on OSGi and already has this). Based primarily on the very last part of that stacktrace, where there is an org.sonar.classloader.ParentFirstStrategy class.

To fix this we'd have to patch that code in our agent, which is... a bit of a maintenance nightmare.

Is org.sonar.classloader.ParentFirstStrategy open source? I'm thinking no.

If it is not, we're not going to fix this, you'll have to ask them to do it, or to contact us with details. I'm not going to attempt to reverse engineer bytecode; bytecode that appears to serve no purpose other than to obfuscate how loading plugins even works.

If it is, let me know where to look.

[henryju]

Hi,

I'm working on the SonarLint plugin at SonarSource. I'm also currently trying to solve this issue (or at least to understand what's going on :)).
First of all, the issue started to appear because our Java analyzer switched to use ecj as a frontend. My understanding is that Lombok EclipsePatcher is patching "our" classes at the same time as "regular" Eclipse compiler.

Is org.sonar.classloader.ParentFirstStrategy open source?

You can find it here: https://github.com/SonarSource/sonar-classloader/blob/master/src/main/java/org/sonar/classloader/ParentFirstStrategy.java

bytecode that appears to serve no purpose other than to obfuscate how loading plugins even works

We have some commercial plugins, but our Java analyzer is open source, and I can guarantee there is no attempt to obfuscate anything here.

Almost looks like sonar is using its own classloader architecture, which is a bit superfluous (eclipse is built on OSGi and already has this)

Our analyzers are not Eclipse/OSGi bundles, and they are used in non OSGi environments (like IntelliJ, SonarQube server, ...). Our SonarLint Eclipse plugin is obviously an OSGi component, and internally we are creating custom isolated classloaders to dynamically load each analyzers.

Do you have a suggestion of what we could to restore the compatibility?

[rzwitserloot]

Glad to hear from you @henryju – heh, this is an interesting case: Whilst running as an eclipse plugin within eclipse, you are loading a bunch of ECJ classes within eclipse, but within the confines of your own plugin even though eclipse already has these classes loaded as part of the JDT plugin. I'd stick with your model, because the JDT plugin's ECJ may not be the version your code is written for.

But, lombok does not know that; it patches all 'ECJ-esque' classes that the VM process is attempting to load. There is some advantage to lombokizing sonar's ECJ, in that it would in theory make sonar more aware of lombok's additions, but that's a sizable can of worms that perhaps we shouldn't get into. Given that things seemed to be doing allright before your update to using ECJ, perhaps the easiest course of action, at least for now, is to ensure that lombok does not lombokize sonar's ECJ.

When we apply the patches, we know which classloader is responsible as we're trying to patch it.

Normally in eclipse land, that's generally an instance of org.eclipse.osgi.internal.loader.EquinoxClassLoader (for all eclipse plugins), or org.eclipse.equinox.launcher.Main$StartupClassLoader (that's what eclipse boots with).

I'm pretty sure that, if I were to install sonarlint into my eclipse, I'd find that it's an instance of .org.sonar.classloader._something_. We can detect that, and not patch it.

Can you reproduce this problem right now?

If so, can you try this edge release? I added this solution of refusing to patch if the CL responsible for loading is that. Double click the edge release jar, instill into eclipse, launch it, check that this problem no longer occurs.

[henryju]

Can you reproduce this problem right now?

yes

can you try this edge release?

just did with lombok-edge-20200130.162511-1.jar, and the problem is still there.

the classloader in SonarJava is an instance of org.sonar.classloader.ClassRealm but loader.getClass().toString().startsWith("org.sonar.classloader") returns false because loader.getClass().toString() returns class org.sonar.classloader.ClassRealm. Maybe replace by loader.getClass().getName().startsWith("org.sonar.classloader")?

[rzwitserloot]

Well, don't I feel like the duncehead now. In shame I did try to reproduce this by installing the sonarlint plugin, but I didn't manage, possibly because I haven't bound this project to sonarcloud.

I'm going to just trust your work on this @henryju – I've made another edge-release, this time comparing with the proper API (getName) and not toString.

[henryju]

I didn't manage, possibly because I haven't bound this project to sonarcloud

Indeed, the version of our Java analyzer shipped by default in SonarLint is still pre ecj. When binding to SonarCloud you get a more recent version.

I have just tested lombok-edge-20200130.195021-1.jar and it works fine, thanks!

[kushanxp]

I didn't manage, possibly because I haven't bound this project to sonarcloud

Indeed, the version of our Java analyzer shipped by default in SonarLint is still pre ecj. When binding to SonarCloud you get a more recent version.

I have just tested lombok-edge-20200130.195021-1.jar and it works fine, thanks!

@henryju can you please share that Jar file: lombok-edge-20200130.195021-1.ja

[randakar]

Here you go: https://projectlombok.org/download-edge

…

On Wed, Feb 26, 2020, 16:24 kushanxp ***@***.***> wrote: I didn't manage, possibly because I haven't bound this project to sonarcloud Indeed, the version of our Java analyzer shipped by default in SonarLint is still pre ecj. When binding to SonarCloud you get a more recent version. I have just tested lombok-edge-20200130.195021-1.jar and it works fine, thanks! @henryju <https://github.com/henryju> can you please share that Jar file: lombok-edge-20200130.195021-1.ja — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2351>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABIERLSD7U74QNUEOKAWYLRE2CRJANCNFSM4KNRVQNA> .

[kavumkalmana]

I have Spring Tool Suite 4 and Sonar Lint for Eclipse 5.0.0.1518.
I had to update the Lombok plug in https://projectlombok.org/download-edge to resolve the issue mentioned in this Bug Thread.
So cant you update this page https://projectlombok.org/setup/eclipse with jar file which has the fixes

[rzwitserloot]

@binukavumkal We don't post 'use the edge release' as instructions, obviously. The current version of lombok (1.18.12) has this fix, just update it.

[Demner21]

I updated my file STS.ini whit a new version of Lombock: [lombok-1.18.12.jar] :
the last line is now:
-javaagent:PATH\sts-bundle\sts-3.9.9.RELEASE\lombok-1.18.12.jar

[aaiezza]

This is happening again for me with the following:

OS: Windows 10
Eclipse: 2020-09
Lombok: 1.18.14

I've tried the lombok.jar installer as well as the Eclipse plugin. Both yield the same results:

UPDATE

As @Rawi01 pointed out, this is a different problem: #2599.

[Rawi01]

That's a different problem, see #2599

[Karthik3247]

Even i was facing the same issue with the latest Lambok jar (i.e. 1.18.22) as well, for the following:

OS: Windows 10
SpringToolSuite4
Java: JDK8
Sonarlint 7.0
Lombok : 1.18.22

An internal error occurred during: "SonarLint processing file......". lombok/launch/PatchFixesHider$Transform
An internal error occurred during: "SonarLint processing file......". lombok/launch/PatchFixesHider$ValPortal

[ckm2912]

Copy Lombok 1.18.16 jar to some desktop folder. And double click on jar file. One popup window called "Quick installer" will open and it will identify all eclipse instances in system. Click install finish . Restart eclipse as mentioned in the popup. This issue will go off. It worked for me!!!