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 > >>>>>>>>> > >> > >> > >
