I'd say there are quite a few tasks aimed at 4.0. I just answered a thread about jute.maxbuffer error, which could be improved for example. Or better yet, throw jute out and use a standardized serialization library. But there's also the issue of separating client and server code. And I'm sure there's many more I can't recall right now.
But this is worth a separate vote thread, that's for sure. - Norbert On Fri, Jan 8, 2021 at 1:33 PM Andor Molnar <an...@apache.org> wrote: > 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 > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>> > >> > >
