Although I'm not a committer and mostly not that active on the HBase list I think I can share some valuable information/ideas:
"Only if a post 8 language feature becomes compelling should there be any need to move up the bytecode compatibility line. Any thoughts there. I can’t think of a one. Eventually the value types work might be worth it." I believe JDK 8-11 version change should happen when major version update is done. HBase 3.0 would be a good opportunity, after that HBase 4.0. Between them it would be unfortunate and if possible it should be avoided. (Accumulo did it between 1.9.3 and the not yet released 1.9.4, and between 2.0 and the future version of 2.1. I would not say that was the best idea for supportability.) Dropping Java8 support would simplify testing and accelerate JDK11 adoption. Would be useful to discuss the plans of other components (ZooKeeper, Hadoop, Phoenix) to see what are their plans for dropping JDK8 support. "When you run ZK 3.4’s test suite on 11 about 40% fail." Zookeeper team did solve JDK11 support for ZooKeeper 3.4.x, but it's time to forget it for ever. ZK 3.5.7 (the second bugfix version of stable 3.5.x) got released 2 days ago, 3.6.0 is at the second rc and planned to be released soon. Hadoop trunk is on ZK 3.5.6. If HBase 3 drops Hadoop 2 support it's time to drop ZK 3.4 support too. JUnit 5. JUnit 4 is for JDK 7, so cannot use any newer Java feature in it. Migration to JUnit 5 is working well, thanks to the junit-legacy package no need to do a big bang migration, it can be done step-by-step. Regards, Tamaas On Mon, Feb 17, 2020, 18:57 Andrew Purtell <andrew.purt...@gmail.com> wrote: > I share this concern. > > I recommend we build on 8, so can run on any 8 or later runtime, and test > on 11 or whatever the desired next advertised version of the runtime will > be. Builds and unit tests would execute on 8, then whole stack integration > tests on 11 (like ITBLL). > > Only if a post 8 language feature becomes compelling should there be any > need to move up the bytecode compatibility line. Any thoughts there. I > can’t think of a one. Eventually the value types work might be worth it. > > There may be differences in runtime, like we’ve seen historically. So far > we have managed to navigate them just fine by being careful or porting in > appropriately licensed support to our own util packages. I would expect > this to continue to be possible. > > > On Feb 17, 2020, at 6:41 AM, 张铎(Duo Zhang) <palomino...@gmail.com> > wrote: > > > > For me the only concern is the JDK11+. > > > > As long as lots of big company are starting to make their own OpenJDK8 > > releases(like AdoptOpenJDK from redhat, and corretto from Amazon, and so > > on), at least a big part of java world will still be on JDK8, this means > we > > still need to run HBase 2 for a very long time? > > > > Lars Francke <lars.fran...@gmail.com> 于2020年2月17日周一 下午6:45写道： > > > >> Sean, > >> > >> you didn't have any explicit questions or request for feedback in your > mail > >> so I'll just say that from my point all the points from your mail make > >> sense to me and I'm +1 on all of them. > >> > >> - Timeline (GA December/January) > >> - Start of shorter release cycle > >> - Rolling upgrade > >> - JDK11+ > >> - Hadoop 3 only > >> - No more Log4j 1 > >> - Minimize Hadoop needs > >> > >> Thank you for starting this process! > >> > >>> On Sat, Feb 15, 2020 at 2:55 AM Sean Busbey <bus...@apache.org> wrote: > >>> > >>> Hi folks! > >>> > >>> Consider this the start of my release manager duties for HBase 3.0.0. > >>> > >>> HBase 2.0 started alpha releases in Jun 2017 and went GA in April > >>> 2018. I'd like to start alpha releases for HBase 3.0 next week and aim > >>> for a GA in December or January. > >>> > >>> As RM, I consider the alpha releases a chance for folks to shake > >>> things out and for us to decide as a community what makes it in or not > >>> for the release line. Once things start being labeled beta, I would > >>> like things to be feature frozen. My current goal is to set beta in > >>> May or June. > >>> > >>> I would like HBase 3.0 to be the start of us getting into practice on > >>> tighter iteration cycles for major versions. 2.5 years is too long. We > >>> should try to look at our version numbers as akin to Linux kernel > >>> version numbers. Something useful to those interested in the internals > >>> of the project but not something where most downstream users have to > >>> dread major bumps. To that end I would like HBase 3.0 to be rolling > >>> upgradable from HBase 2.y at GA. Ultimately, I would like to update > >>> our reference guide's section on compatibility to state that future > >>> major releases will similarly be rolling upgradable from some minor > >>> release of the prior major release line. > >>> > >>> Given my desire to make major upgrades less of a world changing event > >>> for our downstream folks, I also don't have any new features that I > >>> feel strongly need to make it into HBase 3.0. I'll do a review of > >>> what's currently there so we can motivate folks, but I won't do that > >>> until we're ready to declare beta since that will be when I'll have a > >>> better idea of what's actually ready to ship. > >>> > >>> With the major version change I'd like us to shed some maintenance > >>> burden in the project. For each of these, doing that will require > >>> getting a branch-2 release out that can successfully opt-in to the > >>> HBase 3 requirement and run on the current HBase 2 requirement. That > >>> way folks can do a rolling restart within HBase 2 to make the change, > >>> then do a rolling upgrade to HBase 3. > >>> > >>> = Hadoop 3 only > >>> > >>> The Hadoop community's focus increasingly is on Hadoop 3.y releases. A > >>> substantial amount of our dependency handling is tied to trying to > >>> span both Hadoop 2 and Hadoop 3. I would like us to drop Hadoop 2 > >>> entirely. I think branch-2 is currently in a place where running on > >>> Hadoop 3 is reasonable. > >>> > >>> = JDK11+ > >>> > >>> We've been bending over backwards on jdk versions for a while. Maven > >>> build sets up for multiple jdk builds are a PITA and our existing > >>> build is already too complicated. I'd like us to get branch-2 into a > >>> solid state for running on either JDK8 or JDK11 so folks can do > >>> production upgrades on those releases. I'd like HBase 3 to be jdk11+ > >>> only so that we can reduce our test footprint in the project and start > >>> to entertain features that don't work with jdk8. For example, we can't > >>> start to figure out how we should fit in the module system as things > >>> are. > >>> > >>> = No more Log4j 1 > >>> > >>> We got through 95% of the work to make our logging system pluggable, > >>> but we still ship with log4j 1 as the out of the box solution. I want > >>> HBase 3 to ship with some other slf4j backend and I want that same > >>> backend to be a realistic option for branch-2 users to deploy in > >>> production. > >>> > >>> = Minimize Hadoop needs > >>> > >>> I would like to isolate the things we have that reach into Hadoop > >>> internals so that we can ease the logistics of changing the Hadoop > >>> version we run on and minimize the extra stuff we carry around for > >>> those who don't run on Hadoop at all. This will involve moving the > >>> stuff we have that reaches into internals into one or more module(s) > >>> and updating our artifacts so that we can tell where our hadoop > >>> related dependencies are in an installation. > >>> > >> >
