Spotbugs 5.0.0: Change Java version of SpotBugs to Java 11

[baloghadamsoftware]

The only change needed to build SpotBugs using Java 11 instead of Java 8 is (beside changing the version in the Gradle files) in a single Java source file. All tests are passing.

---

Make sure these boxes are checked before submitting your PR -- thank you!

• Added an entry into CHANGELOG.md if you have changed SpotBugs code

[hazendaz]

HI @baloghadamsoftware This is likely where we will go but lets wait a bit longer to see if anyone real participation in the vote. The vote right now is only 4 people and leaning jdk 17 which IMO could be too much. So I'd like to see a bit more votes.

[JuditKnoll]

I think this could be added to the Next Breaking Changes for v5.0.

[ijuma]

As a user of spotbugs in both open-source (Apache Kafka) and proprietary projects, I think it would be reasonable to bump the minimum Java version to 11 for spotbugs 5.0.0. I think it would be super helpful for Java 21 support (#2567) to be added to the 4.x release though - that should tide people over.

[hazendaz]

@ijuma As noted on other thread, support is already there, we simply have not released yet. Please override as now fully shown there in meantime. If you like send a PR to the gradle plugin to override so users don't have to, that one is easier to release.

[Vest]

Excuse me for pinging this thread. Do you have a theoretical timeline, when SpotBugs 5.0 will be released?
I am holding my project in Java 17, and even with it, I have difficulties with Gradle+SpotBugs :(
Thanks.

[hazendaz]

@Vest You shouldn't be having issues with java 17 and spotbugs. Its fully compatible as-is.

[soloturn]

@hazendaz it is not compatible with java-21 though:

  Unable to get XClass for org/terasology/benchmark/entitySystem/jmh_generated/IterateComponentsBenchmark_iterateSingleComponent_jmhTest
    java.lang.IllegalArgumentException: Unsupported class file major version 65
      At org.objectweb.asm.ClassReader.<init>(ClassReader.java:199)
      At org.objectweb.asm.ClassReader.<init>(ClassReader.java:180)
      At org.objectweb.asm.ClassReader.<init>(ClassReader.java:166)
      At edu.umd.cs.findbugs.asm.FBClassReader.<init>(FBClassReader.java:35)

[JuditKnoll]

@hazendaz it is not compatible with java-21 though:

  Unable to get XClass for org/terasology/benchmark/entitySystem/jmh_generated/IterateComponentsBenchmark_iterateSingleComponent_jmhTest
    java.lang.IllegalArgumentException: Unsupported class file major version 65
      At org.objectweb.asm.ClassReader.<init>(ClassReader.java:199)
      At org.objectweb.asm.ClassReader.<init>(ClassReader.java:180)
      At org.objectweb.asm.ClassReader.<init>(ClassReader.java:166)
      At edu.umd.cs.findbugs.asm.FBClassReader.<init>(FBClassReader.java:35)

Until the release of 4.8.0, you can use a simple workaround described in #2567 to make it work with java 21.

[hazendaz]

Given we are still trying to stabilize spotbugs after long time with no releases, I've pushed out expectations for when we go to java 11 requirement until January. I'm hoping by then we do something about this constant 'changelog' being a blocker to mergers that it is. However, just wanted to give heads up as we have not forgotten about this.

[hazendaz]

Believe winner will be jdk 17 but considering we are still fiddling around with this, I think we will do a lot of code cleanup still on java 8 usage as we have found it needs some more love. We likely will drop a jdk 11 so we don't lose everyone then follow that with jdk 17 after since most consider just going there. So this will continue to delay for a while I think. We are getting ready for 4.8.4 release, after that I plan to do deep dives myself to cleanup common issues in our code base I found in one module while doing other work and I'm sure we possibly will still get in a number of fixes as well as trying to continue to reduce our overall issues - many of which are starting to appear already done. This will allow us to not lose those unfortunately stuck on java 8 as quickly. I'll adjust the milestone out further once we have a better idea.

[hazendaz]

Converted to DRAFT for now.

[hazendaz]

What does team @JuditKnoll @iloveeclipse @gtoison think about cutting the cord here and just doing this on the next release here and bumping up our version to reflect java 11 now. So may other projects are now moving it only makes sense we go ahead and do this.

[gtoison]

I think we should release 4.8.4 (there are quite a few fixes and improvements), and then move on to the breaking changes with 5.0.0

[iloveeclipse]

think about cutting the cord here and just doing this on the next release here and bumping up our version to reflect java 11 now.

I personally think we should go straight forward to Java 17. There is no reason to keep on Java 11, Java 21 is LTS and there already, but there are lot of possible improvements / features we can get from updated JDK!

• Helpful null pointers
• Switch expressions
• Records
• Pattern matching for instanceof

I think we should release 4.8.4 (there are quite a few fixes and improvements), and then move on to the breaking changes with 5.0.0

Yes. And I would really don't want to wait for 6.0.0 just to switch to Java 17, so ideally 5.0 would be Java 17 based.

[JuditKnoll]

There are plenty of fixes, and already a few month passed since the last release. I think the next release should be 4.8.4, without upgrading the required minimal JDK to Java 11 or other breaking changes.
IMO it would be best if 5.0.0 contained minimal changes other than the Java version upgrade and other breaking changes, but it could be released not long after 4.8.4, maybe in a month. Maybe that could help if we had a branch kept up-to-date with master with the planned breaking changes in 5.0.0 (or just cause unnecessary overhead).
I think 5.0.0. could be a switch to Java 11, and later 6.0.0 to Java 17, if we not wait for the release of 6.0.0 so much.

[hazendaz]

So if thinking in same line you are @JuditKnoll, I think we are ready to cut 4.8.4, cut a branch from there for support fixes, then move this to master as part of 5.0.0 and outside of any issues we need to fix, limit working on bringing code up to java 11 standards in general and then cut that. Then do basically same thing and then move to 17. Everything is really going to 17 but that would limit us to trying to cleanup the repo to the respective versions. That is my thought anyways.

If nothing else, I think we are well overdone for getting 4.8.4 out and seems like a lot of false positive fixes many would benefit from. Plus personally I don't want to patch the maven plugin again just to get the groovy update here as groovy has been somewhat problematic in downstream usage unless all forced to same.

Anyway, I did open this discussion #2880 and I know I've kicked the can on the suggested dates many times already. If a few folks could just comment out there if we are ready to go then lets at least get 4.8.4 out....