Spring is a good argument for JDK17. Duo's suggestion is a great step forward, firmly stating that JDK8 is not officially supported solves most of our expected future CVE problems.
However, I think that ripping off the bandaid, and making sure that HBase 3 does not work with Java 8 would be better. It's easier to accept such a change in a major version than in a minor version. IMO users that are so conservative that they are still using Java 8 are unlikely to be first movers to a new major release anyway. I think that the following upgrade path would optimal: - User stays on (supported) Hbase 2.x until ready to upgrade Java - User upgrades to Java 11/17 with the same HBase - User upgrades to Hbase 3.x As noted, we will need to support 2.x for some time anyway (just like 1.x was supported for a long time). As for the backporting issues: We could make it a policy to avoid using Java 11+ features in Hbase code until 2.x supports winds down. This has worked quite well for Phoenix with Java 7 / Java 8. On Tue, Apr 30, 2024 at 3:59 AM 张铎(Duo Zhang) <palomino...@gmail.com> wrote: > AFAIK spring 6 and spring-boot 3 have jumped to java17 directly, so if we > want to upgrade, I also suggest that we jump to java 17 directly. > > While upgrading to java 17 can reduce our compatibility work on branch-3+, > but consider the widely usage for java 8, I think we still need to support > branch-2 for several years, then this will increase the compatibility work > as the code between branch-3+ and branch-2.x will be more and more > different. > > So for me, a workable solution is > > 1. We first claim that branch-3+ will move minimum java support to 11 or > 17. > 2. Start to move the compilation to java 11 or 17, but still keep release > version 8, and still keep the pre commit pipeline to run java 8, 11, 17, to > minimum our compatibility work before we have the first 3.0.0 release. > 3. Cut branch-3.0 and release 3.0.0, so we have a 3.0.0 release, actually > which can still run on java 8, so it will be easier for our users to > upgrade to 3.x and reduce our pressure on maintaining branch-2, especially > do not need to back port new features there. > 4. Start to move the release version to 11 or 17 on branch-3+, and prepare > for 3.1.0 release, which will be the real 11 or 17 only release. > > Thanks. > > Bryan Beaudreault <bbeaudrea...@apache.org>于2024年4月30日 周二02:54写道： > > > I am a huge +1 for dropping java8. > > > > One reason I would suggest going to 17 is that it seems so hard to change > > these things given our long development cycle on major releases. There > are > > some nice language features in 17, but more importantly is that the > initial > > release of java11 was released 6 years ago and java17 released 3 years. > > Java21 is already released as well. So I could see java17 being widely > > available enough that we could jump "in the middle" rather than to the > > oldest LTS. > > > > I will say that we're already running java 21 on all of our hbase/hadoop > in > > prod (70 clusters, 7k regionservers). I know not every organization can > be > > that aggressive, and I wouldn't suggest jumping to 21 in the codebase. > Just > > pointing it out in terms of basic support already existing and being > > stable. > > > > On Mon, Apr 29, 2024 at 2:33 PM Andrew Purtell <andrew.purt...@gmail.com > > > > wrote: > > > > > 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. > > > > > > -- *István Tóth* | Sr. Staff Software Engineer *Email*: st...@cloudera.com cloudera.com <https://www.cloudera.com> [image: Cloudera] <https://www.cloudera.com/> [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera on LinkedIn] <https://www.linkedin.com/company/cloudera> ------------------------------ ------------------------------
