I’ve noticed that after the release of SonarLint Version 10, the previous Version 9.3 is now no longer available in the Eclipse update site (https://eclipse-uc.sonarlint.org/). The archive site linked in the Github Readme (https://binaries.sonarsource.com/SonarLint-for-Eclipse/releases/) also does not contain any 9.x Version.
This presents an issue for us, since we are using the Eclipse Ooomph tool to define which plugins should be installed for every developers’ Eclipse. But since SonarLint Version 9.3 is no longer available in the update site, this installation process no longer works. Since Version 10 introduced some major changes (especially SLE-781) we do not yet want to update.
Is there any chance the Eclipse update site could be changed, so that the previous 9.3 version is available for installation again?
thanks for reaching out. First things first, it is intended for the Eclipse updated site to only provide the latest plug-in version in order for us to get feedback quickly on what was just released as well as older, specific ones for compatibility with IDEs stuck to older Java versions. We have no current plans to change this.
For older versions of SonarLint for Eclipse and how to get them, please take a look at the documentation page on that subject: Previous versions. We will not remove older versions but tend to suggest using the newest one, if possible. The previous versions are available as archives as well as update sites themselves.
I’m sorry to hear that you don’t want to update yet, would you please elaborate on that (e.g. you want to test it first, the rollout is not possible for reason xyz, etc.). This will help me as the main developer on SonarLint for Eclipse to understand your decision and maybe I can draw some conclusions based on that for future improvements.
Our main concern lies with SLE-781. As far as I understand this issue, SonarLint will now download and use a custom JRE separate from the one used by Eclipse. This leads to the following concerns:
- General security concerns: With this change every machine would now have an additional JRE installed, which is outside our direct control (i.e. the version you bundle could have vulnerabilities)
- Performance concerns: The JRE used by our Eclipse instance is specifically whitelisted in our anti-virus solution. This change means we would have to whitelist the new JRE too or potentially face performance issues when using SonarLint. In order to whitelist this new JRE we also require additional information about it: Where will this JRE be downloaded to? Will this path remain constant between different versions or could it potentially change every update? (Meaning we would have to adjust the whitelist for every SonarLint update)
- Additional testing: Since this seems to be a major change in the way SonarLint works, we want to properly test it before we roll it out to every developer.
i know that i am not the OP, but … if i saw the following correctly, then please advise how to continue:
OP has asked for availability of a 9.x sonarlint installation
Initial question was successfully solved while also asking a followup question
Thread was marked as solved
Thorough answer to the followup question was delivered by OP
In my (admittedly rather pessimistic) expectation, now this thread will lie dormant until a week passes, then noone can reply any more.
Maybe i am wrong, then please excuse my pressing demeanor. But … i, too, am eyeing the voiced concerns, since i read about SLE-781, and could potentally also see my own troubles with this.
Do you expect us to raise these concerns again in a separate topic? Maybe it might help, if you’d split this off, as the 7-Days reply period has already started ticking?
thank you for your response, I’d like to offer you some answers to your questions. The first thing I noted down is for us to improve the documentation about where it is stored, what will change on an update, and so on.
Yes there will be a new JRE bundled with SonarLint from now on: I see your point and for now, I can only assure you that we on our side make sure that the JRE does not have vulnerabilities. If at some point there is a vulnerability found with the JRE, we will provide an update to SonarLint with a JRE bundled not vulnerable.
I’m aware of cases like your strict environment so here is as much information as possible I can provide to you:
The JRE is coming via an Eclipse plug-in fragment, so it is downloaded when you download SonarLint and not afterward or at runtime. The JRE 17 being platform-specific, it is stored in the IDE installations’ Eclipse plugin directory in the folder org.sonarlint.eclipse.sloop.{OS, e.g windows}.{architecture, e.g. x64}_{plug-in version}
alongside libraries and our script starting the SonarLint part that is out of process.
Therefore, the path will be changing with every update, but the JRE inside of it might not.
We provide a JRE with SonarLint for Windows x64, macOS x64/aarch64, Linux x64/aarch64. For all other platforms we don’t ship a JRE and will rely on the user providing one.
For your testing, could you please reach out (via a new thread please), if you encounter something breaking or something blocking? That would be much appreciated.
Also for additional questions, don’t hesitate to reach out to us!
by default it is one topic per thread, if you encounter the exact same thing or have something very related, just comment in the thread.
Otherwise please open a new one, we will be triaging them and may decide to merge the threads together as we please.
For this thread, the 7-day period is ticking down. If you have your concerns bundled together, please open a new thread and share it there, maybe link them.
I just wanted to let you know that we released a new version of SonarLint for Eclipse (10.0.1) where you are able to configure your own Java 17+ runtime to run the part of SonarLint out of process.
This will be done via the preferences page on the workspace level or, for power users, via importing preferences (see the section Importing and Exporting Preference Settings) where this can be configured on the application level or workspace level for easier rollout to your users.
Please get back to me if you encounter anything not working correctly!
