For me I think Istvan's plan is also acceptable. So in conclusion, we should
1. Jump to JDK11/JDK17(we could start a new thread to discuss this, maybe also on the user mailing list) 2. Claim and also make sure 3.x does not work with JDK8 3. Introduce a policy to only allow JDK8 features on master and branch-3.x for a while(maybe still keep the release version as 8?) Any other suggestions? Thanks. Istvan Toth <st...@cloudera.com.invalid> 于2024年4月30日周二 12:45写道： > > 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> > ------------------------------ > ------------------------------
