lombok recognition fails after 1.8.0 release

[jkamke]

Running in a devcontainer java build fails to properly compile lombok annotation support. Rolling back to 1.7.0 release resolves the issue.

Environment

• Operating System: Ubuntu 20.04.4 LTS (Focal Fossa)
• JDK version: 1.8
• Visual Studio Code version: 1.68.1 (Universal)
• Java extension version: 1.8.0 and 1.9.2022070604

Steps To Reproduce

1. install vscjava.vscode-java-pack and vscjava.vscode-lombok in a devcontainer
2. reload as requested

Current Result

Java Building [Done] with errors

Expected Result

Java Building [Done] without errors

Additional Informations

Downgrading to 1.7.0 resolves the issue.

[jdneo]

@XiaoYuhao is investigating this issue.

[XiaoYuhao]

@jkamke Which lombok version do you use in your project?

[jcolladosp]

Hi @XiaoYuhao, facing the same issue, using 1.18.22 version Also tried 1.18.24

Thanks

[XiaoYuhao]

Hi @XiaoYuhao, facing the same issue, using 1.18.22 version Also tried 1.18.24

Thanks

It seems that the lombok don't load into the language server correctly. I think that you can view vscode-java extension log file. (Ctrl+Shift+P : Java: Open Java Extension Log File)

And then check the language server starting parameters:

{
  message: 'Starting Java server with: java ...... -javaagent: \path\lombok-1.18.24.jar ...... '
  level: 'info',
  timestamp: 'xxxx-xx-xx:xx'
}

Is the -javaagent: \path\lombok-1.18.24.jar argument correct？Or is there any other -javaagent argument？

[jcolladosp]

Hi, @XiaoYuhao , the path to lombok seems OK, the lombok.jar exists in that path. I attach here the snippet of the log in case you want to check something:

{ message: 'Starting Java server with: /usr/lib/jvm/jdk-17/bin/java --add-modules=ALL-SYSTEM --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/sun.nio.fs=ALL-UNNAMED -Declipse.application=org.eclipse.jdt.ls.core.id1 -Dosgi.bundles.defaultStartLevel=4 -Declipse.product=org.eclipse.jdt.ls.core.product -Djava.import.generatesMetadataFilesAtProjectRoot=false -Dfile.encoding=utf8bom -XX:+UseParallelGC -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true -Xmx1G -Xms100m -javaagent:/home/jcolladosp/.vscode/extensions/vscjava.vscode-lombok-1.0.1/server/lombok.jar -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/jcolladosp/.config/Code/User/workspaceStorage/c6a156ff9a8ae36ba1198decfa08aadf/redhat.java -jar /home/jcolladosp/.vscode/extensions/redhat.java-1.7.0-linux-x64/server/plugins/org.eclipse.equinox.launcher_1.6.400.v20210924-0641.jar -configuration /home/jcolladosp/.config/Code/User/globalStorage/redhat.java/1.7.0/config_linux -data /home/jcolladosp/.config/Code/User/workspaceStorage/c6a156ff9a8ae36ba1198decfa08aadf/redhat.java/jdt_ws', level: 'info', timestamp: '2022-07-08 08:41:41.793' }

[jkamke]

There seems to be a conflict between vscjava.vscode-lombok and redhat.java as of version 1.8. This version introduces a new setting java.jdt.ls.lombokSupport.enabled. With the lombok plugin installed you must have java.jdt.ls.lombokSupport.enabled=false. Without the lombok plugin (and java.jdt.ls.lombokSupport.enabled=true) it is working, so long as the lombok version is (at least?) lombok-1.18.12.jar (which is the same version which was in extensions/vscjava.vscode-lombok-1.0.1/server/lombok.jar )

[XiaoYuhao]

@jkamke Yeah, after 1.8.0 release, redhat.java uses the lombok version from your project's classpath as -javaagent: parameter to start JDT LS. However, the vscjava.vscode-lombok uses the fixed lombok version (extensions/vscjava.vscode-lombok-1.0.1/server/lombok.jar) as -javaagent: to start JDT LS. It causes conflict.

In order to avoid this conflict, redhat.java will remove the -javaagent: parameter which added by vscjava.vscode-lombok if java.jdt.ls.lombokSupport.enabled=true.

[testforstephen]

Without the lombok plugin (and java.jdt.ls.lombokSupport.enabled=true) it is working, so long as the lombok version is (at least?) lombok-1.18.12.jar (which is the same version which was in extensions/vscjava.vscode-lombok-1.0.1/server/lombok.jar )

@jkamke Correct. From our testing, it seems the lombok version 1.18.4 and higher can be loaded to redhat.java extension well. Anyway, we're also considering embedding a latest lombok-1.18.24.jar in redhat.java extension itself. Finally, vscode-lombok extension will remove the same lombok.jar but provide some auxiliary lombok feature there instead.

[jcolladosp]

@jkamke if I understood you correctly, vscjava.vscode-lombok is now useless since lombok is now included in redhat.java?

[jkamke]

@jcolladosp I would say that I don't have a use for vscjava.vscode-lombok now that redhat.java can pick it up off the classpath. Additionally, since loading the second plugin requires a language server restart it is less convenient for my use case.