On Wed, Oct 21, 2020 at 8:04 AM Brent <brentwritesc...@gmail.com> 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) > > I had similar thoughts as to what Brent has mentioned. Also there are reports such as this one from inforworld in May of this year: https://www.infoworld.com/article/3532358/oracle-extends-extended-support-for-java-8.html "64 percent of Java users polled are using Java SE (Standard Edition) 8 for their main application in production" Given Oracle themselves have seen fit to continue supporting java8 I don't see how we should drop it. In many cases there may be a corporate mandate in place which keeps folks from utilizing a newer version - iow not a technical decision. Regards, Patrick > 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 > > >>>>> > > >>>> > > >> > > >> > > > > >
