Using Java installation of SonarLint
Using JRE from /<path to eclipse app>/Contents/Eclipse/plugins/org.sonarlint.eclipse.sloop.macosx.aarch64_10.5.0.82112/sloop/jre
Unable to start the SonarLint backend
java.io.IOException: Cannot run program "/<path to eclipse app>/Contents/Eclipse/plugins/org.sonarlint.eclipse.sloop.macosx.aarch64_10.5.0.82112/sloop/jre/bin/java" (in directory "/<path to eclipse app>/Contents/Eclipse/plugins/org.sonarlint.eclipse.sloop.macosx.aarch64_10.5.0.82112/sloop/jre/bin"): error=13, Permission denied
at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143)
at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1073)
at org.sonarsource.sonarlint.core.rpc.client.SloopLauncher.execute(SloopLauncher.java:102)
at org.sonarsource.sonarlint.core.rpc.client.SloopLauncher.start(SloopLauncher.java:63)
at org.sonarlint.eclipse.core.internal.backend.SonarLintBackendService$1.run(SonarLintBackendService.java:168)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: java.io.IOException: error=13, Permission denied
at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:314)
at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:244)
at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1110)
... 5 more
Starting SonarLint for Eclipse 10.5.0.82112
Please provide
Operating system: MacOS but also observed on Linux
SonarLint plugin version: 10.5.0.82112
Programming language you’re coding in: Java
Connected to SonarQube: Version 10.3 (build 82913)
thank you for reaching out. This issue is not yet known but also a bit confusing to say the least. Let me explain:
Apparently, SonarLint doesn’t use a Java runtime provided by you, and you use an Eclipse IDE that is running on Java < 17 and therefore it is using the bundled JRE (as parts of SonarLint require a Java 17 runtime). Btw, could you please provide me with the version of the Eclipse IDE you are using?
When SonarLint is released it is made sure that the JRE bundled has the executable flag and when SonarLint is started using its bundled JRE we also make sure, once again, to set the executable flag.
I guess that your machine forbids the JRE from starting up (maybe any software on your machine installed by your company to limit the execution of software). Do you have any Java 17 runtime that is especially set by your organization to be used?
If so, then, as the docs linked above, you also have to make it available to SonarLint.
If this is not the case, then still maybe some software on your machine is forbidding it to run, an inventory system or an anti-virus protection or something like that.
It could be that there was a difference in the user who installed Eclipse and/or SonarLint and the one that is running it (even difference between sudo and non-sudo can make a deal). Could you please tell me how the Eclipse IDE is usually installed in your environment?
We a company-custom distribution based on the latest Eclipse (2024-06) that requires Java 17. So it is not possible that people start with something different.
We updated from 9.3.0.81553 to 10.5.0.82112 (nobody complained before this update)
EDIT: we also recently updated from Eclipse 2023-12 to 2024-06
maybe any software on your machine installed by your company to limit the execution of software
I really doubt it is the case. The company has a BYOD policy without installing a lot of control software.
Then still maybe some software on your machine is forbidding it to run, an inventory system or an anti-virus protection or something like that.
I don’t think so.
People who has experienced the issue were able to deal with the issue by just doing a chmod on the mentioned file.
It could be that there was a difference in the user who installed Eclipse and/or SonarLint and the one that is running it (even difference between sudo and non-sudo can make a deal)
It is the same user. We have a python script that unzip the zip and start it. I will double check but to my knowledge everything works in non-sudo mode.
EDIT 2: Eclipse 2024-06 requires Java 17 (I thought it is Java 21)
This wasn’t the case with SLE 9.3.0.81553, as we only introduced the bundled JRE when moving to 10.0. Since it is OS and architecture-specific, we set the executable flag on the specific files depending on the OS and architecture.
Even unzipping the distribution shouldn’t be an issue for losing those executable flags, but your workaround would be the next one I would have suggested. I will reach out to my colleague to put it on the troubleshooting docs page as well.
As you have a custom distribution, I would encourage you to reach out to your colleagues who are creating it to already do this when they create the distribution. Like before zipping it to run a chmod +x on the necessary files in the JRE.
If they want to have it, they can also already set the Eclipse preference for SonarLint for Eclipse to link to that JRE the IDE is running with. Here are the official docs on how to do it from the UI, but the actual eclipse preference needs some more in-depth knowledge of the Eclipse IDE.
This one is optional but a lot of enterprises like to provide SonarLint with a self-managed Java runtime, we require Java 17+ and the 21 LTS is fine as well.
Even unzipping the distribution shouldn’t be an issue for losing those executable flags, but your workaround would be the next one I would have suggested.
We are building the zip with Maven Tycho, nothing special here. I can share a reproducer if you want/need.
I am confused by the fact that this zip would contains a file with the wrong execution flag.
As does it differ from the case where you add the EclipseLint plugin form the P2 Update site?
I also don’t guess that Tycho is stripping them or that they’re lost when zipping/unzipping them.
That was the confusing part as even when SonarLint is starting up and the executable flags are not on the files, we add them as they were not working on Tycho tests. That is where my initial guess was coming from that something blocked it on your machines.
I’ve tested again earlier with just installing the plugin on my machine from the update site directly and via the marketplace and both times the flags are set. I’m on Linux so I couldn’t 100% reproduce it. My other guess would macOS adding a quarantine flag or something like this? Both with an Eclipse installation done with my user and as sudo worked as expected.
Some more info about the Java version used to start Eclipse:
openjdk 21.0.2 2024-01-16 LTS
OpenJDK Runtime Environment Zulu21.32+17-CA (build 21.0.2+13-LTS)
OpenJDK 64-Bit Server VM Zulu21.32+17-CA (build 21.0.2+13-LTS, mixed mode, sharing)
I guess you have trouble to identify this as a valid Java 17+ runtime.
And this is why it is not affecting all users (I am using a Temurin distribution).
The problem was solved by setting the path to the java 21 installation in the Eclipse preferences (SonarLint node), but I would still say that:
The jvm detection code has some issue. We are sure that people have at least Java 17 since otherwise Eclipse 2024-06 would not start.
Maybe building a custom Eclipse with Maven Tycho is breaking the execution flag (needs to be investigated)
I asked somebody else that has trouble and he has 21.0.2-librca
openjdk 21.0.2 2024-01-16 LTS
OpenJDK Runtime Environment (build 21.0.2+14-LTS)
OpenJDK 64-Bit Server VM (build 21.0.2+14-LTS, mixed mode, sharing)
I have asked my colleagues (one is using macOS the other one Ubuntu) to check the value of java.home and eclipse.vm
Help menu > About entry. And then [Installation details] button and then in the configuration tab, filter for the value
I hope this will reveal why the JavaRuntimeUtils.getJavaRuntime() is not working for them.
Regarding tycho I am even more confused. I have pushed something that is really close to what we are internally doing here:
I think we are then storing the zip created in the target/products folder and pushing those to a file bucket. I have tried to expand the linux.gtk.x86_64.zip and from what I can tell the execution flag is correctly set… So it might be something else (later in the install process).
Thanks for reaching out to your colleagues. In the meantime, I created a ticket, SLE-931, to examine the Java runtime detection again. I will take the repo into account. I ran it on Linux, and it contained the executable flags for me as well. Even after zipping and unzipping.
But due to planned vacation it won’t be part of today’s release or the one of next month.
We also look into updating the troubleshooting docs side to add the info to add the executable flag so users can help themselves first.
They are using SDKMAN! which create a link named “current” for the default installation. I am using it as well, but my default is pointing to Java 8, so I always switch to an explicit java version before starting Eclipse.
On my machine /___user.home___/.sdkman/candidates/java/ contains:
11.0.17-tem
11.0.18-zulu
17.0.5-tem
21.0.1-graalce
21.0.2-tem
8.0.352-tem
current -> 8.0.352-tem
It seems that java.home resolves the link, but eclipse.vm contains the path as it was provided.
Values of the user where your detection does not work:
But for the specific zulu case on macOS that has this Contents/Home suffix, the condition “eclipse.vm” starts with “java.home” will never be true
thanks for the reply and sorry for the late reply.
Thank you very much for the input; I updated the ticket and will tackle it in next week’s hardening by relying on .toRealPath(). If it is okay with you, then I will tackle it first and share a dogfooding artifact of SonarLint for Eclipse with you?
