I'm a -1 on requiring different minimum versions of java for the client and the server. I think this has the potential to create a lot of confusion for users and contributors.
I would support moving master (3.6) to java 8, I also think it is worth considering moving to java 9. Given how long our release cycle tends to be I think targeting the latest and greatest this early in the development cycle is reasonable. Thanks, Abe On Fri, Feb 16, 2018, at 06:48, Enrico Olivelli wrote: > 2018-02-16 14:20 GMT+01:00 Andor Molnar <[email protected]>: > > > +1 for setting the Java8 requirement on server side. > > > > *Client side.* > > I'd like the idea of the setting the requirement on client side too without > > introducing anything Java8 specific. I'm not planning to use Java8 features > > right on, just thinking of opening the gates would be useful in the long > > run. > > > > Additionally, I don't see heavy development on the client side. Users who > > are tightly coupled to Java7 are still able to use existing clients as long > > as we introduce something breaking which they're forced to upgrade to for > > whatever reason. I'm not sure what are the odds of that to happen. > > > > > My two cents > Actually ZooKeeper is distributed as a single JAR which contains both > server and client side code, requiring Java 7 for the client and Java 8 for > the server will require a new way of packaging the artifacts and building > the project (and this will require separating client side and server side > code base). > Maybe I am missing something. > > > Enrico > > > > > > Andor > > > > > > > > On Fri, Feb 16, 2018 at 12:31 PM, Flavio Junqueira <[email protected]> wrote: > > > > > We have this section in the admin doc that talks about the system > > > requirements: > > > > > > https://zookeeper.apache.org/doc/r3.5.3-beta/zookeeperAdmin.html#sc_ > > > requiredSoftware <https://zookeeper.apache.org/doc/r3.5.3-beta/ > > > zookeeperAdmin.html#sc_requiredSoftware> > > > > > > If we change, then we have to update that section. Specifically about > > > client and server, I'd think that there is no problem with requiring > > Java 8 > > > on the server. The potential concern is with the client as it affects > > > applications that build against it. It would be best to not force > > > applications to upgrade themselves. Looking at the compatibility guide > > for > > > Java 8: > > > > > > http://www.oracle.com/technetwork/java/javase/8- > > > compatibility-guide-2156366.html <http://www.oracle.com/ > > > technetwork/java/javase/8-compatibility-guide-2156366.html> > > > > > > The risk is that an application is strictly using Java 7 because of some > > > incompatibility listed in that guide, in which case, it wouldn't be able > > to > > > compile the ZK client assuming we get it to use some Java 8 construct. > > One > > > option is that we raise the requirement to Java 8, but we do no really > > > introduce anything that breaks compatibility for the next version. Users > > > should take this as a warning that they need to migrate to Java 8. I'm > > not > > > sure this makes the situation any better, though. Another option is that > > we > > > set a release to be the one in which we migrate and let everyone know > > that > > > they need to migrate. > > > > > > -Flavio > > > > > > > > > > On 16 Feb 2018, at 12:05, Andor Molnar <[email protected]> wrote: > > > > > > > > Hi all, > > > > > > > > I think it would be nice to draw a line at branch-3.5 and target Java > > > > version 8 onwards. It seems to be a good opportunity for the upgrade > > > before > > > > we release a stable version of 3.5. > > > > > > > > The benefit would be the ability to use new features of Java 8 in the > > > code: > > > > > > > > Do think it's feasible? > > > > > > > > Regards, > > > > Andor > > > > > > > >
