I'm fine with moving to Java 8 or even 9 in 3.6. Does anyone have a different option? Otherwise, should we start a vote?
-Flavio > On 16 Feb 2018, at 21:28, Abraham Fine <[email protected]> wrote: > > 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 >>>> >>>> >>>
