Hi Andor, all,
Okay—a clear consensus has emerged in this thread. 3.7+ will follow the same "JDK policy" as 3.6. Thank you all for your input. Cheers, -D Andor Molnar <an...@apache.org> writes: > Okay, let’s stay on JDK 8 with 3.7.0 release and do the transition in 4.0. > Not sure if we want 3.8 release or make the master 4.0 from now on. > > Andor > > > >> On 2021. Jan 6., at 22:35, Christopher <ctubb...@apache.org> wrote: >> >> 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 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>> >>>