this is a continuation of the previous discussion in this thread. As discussed there I am opening a new thread to increase visibility and to more easily allow other people to weigh in on this.
This presents a major issue for us. As previously stated this means we would have to change the whitelist of our anti-virus solution for every SonarLint update. With this I don’t see us upgrading to 10.x anytime soon. And even when we do, I doubt we will then regularly update to the next minor release. Unless the new version contains critical bugfixes/features, this would simply require too much effort for little gain.
Also maybe you could clarify what that means for updates: Is the JRE redownloaded for every SonarLint update, even if it is completely unchanged from the previous version?
While I appreciate the commitment, this would then effectively force all users to update to the newest version or take the risk of using a vulnerable JRE. So it would no longer be possible to wait until e.g. a bug is fixed or a new feature is implemented before updating to a newer version.
Provide the JRE as an additional plugin: The JRE is no longer a direct part of the SonarLint plugin, but instead provided via an additional plugin. This would provide a constant installation directory for the JRE at least as long as it remains the same version. It would also allow you to distribute security updates for the JRE independent of the main SonarLint plugin. So users who want to stay on an older SonarLint version, would not have to use a vulnerable JRE.
Allow advanced users to specify a custom path: Advanced users can set a path to a compatible JRE via a system property. This means those users would stay in full control over all installed JREs.
In conclusion while I understand the reasons for this change, I don’t think the current solution is optimal yet.
thank you for providing more input on the topic, this is really valued!
I will take all the points with me and get an internal discussion running regarding this as it will impact other SonarLint flavors as well. Additionally, I’ll take a closer look at how we can make it more pleasant for you without changing the architecture too much, which is not feasible on short notice. For the ticket that is based on this discussion and will be tackled on short notice, see below.
From your answer I suspect that you also don’t use JustJ for the Java runtime of Eclipse. We took more or less the same approach they did for bundling JRE. They also are updating their plug-in (JRE) leading to the same “issues” we have.
So yeah: When we update SonarLint, we update the fragment containing the JRE, which might not change the JRE version itself. I see the point you have on this being not ideal.
The issue with us not bundling a JRE into SonarLint would mean that SonarLint won’t work with some users and we want to provide users with an out-of-the-box solution that just works when they run it.
But, I see that we might have missed the power users in that case (like you) that want to have more control over their environment. Even though I cannot offer you the option of the WWW approach with the JRE being split from SonarLint itself (for now, never say never), I could offer you the second option where a user can configure a specific JRE to be used. That is, in your case, under your control.
I’ve created THIS ticket to tackle it definitely for the next release. Once this is done and released, I’ll also let you know!
Following this, I would suggest you wait before updating. But once SonarLint provides the option to make use of a user-controlled JRE, I would be grateful if you would give it a try and either update eventually for all your users or provide us with more feedback that we can then take into account when developing and evolving SonarLint even further. In SonarLint we follow the approach of incremental improvements based on the users’ feedback.
Thank you very much for your input! If you have anything you want to come back to or comment on, just get back to this thread. There is no need to mark it as a solution yet
thank you for the quick reply. This does indeed sound like a promising solution to our problem.
I’ve got one follow-up question though: Will SonarLint require strictly a Java 17 JRE or will any JRE > 17 work? Since we are currently using Java 21 for Eclipse and SonarLint works just fine, I am guessing it will be the latter.
ah sorry to be a bit unclear about it. We require at least Java 17, so Java 21 should be fine as well but I cannot give you a 100% answer on that as I don’t fully follow what changed between these versions. I only know we don’t rely on deprecated API. But it should work, at least worth giving it a try then.
So yes you’re right, providing Java >= 17 is your correct assumption.
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!
