Spotbugs: Support running under Java7

[jsotuyod]

The JRT FS code for Java 9 uses lambdas, which forced to raise the min JRE from 7 to 8. However, all other needed APIs are present in Java 7.

Turning those lambdas back into anonymous classes would allow to keep SpotBugs running in JRE 7, 8 and 9 (of course, actually being able to load a JRT FS needs JRE9). This would leave no one behind if they want to switch to SpotBugs at least in the immediate future (FindBugs 3.0.1 requires JRE7+).

Future releases may take advantage of JRE 8, but for the time being JRE7 is probaly the sanest.

@iloveeclipse is there any other reason for the version bump I may be missing?

[iloveeclipse]

Please stop here. Supporting Java 7 is definitely nothing worth the effort. If someone can't run latest FB on Java 8, there are still old FB versions. Maintaining code for this old Java release just cost time, and time is what we do not have.

[jsotuyod]

I don't think that is the right approach to this conversation.

Before even thinking of effort / time, we should be considering what's the best for our users and the product as a whole.

The way I see it, keeping JRE7 support has some interesting advantages:

• It makes moving from FindBugs to SpotBugs a no brainer. No strings attached, no conditions, just drop in the replacement lib.
• It maximizes momentum to migrate. Allowing everyone to migrate now will probably see a better adoption than having people stuck on old projects and then having to remember to switch if they ever bump their JDK.
• It keeps in line with our proposal to remain binary-compatible with FindBugs, at least for version 3 of SpotBugs. Version 4 may be a different matter.
• It keeps providing value to Android users. Android has been stuck for quite some time on Java 6 + some Java 7 syntax sugar, meaning many developers are still using JRE7 (a battle I keep fighting within my organization for instance).
• It simplifies integration by third parties. Many tools that integrate FindBugs, such as Gradle require JRE7. Keeping JRE7+ means they can actually just drop FindBugs for SpotBugs almost seamlessly. Unit and integration tests can probably remain the same. Dropping JRE7 support makes the whole matter a lot harder on them, which again, works against user adoption.

I believe these are strong arguments in favor of keeping JRE7 which can't be lightly dismissed.

Having said that, we may now approach the planification for such work.

I'd agree doing this is certainly not as important as fully supporting JRE9 (which is alredy done), or Java 8 analysis (see #6), so in the order of priorities it's probably among the last ones. Still, it's an important part for the 3.1.0 milestone.

As for the effort, right now, changing existing lambdas to anonymous classes is a 5 minute change (there are only 2 lambdas in the whole source code, both on JrtfsCodeBase.java). Adding JRE7 to Travis and changing the build.xml files to build on JRE7 can probably be done within an hour. Nothing I'm not willing to do.

There is however, another effort cost, that is the "opportunity cost" of not being able to use the syntax sugar Java 8 provides (lambdas, default methods). This can be partly recovered by eventually adopting RetroLambda. It's not perfect (we wouldn't be able to use the new default methods in collections for instance, since those are not present in JRE 7), but we would be able to use those language features on our own code in a forward compatible way (we can drop RetroLambda and JRE7 support at any time with no code changes). Once again, this would only be needed for the SpotBugs 3.x releases. For SpotBugs 4.x we can asses again if JRE7 support still makes sense (certainly, the final release on JRE9 in late July 2017 will help in pushing for a drop).

I'd love to hear your and @mebigfatguy's opinion too.

[iloveeclipse]

I've asked this question on the mailing list and not a single user answered "please keep Java 7".
Again, every second more I need to spend on the supporting Java 7 is a second too much.
Java 7 users should use FB 3.0.1. Period.

If they want shiny new features they should update the JVM they use for running FB. For me this discussion is going into nowhere because there are simply no resources for supporting obsoleted JVM's.

[mebigfatguy]

there are unfortunately a huge number of (corporate) people running java 7. I wish it were not the case. Given that java 7 is well past End of Life, tho, at this point our support for java 7 is like we are enablers of bad processes. So i'd probably vote 8 min as well. But, i'm not going to kick and scream about it.

[jsotuyod]

Ok, everyone actively participating on this project seems to be in favor of killing JRE 7 support. I won't fight you. Thanks to everyone for sharing their opinions.