I don’t expect 2.x to wind down for up to several more years. We will be still using it in production at my employer for a long time and I would continue my role as RM for 2.x as needed. HBase 3 is great but not GA yet and then some users will want to wait one to a couple years before adopting the new major version, especially if migration is not seamless. (We even faced breaking changes in a minor upgrade from 2.4 to 2.5 that brought down a cluster during a rolling upgrade, so there should be no expectation of a seamless upgrade.) My plan is to continue releasing 2.x until, like with 1.x, the commits to branch-2 essentially stop, or until the PMC stops allowing release of the candidates.
Perhaps we do not need to do a total ban on use of 11 features. We should allow a case by case discussion. We can minimize their scope and even potentially offer multiversion support like we do with Unsafe access utility classes in hbase-thirdparty. There are no planned uses of new 11+ APIs and features now anyhow. On Tue, May 7, 2024 at 7:40 AM 张铎(Duo Zhang) <palomino...@gmail.com> wrote: > 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> > > ------------------------------ > > ------------------------------ >
