Require jdk 11 or 17 to use spotbugs

[hazendaz]

Considering that we are less than 2 months from LTS for jdk 21 and many larger firms are in fact dropping jdk 8. Further JakartaEE next is jdk 21 only, Tomcat next is jdk 21 only, Spring boot is jdk 21 without commercial support in November, and many plugins now already require jdk 11 and further some are gong to jdk 17. Some other libraries are doing same.

[iloveeclipse]

I miss third option: move straight forward to Java 17, which is current LTS release.

[ThrawnCA]

I haven't been much involved in Java development of late, but OpenJDK 8 still has years left before it goes out of support. How difficult is it to keep?

[hazendaz]

OpenJDK 8 is end of life in 2026 and with RHEL 9 they are not shipping it as default but rather jdk 11. Any big company isn't going to use openJdk 8 for production usage. I believe all vendors at this point that build jdk 8 have announced end of life dates in line with openjdk.

[iloveeclipse]

It depends. I would argue,

• if someone needs Spotbugs on Java 8, old releases can be used.
• If someone needs latest Spotbugs on Java 8, this someone should consider to contribute to the project.
• Switching from Java 8 to 9+ is a major pain. Switching from 11 to 17 is much easier, the only major problem is missing Nashorn engine.
• So most of the people should be able to switch from 8 to 17 if they would be able to switch from 8 to 11.

[hazendaz]

Agreed Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Andrey Loskutov ***@***.***> Sent: Monday, July 24, 2023 1:29:03 AM To: spotbugs/spotbugs ***@***.***> Cc: Jeremy Landis ***@***.***>; Author ***@***.***> Subject: Re: [spotbugs/spotbugs] Require jdk 11 or 17 to use spotbugs (Discussion #2482) It depends. I would argue, * if someone needs Spotbugs on Java 8, old releases can be used. * If someone needs latest Spotbugs on Java 8, this someone should consider to contribute to the project. * Switching from Java 8 to 9+ is a major pain. Switching from 11 to 17 is much easier, the only major problem is missing Nashorn engine. * So most of the people should be able to switch from 8 to 17 if they would be able to switch from 8 to 11. — Reply to this email directly, view it on GitHub<#2482 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAHODI5H3JH3EJ7RMKXQZQTXRYBZ7ANCNFSM6AAAAAA2T67LCE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[gtoison]

Dropping support for JDK 8 (or even 11) should be in a new major version so it's easier for users to pick the right version
Even if that's the only change, it should be SpotBugs 5

[iloveeclipse]

should be in a new major version so it's easier for users to pick the right version

Not sure I understood the reasoning. Why should it be "easier" and what is "right" version? Could you elaborate?

[gtoison]

I suspect that many people pay more attention to the release notes when the major version changes, and probably upgrade without checking in other cases.
So a breaking changing like dropping support for JDK 8 would be better in a new major version.
Users who want to remain on JDK 8 would need to remain on the last 4.x version (the "right" version for them)

Unless I misunderstood, it should also be clear that the change is for the JDK running SpotBugs itself and that SpotBugs can still analyse Java 8 bytecode

[iloveeclipse]

Unless I misunderstood, it should also be clear that the change is for the JDK running SpotBugs itself and that SpotBugs can still analyse Java 8 bytecode

Sure.

[hazendaz]

Still not many votes but think this is our plan. Maybe outsiders don't get to see discussions or haven't been concerned to look 👍

4.8.0 -> still jdk 8 with all we have now and whatever trivial stuff we are still working on.

5.0.0 -> jump to jdk 11, do all the work we need to do throughout to be really jdk 11 and not just symbolic. This will include getting to a far newer Eclipse version that isn't 4 to 5 years old. (should be noted Eclipse requires jdk 17 as is now and likely will jump to 21 shortly so we might want to consider breaking out the eclipse plugin to keep in line with them). Think we will be busy here for a while.

6.0.0 -> jump to jdk 17, and do all similar work there.

At least in my firm, we are getting ready to dump jdk 8 from all platforms in next month (so we claim...lol). Our builds in my line of business are roughly 90% jdk 17 already (note builds not runtimes). The rest are jdk 11 outside of a handful (less than 10) on jdk 8 and we are working to get them all to 17. We do however already require any users of our super pom be on jdk 11 at least for last 2 years and plan to require jdk 17 or above only at end of the year. I suspect this is somewhat representative of the industry as a whole and we do have quite a number of legacy items that in some cases predate maven existence that will build with jdk 17, just won't run with it. For context, my line of business we support about 2k separate projects running on maven for which I gather this data.

With that said, we will still be able to scan older uses, its just that we will require newer to build with. Further, we could backport if needed. I'd say we at least initially try not to. I'd suspect as slow as we have been going in getting actual release out, these targets are likely to cross over into early 2024.

[JuditKnoll]

The discussion under spotbugs/spotbugs - including this one - are available even without signing in to GitHub (checked it).
This plan could be documented to milestones.

[hazendaz]

adjusted the name on the 5.0 milestone based on history of milestones, added 4.8.0 and 6.0.0 with reference on respective runtimes for each.