I also agree that mitigation of security problems in dependencies will be increasingly difficult, as we cannot expect our dependencies to continue to support Java 8. They might, but as time goes on it is less likely.
A minimum of Java 11 makes a lot of sense. This is where the center of gravity of the Java ecosystem is, probably. A minimum of 17 is aggressive and I don’t see the point unless there is a feature in 17 that we would like to base an improvement on. > On Apr 29, 2024, at 1:23 PM, chrajeshbab...@gmail.com wrote: > > Hi! > > With 3.0 on the horizon, we could look into bumping the minimum required > Java version for HBase. > > The last discussion I could find was four years ago, when dropping 8.0 > support was rejected. > > https://lists.apache.org/thread/ph8xry0x37cvjj89fp2jk1k48yb7gs46 > > Now it's four years later, and the end of OpenJDK support for Java 8 and 11 > are much closer. > (Oracle public support is so short that I consider that irrelevant) > > Some critical dependencies (like Jetty) have ended even regular security > support for Java 8. > > By supporting Java 8 we are alse limiting ourselves to using an already 10 > year old Java release, ignoring any developments in the language. > > My take is that with the current dogmatic emphasis on CVE mitigation the > benefits of bumping the required JDK version outweigh the benefits even for > the legacy install base, especially it's getting harder and harder to be > CVE free with Java 8. > > Furthermore, with RedHat dropping JDK11 support this year, I think we could > also consider bumping the minimum requirement straight to JDK 17. > > Hadoop is still on Java 8, but previously it has dropped Java 7 support in > a patch release, and I wouldn't be surprised if it dropped Java 8 in a > similar manner, so I would not put too much stock in that. > > What do you think ? > > Thanks, > Rajeshbabu.
