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