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