I agree with Enrico on this point. If the ZK PMC is considering a 3.7 release, now would not be the right time to make this change, and it would be better to make a change at the beginning of the next iteration.
That said, I think switching to builds with JDK 11 and supporting JDK 8 "passively" is the right thing to do for 3.8, and switching to JDK 11 fully would be the right thing to do if the PMC decides to do a major version bump to 4.0 instead of a 3.8. On Wed, Jan 6, 2021 at 1:20 PM Enrico Olivelli <eolive...@gmail.com> wrote: > In my opinion we can stay on 8, we should change this kind of stuff at the > beginning of a new iteration and not before the release. > IIRC We are not in a hurry, having a stable build process is a value. > > Enrico > > Il Mer 6 Gen 2021, 17:51 Damien Diederen <ddiede...@apache.org> ha > scritto: > > > > > Dear ZooKeeper team, > > > > Andor just reminded me of this JDK 11 vs. 8 discussion, for which we did > > not reach a resolution. Do we want to make a move for the 3.7.0 release? > > > > The original proposal, by Christopher, can be found here: > > > > > > > https://mail-archives.apache.org/mod_mbox/zookeeper-dev/202010.mbox/%3ccal5zq9z2tnfawjz7etxpf91qmrovuwv+khnxgpsd_msekfp...@mail.gmail.com%3e > > > > I am explicitly replying to Christopher's nice and useful summary, which > > you will find directly below. An archived copy can be found here: > > > > > > > https://mail-archives.apache.org/mod_mbox/zookeeper-dev/202010.mbox/%3cCAL5zq9ao9-4S9bmzxaYJM8n8=aolxidz-0zohunvnayqei0...@mail.gmail.com%3e > > > > It contains three proposals, to which we can add the trivial one: > > > > 1. Compile/test with JDK 11, support JDK 8 "passively"; > > > > 2. Compile/test with JDK 11, test client only with JDK 8 (requires test > > suite adaptations); > > > > 3. Move to JDK 11 fully; > > > > 4. Postpone any change to 3.8 (or 4.0). > > > > Flavio wrote: > > > > > [Christopher] mentioned a PMC vote, and I don't think this should be a > > > closed vote, independent of how the conversation goes. > > > > Do we have a better idea of what we want? Or should we organize a vote? > > > > Cheers, -D > > > > > > --8<--------------- original message ------------->8--- > > > > Christopher <ctubb...@apache.org> writes: > > > I'm happy that this discussion has been so lively! I just want to > > > emphasize a few things: > > > > > > I really do understand the desire to continue to support Java 8... I > > > get it. But all the conversations around this seem based on what > > > people are doing *today*. But, ZK 3.7 is *tomorrow's* version... a > > > *future* release... so it should be based more on reasonable > > > expectations for users in the future, and less based on what is > > > happening today. I suspect *most* people today are still using 3.4 > > > anyway (it was just so stable for so long...), but that shouldn't mean > > > the developers should hold back development on 3.5 and 3.6, any more > > > than today's users of 3.5/3.6 should hold back 3.7. > > > > > > Some of the opinions expressed in this discussion seem to propose a > > > scenario where users are going to be updating to "bleeding edge" > > > versions of ZooKeeper, but are going to insist on using Java 8. > > > Personally, I find this to be implausible. In my experience, people > > > either upgrade everything as soon as they are able to, or they upgrade > > > each thing individually, only when they are forced to. The first group > > > will be happy to move to Java 11 and ZK 3.7. The second group will > > > probably avoid 3.7 anyway, and are fine sticking with 3.6, but if they > > > had to update to 3.7, they'd also be fine updating to Java 11 if they > > > had to in order to use 3.7. I can't imagine the scenario where people > > > are eagerly choosing to upgrade to ZK 3.7, but miserly insisting on > > > using Java 8. Perhaps that scenario exists, but it's hard for me to > > > imagine. Even so, my proposal would still support even that group of > > > people. > > > > > > I think there are now effectively three proposals being discussed in > > > this thread: > > > > > > 1. (Christopher's original proposal) passively support Java 8 at > > > runtime by making JDK 11 the minimum requirement to build and test. > > > This scenario involves continuing to fix bugs, as they are discovered > > > and reported, that affect JDK 8, but passively, rather than > > > proactively. This proposal does *not* drop Java 8 support, but merely > > > de-emphasizes it in development of what will be 3.7 in the future, and > > > drops the requirement to do dedicated testing with Java 8. I think > > > this is low risk, because it is very unlikely that the ZK devs would > > > introduce a bug that would affect only Java 8 and the compiler > > > wouldn't catch it... because the cross-compilation features of newer > > > JDKs are really good. > > > > > > 2. (Enrico's alternate proposal) this variation of my proposal would > > > involve continuing to proactively support Java 8 by creating a > > > dedicated testing suite to test client code on Java 8. I think this is > > > a good option, but since it involves a significantly higher amount of > > > work than option 1, I think the cost-benefit analysis would show this > > > to be not worth the effort. Also, if it were implemented, it would > > > need to be done carefully to avoid requiring developers to have > > > concurrently installed both Java 8 and Java 11 in order to perform a > > > build, because requiring Java 8 at build time while developing would > > > be worse than we have today. > > > > > > 3. (Andor's preference) move to JDK 11 fully. This would provide no > > > support, passive or active, for Java 8 in ZK 3.7. To be honest, this > > > is my personal favorite, and is the simplest to implement and > > > communicate clearly to end users in release notes. The only reason I > > > proposed a passive support of Java 8 instead of this is because I was > > > trying to seek a compromise from the start. But, I think by far, this > > > is the best option for the next *future* release of ZK. If you wanted > > > to make the change even more visible to users, the version could even > > > be bumped to 4.0. > > > > > > If this were to come to a VOTE by the PMC, in order to make a final > > > decision, I would recommend they vote on option 3, and then if that > > > fails, vote on option 1, and if that fails, keep things the way they > > > are (because option 2 is more work). > > > > > > Christopher > > > > > > P.S. as for Hadoop on Java 11... I've been running Hadoop 3 on JDK 11 > > > and it works just fine there (as long as you add the missing runtime > > > jar for javax.activation:javax.activation-api:1.2.0 to its class path, > > > but that was fixed in Hadoop 3.3). > > > > > > On Wed, Oct 21, 2020 at 5:42 PM Tamas Penzes > > > <tam...@cloudera.com.invalid> wrote: > > >> > > >> Hi All, > > >> > > >> I've just talked with a Hadoop/HDFS developer who told me what I > > guessed. > > >> With Hadoop3 they have just dropped JDK7 support, dropping JDK8 would > > mean > > >> a release of Hadoop4. > > >> Since HADOOP-15338 is finished, they test with JDK8 and JDK11 both. As > > of > > >> today most of the Hadoop users are still on Hadoop2, he doesn't expect > > >> Hadoop4 soon. > > >> As many Apache components depend on Hadoop and ZooKeeper they won't > > hurry > > >> to JDK11 until they have to (they will probably go one-by-one very > > slowly), > > >> which means if Hadoop stays on JDK8, they would use the last ZK > version > > >> which works on JDK8. > > >> Do we want a ZK 3.4 again? > > >> > > >> Regards, Tamaas > > >> > > >> > > >> On Wed, Oct 21, 2020 at 11:23 PM Tamas Penzes <tam...@cloudera.com> > > wrote: > > >> > > >> > Hi All, > > >> > > > >> > Just to add my two cents. > > >> > > > >> > Upgrading to JDK11 looks inevitable sooner or later and I would > > definitely > > >> > not wait until 2030 or 2026 when the extended support of JDK8 ends. > > >> > But on the other side I have to agree with Enrico and Patrick that > > far too > > >> > many users are tied to JDK8 yet (not because they want to use JDK8, > > but > > >> > because they have to), some of them are components of the Hadoop > > ecosystem, > > >> > which would be a loss to tie them to 3.6.x for years. > > >> > Do we know the state of Hadoop? It builds with JDK8 at the moment, > > but do > > >> > we know what are their plans to go to JDK11? > > >> > When they move, we should move too, but I don't think it would be > > wise to > > >> > do it earlier. > > >> > > > >> > Christopher's option looks like the golden path, but it needs some > > >> > investment on the testing side as Enrico pointed it out. > > >> > Could we agree on it as a compromise? > > >> > > > >> > Regards, Tamaas > > >> > > > >> > On Wed, Oct 21, 2020 at 7:11 PM Brent <brentwritesc...@gmail.com> > > wrote: > > >> > > > >> >> I think I was reacting to Enrico's earlier comment of: > > >> >> > > >> >> " ZooKeeper client is used by tons of users and unfortunately many > > >> >> projects > > >> >> are still on JDK8, if we move ZooKeeper to JDK11 the risk is to > block > > >> >> users > > >> >> from the adoption, that is that we will see the world to stay on > > 3.6.x and > > >> >> we will have again a long lived release line, like 3.4." > > >> >> > > >> >> It's a matter of whether or not a long-lived release line is > > >> >> desirable/undesirable. If everyone is OK keeping 3.6.x up-to-date > > >> >> security/patch-wise (if not feature-wise) for the next N years, > then > > >> >> that's > > >> >> a potentially valid approach. I interpreted that comment as "a > > long-lived > > >> >> release line is undesirable", but no one explicitly said that, I > > just read > > >> >> it that way. > > >> >> > > >> >> ~Brent > > >> >> > > >> >> On Wed, Oct 21, 2020 at 9:49 AM Patrick Hunt <ph...@apache.org> > > wrote: > > >> >> > > >> >> > On Wed, Oct 21, 2020 at 9:03 AM Andor Molnar <an...@apache.org> > > wrote: > > >> >> > > > >> >> > > As far as I know Hbase, Solr and Kafka are already Java 11 > ready. > > >> >> > > > > >> >> > > IMHO contributors of those projects should also put efforts > into > > >> >> moving > > >> >> > > forward. > > >> >> > > > > >> >> > > We’re not saying that you _have_ to move to Java 11. > > >> >> > > Staying on Java 8? No problem, 3.6 is for you. > > >> >> > > Want the fancy new features of 3.7? Work on it on your side > too. > > >> >> > > > > >> >> > > > > >> >> > ppl want things like security fixes. I believe the highlighted > > downside > > >> >> is > > >> >> > that we would need to continue to maintain 3.6.x rather than > > allowing > > >> >> > users, and ourselves, to focus on trunk for production -"64 > > percent" > > >> >> would > > >> >> > be blocked. > > >> >> > > > >> >> > Patrick > > >> >> > > > >> >> > > > >> >> > > Andor > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > On 2020. Oct 21., at 17:52, Enrico Olivelli < > > eolive...@gmail.com> > > >> >> > wrote: > > >> >> > > > > > >> >> > > > Il giorno mer 21 ott 2020 alle ore 17:49 Andor Molnar < > > >> >> > an...@apache.org> > > >> >> > > ha > > >> >> > > > scritto: > > >> >> > > > > > >> >> > > >> Correct me if I'm wrong, but Oracle gets paid for extended > > support. > > >> >> > > >> Java 8 support until 2030 is not free of charge. > > >> >> > > >> > > >> >> > > >> "ZK may end up with a lot of users potentially locking > > themselves > > >> >> to > > >> >> > > >> 3.6.x for a while as Enrico mentioned." > > >> >> > > >> > > >> >> > > >> That's true. What's the downside of that which we should > > invest in > > >> >> to > > >> >> > > >> avoid? > > >> >> > > >> > > >> >> > > > > > >> >> > > > I see ZooKeeper used in many many projects, all of the > > >> >> > > > HBase/Pulsar/Kafka/Solr ecosystem... > > >> >> > > > they will have to move to JDK11 in order to move to the new > ZK > > >> >> version > > >> >> > > > so probably they will stay on ZK 3.6 > > >> >> > > > > > >> >> > > > Probably with Java 17 LTS released the cards will change on > the > > >> >> table > > >> >> > > > > > >> >> > > > Enrico > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > >> > > >> >> > > >> Andor > > >> >> > > >> > > >> >> > > >> > > >> >> > > >> > > >> >> > > >> On Wed, 2020-10-21 at 08:03 -0700, Brent wrote: > > >> >> > > >>> As a slightly different consideration, if you look at the > > >> >> Long-Term > > >> >> > > >>> Support > > >> >> > > >>> (LTS) roadmaps for Java, currently Java 8 is set to have > full > > >> >> support > > >> >> > > >>> until > > >> >> > > >>> 2030 from Oracle and at least 2026 from OpenJDK & Corretto: > > >> >> > > >>> > > >> >> > > >>> > > >> >> > > > https://www.oracle.com/java/technologies/java-se-support-roadmap.html > > >> >> > > >>> https://en.wikipedia.org/wiki/Java_version_history > > >> >> > > >>> > > >> >> > > >>> My guess is that a number of companies are still heavily > > invested > > >> >> at > > >> >> > > >>> the > > >> >> > > >>> Java 8 level (I know a few) and with that kind of time > > horizon, > > >> >> they > > >> >> > > >>> have > > >> >> > > >>> no real motivation to upgrade for quite a while. If the > > recent > > >> >> > > >>> Python 2 > > >> >> > > >>> deprecation is anything to go by, they won't do it until > > they have > > >> >> > > >>> to. > > >> >> > > >>> > > >> >> > > >>> Not saying Java 8 isn't *very* old (2014 release it seems > > like?) > > >> >> and > > >> >> > > >>> I'm > > >> >> > > >>> not invested heavily either way, but this might suggest > that > > ZK > > >> >> may > > >> >> > > >>> end up > > >> >> > > >>> with a lot of users potentially locking themselves to 3.6.x > > for a > > >> >> > > >>> while as > > >> >> > > >>> Enrico mentioned. > > >> >> > > >>> > > >> >> > > >>> (Not a major contributor, but wanted to chime in since I > > just had > > >> >> > > >>> this > > >> >> > > >>> conversation with a bunch of people professionally > recently) > > >> >> > > >>> > > >> >> > > >>> Brent > > >> >> > > >>> > > >> >> > > >>> On Wed, Oct 21, 2020 at 2:07 AM Andor Molnar < > > an...@apache.org> > > >> >> > > >>> wrote: > > >> >> > > >>> > > >> >> > > >>>> Thanks for the summary. > > >> >> > > >>>> > > >> >> > > >>>> I still vote for option 1). Move 3.7.0 to JDK 11 fully. > > Other > > >> >> > > >>>> projects > > >> >> > > >>>> will upgrade once they’re JDK11 compliant, otherwise they > > will > > >> >> stay > > >> >> > > >>>> on 3.5 > > >> >> > > >>>> or 3.6. Both version are quite recent in ZooKeeper-terms, > we > > >> >> > > >>>> already > > >> >> > > >>>> planned big changes for 3.7.0 and JDK 11 could be one of > > them. > > >> >> > > >>>> > > >> >> > > >>>> Don’t put extra burden on the ZK community to help others > > staying > > >> >> > > >>>> on > > >> >> > > >>>> ancient Java versions. > > >> >> > > >>>> > > >> >> > > >>>> Andor > > >> >> > > >>>> > > >> >> > > >>>> > > >> >> > > >>>> > > >> >> > > >>>>> On 2020. Oct 21., at 10:57, Enrico Olivelli < > > >> >> eolive...@gmail.com> > > >> >> > > >>>>> wrote: > > >> >> > > >>>>> > > >> >> > > >>>>> Let me recap > > >> >> > > >>>>> - Christopher is proposing to move to JDK11 > > >> >> > > >>>>> - ZooKeeper client and server are bundled and coded and > > tested > > >> >> > > >>>>> together > > >> >> > > >>>> in > > >> >> > > >>>>> zookeeper-server > > >> >> > > >>>>> - Enrico is concerned about the need of testing ZooKeeper > > client > > >> >> > > >>>>> on JDK8 > > >> >> > > >>>>> (not a problem to move the server to JDK11) > > >> >> > > >>>>> > > >> >> > > >>>>> ZooKeeper client is used by tons of users and > > unfortunately many > > >> >> > > >>>>> projects > > >> >> > > >>>>> are still on JDK8, if we move ZooKeeper to JDK11 the risk > > is to > > >> >> > > >>>>> block > > >> >> > > >>>> users > > >> >> > > >>>>> from the adoption, > > >> >> > > >>>>> that is that we will see the world to stay on 3.6.x and > we > > will > > >> >> > > >>>>> have > > >> >> > > >>>> again > > >> >> > > >>>>> a long lived release line, like 3.4. > > >> >> > > >>>>> > > >> >> > > >>>>> Testing the client on JDK8 would be possible if we create > > some > > >> >> > > >>>>> kind of > > >> >> > > >>>>> additional module with system tests, then we can start > the > > >> >> server > > >> >> > > >>>>> on > > >> >> > > >>>> docker > > >> >> > > >>>>> on JDK11+ and start a client on JDK8 > > >> >> > > >>>>> with Maven toolchain it should possible to run surefire > > tests > > >> >> > > >>>>> using a > > >> >> > > >>>>> separate JVM. > > >> >> > > >>>>> > > >> >> > > >>>>> So in my vision 2 options: > > >> >> > > >>>>> 1) fully JDK11 - drop JDK8 at all > > >> >> > > >>>>> 2) build with JDK11 - server only on JDK11 - add system > > tests > > >> >> > > >>>>> with docker > > >> >> > > >>>>> and toolchains that ensure the ZooKeeper client (and all > > >> >> > > >>>>> dependencies) > > >> >> > > >>>>> still work on JDK8 > > >> >> > > >>>>> > > >> >> > > >>>>> From my point of view about the ZooKeeper ecosystem > option > > 2) > > >> >> > > >>>>> will be far > > >> >> > > >>>>> better, but we need resources to work on a new test > suite. > > >> >> > > >>>>> > > >> >> > > >>>>> Enrico > > >> >> > > >>>>> > > >> >> > > >>>>> > > >> >> > > >>>>> Il giorno mer 21 ott 2020 alle ore 10:43 Andor Molnar < > > >> >> > > >>>>> an...@apache.org> > > >> >> > > >>>> ha > > >> >> > > >>>>> scritto: > > >> >> > > >>>>> > > >> >> > > >>>>>> Tamas, Enrico, > > >> >> > > >>>>>> > > >> >> > > >>>>>> Sorry I don’t follow. Why do we have to test the client > > with > > >> >> > > >>>>>> JDK 8 in > > >> >> > > >>>>>> version 3.7.0? > > >> >> > > >>>>>> > > >> >> > > >>>>>> Andor > > >> >> > > >>>>>> > > >> >> > > >>>>>> > > >> >> > > >>>>>> > > >> >> > > >>>>>> > > >> >> > > >>>>>>> On 2020. Oct 20., at 22:29, Tamas Penzes < > > >> >> > > >>>>>>> tam...@cloudera.com.INVALID> > > >> >> > > >>>>>> wrote: > > >> >> > > >>>>>>> Hi Enrico, > > >> >> > > >>>>>>> > > >> >> > > >>>>>>> Separating ZooKeeper client and server is a huge work, > > but we > > >> >> > > >>>>>>> might not > > >> >> > > >>>>>>> need it. > > >> >> > > >>>>>>> As you mentioned we have to test ZK client with Java 8, > > what > > >> >> > > >>>>>>> about > > >> >> > > >>>>>>> separating only the test cases which we need to run > with > > >> >> > > >>>>>>> Java8 too? > > >> >> > > >>>>>>> In Curator we have the ZK compatibility tests where we > > run a > > >> >> > > >>>>>>> limited > > >> >> > > >>>>>> amount > > >> >> > > >>>>>>> of Curator's jUnit tests with a different ZK version. > > >> >> > > >>>>>>> We might be able to do the same here, tag tests which > are > > >> >> > > >>>>>>> testing ZK > > >> >> > > >>>>>> client > > >> >> > > >>>>>>> and run them separately with Java 8. The only > limitation > > is > > >> >> > > >>>>>>> that these > > >> >> > > >>>>>>> tests must stay JDK8 compatible. > > >> >> > > >>>>>>> But from the tags we will see which ones are those. > > >> >> > > >>>>>>> > > >> >> > > >>>>>>> What do you think? > > >> >> > > >>>>>>> > > >> >> > > >>>>>>> Regards, Tamaas > > >> >> > > >>>>>>> > > >> >> > > >>>>>>> On Sat, Oct 17, 2020 at 7:45 AM Enrico Olivelli < > > >> >> > > >>>>>>> eolive...@gmail.com> > > >> >> > > >>>>>> wrote: > > >> >> > > >>>>>>>> Christopher > > >> >> > > >>>>>>>> I appreciate your idea and I also moved lots of my > > projects > > >> >> > > >>>>>>>> to work > > >> >> > > >>>> the > > >> >> > > >>>>>> way > > >> >> > > >>>>>>>> you are suggesting. > > >> >> > > >>>>>>>> > > >> >> > > >>>>>>>> > > >> >> > > >>>>>>>> We must run tests using real jdk8 to test the > Zookeeper > > >> >> > > >>>>>>>> client. We > > >> >> > > >>>> must > > >> >> > > >>>>>>>> ensure that Zookeeper works well, especially while > > dealing > > >> >> > > >>>>>>>> with > > >> >> > > >>>> security > > >> >> > > >>>>>>>> stuff. > > >> >> > > >>>>>>>> Currently the client is in the same module of the > server > > >> >> > > >>>>>>>> and it will > > >> >> > > >>>>>> take a > > >> >> > > >>>>>>>> good (huge) amount of work to separate them > > >> >> > > >>>>>>>> > > >> >> > > >>>>>>>> > > >> >> > > >>>>>>>> Enrico > > >> >> > > >>>>>>>> > > >> >> > > >>>>>>>> Il Ven 16 Ott 2020, 23:25 Christopher < > > ctubb...@apache.org> > > >> >> > > >>>>>>>> ha > > >> >> > > >>>> scritto: > > >> >> > > >>>>>>>>> Hi ZK Devs, > > >> >> > > >>>>>>>>> > > >> >> > > >>>>>>>>> With recent advancements in Java (since Java 9), it > is > > >> >> > > >>>>>>>>> now generally > > >> >> > > >>>>>>>>> no longer necessary to require that software be > > developed > > >> >> > > >>>>>>>>> on an older > > >> >> > > >>>>>>>>> JDK in order to have confidence that it will run on > the > > >> >> > > >>>>>>>>> older version > > >> >> > > >>>>>>>>> of Java. This is because, as of Java 9, all JDK > > releases > > >> >> > > >>>>>>>>> have better > > >> >> > > >>>>>>>>> support for cross-compilation to older Java versions. > > >> >> > > >>>>>>>>> > > >> >> > > >>>>>>>>> What this means is that developers can confidently > make > > >> >> > > >>>>>>>>> the build > > >> >> > > >>>>>>>>> requirements for a project higher than the Java > version > > >> >> > > >>>>>>>>> that will > > >> >> > > >>>>>>>>> actually be supported at runtime. > > >> >> > > >>>>>>>>> > > >> >> > > >>>>>>>>> In fact, ZooKeeper already supports the necessary > flags > > >> >> > > >>>>>>>>> in its Maven > > >> >> > > >>>>>>>>> build configuration to ensure that it uses JDK 8 > > >> >> > > >>>>>>>>> compliance when > > >> >> > > >>>>>>>>> building on a newer JDK (I added this way back in > > >> >> > > >>>>>>>>> ZOOKEEPER-3739 / > > >> >> > > >>>>>>>>> https://github.com/apache/zookeeper/pull/1269) > > >> >> > > >>>>>>>>> > > >> >> > > >>>>>>>>> So, I propose that we make JDK 11 the new minimum > > version > > >> >> > > >>>>>>>>> to *build* > > >> >> > > >>>>>>>>> ZooKeeper with. This would not change the runtime > > >> >> > > >>>>>>>>> requirement, which > > >> >> > > >>>>>>>>> would remain at JDK 8. > > >> >> > > >>>>>>>>> > > >> >> > > >>>>>>>>> The only necessary change to make this happen would > be > > to > > >> >> > > >>>>>>>>> add the > > >> >> > > >>>>>>>>> minimum Java version to the maven-enforcer-plugin > (like > > >> >> > > >>>>>>>>> > > >> >> > > >>>>>>>>> > > >> >> > > >>>> > > >> >> > > >> > > >> >> > > > > >> >> > > > >> >> > > > > > > https://github.com/apache/accumulo/blob/438f0efd34ef9d200bc8c7ecdd11d5dedb146519/pom.xml#L1162-L1164 > > >> >> > > >>>>>>>>> ) > > >> >> > > >>>>>>>>> > > >> >> > > >>>>>>>>> This would allow ZooKeeper to to streamline its > > >> >> > > >>>>>>>>> development process a > > >> >> > > >>>>>>>>> little bit by reducing the amount of CI testing that > is > > >> >> > > >>>>>>>>> done as part > > >> >> > > >>>>>>>>> of the build. In other words, we can drop the CI > builds > > >> >> > > >>>>>>>>> for JDK 8, > > >> >> > > >>>>>>>>> which saves on build resources and time. The return > on > > >> >> > > >>>>>>>>> investment is > > >> >> > > >>>>>>>>> so low for the JDK 8 builds anyway, because of the > > >> >> > > >>>>>>>>> improved > > >> >> > > >>>>>>>>> cross-compilation in newer JDKs. So, there's not much > > >> >> > > >>>>>>>>> value in > > >> >> > > >>>>>>>>> building on JDK 8 anyway. > > >> >> > > >>>>>>>>> > > >> >> > > >>>>>>>>> Of course, I am only recommending this for *new* > > release > > >> >> > > >>>>>>>>> lines, > > >> >> > > >>>>>>>>> starting with ZooKeeper 3.7.0/master branch, because > I > > >> >> > > >>>>>>>>> would not want > > >> >> > > >>>>>>>>> to change expectations for users who will build their > > own > > >> >> > > >>>>>>>>> 3.5 and 3.6 > > >> >> > > >>>>>>>>> versions as they continue to have patch versions > > >> >> > > >>>>>>>>> released. > > >> >> > > >>>>>>>>> > > >> >> > > >>>>>>>>> What do you think? > > >> >> > > >>>>>>>>> > > >> >> > > >>>>>>>>> Kind Regards, > > >> >> > > >>>>>>>>> Christopher > > >> >> > > >>>>>>>>> > > >> >> > > >> > > >> >> > > >> > > >> >> > > > > >> >> > > > > >> >> > > > >> >> > > >> > > > >
