I’m a fan of moving forward and accelerating our cadence of adoption, if that’s possible. Much of our performance-critical code relies on features deprecated after JDK8. We need to see if those use-cases are adequately supported by JDK17 or some later version.
For the curious, we hide those use cases in the hbase-thirdparty repo, in the hbase-unsafe module. Thanks, Nick On Mon, 29 Apr 2024 at 19:22, rajeshb...@apache.org < 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. >
