zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andor Molnar <an...@apache.org>
Subject Re: Java version (Oracle - OpenJDK) support
Date Fri, 14 Sep 2018 18:38:02 GMT


> On 2018. Sep 13., at 19:29, Patrick Hunt <phunt@apache.org> wrote:
> 
> On Thu, Sep 13, 2018 at 1:52 AM Andor Molnar <andor@apache.org <mailto:andor@apache.org>>
wrote:
> 
>> Hi team,
>> 
>> Let me quickly summarise what we’re trying to resolve on this thread.
>> 
>> Problem #1: due to Oracle licensing changes people are expected to move
>> away from Oracle Java and support of other “open” Java implementations will
>> become important for ZooKeeper.
>> 
>> Problem #2: Java 8 support will end in September 2018, we have to add
>> support for Java 11 (LTS). Java 9 and 10 support are nice-to-haves, because
>> those are not LTS releases.
>> 
>> branch-3.4 (stable version):
>> From Jenkins this is currently the most stable version (kudos for the hard
>> work with flaky tests).
>> Problem: Java 11 build is failing due to Kerberos tests.
>> Solution: Backport Kerberos tests from 3.5
>> 
>> I think there’s no need to change Java support on branch-3.4 or it’s not
>> scope of this conversation.
>> 
>> branch-3.5 (upcoming stable version):
>> Problem: there’s no Java 11 build currently
>> Solution: create new Jenkins job
>> 
>> branch-3.6 (master):
>> Problem: Java 11 build is constantly failing
>> Solution: no solution provided yet
>> 
>> A few more thoughts:
>> - We don’t necessarily need to add Java 11 support for branch-3.4. I think
>> it would be better to push people towards upgrading to 3.5 and focus on
>> making it stable as soon as possible. (See the other thread for details -
>> we’re getting close)
>> 
> 
> Until the downstream projects (those using ZK) update to post-3.4 many
> users will be forced to keep 3.4. Given 3.4 is currently the stable branch
> and it's unknown when 3.5 will reach the same level of maturity, and Oracle
> forcing the issue re JDK licensing, I don't think this will be feasible for
> many users.
> 
> Patrick

Understood.
Enrico already submitted a patch to make Kerberos testing JDK11 compatible.
We’ll be in a good shape with that for 3.4

Andor







> 
> 
>> - We should add more pressure on the testing side of 3.5: there’re only 3
>> Jenkins job currently running on branch-3.5. Let’s add Oracle Java 11
>> build, OpenJDK 8,9,10,11 whatever you think makes sense.
>> 
>> Regards,
>> Andor
>> 
>> 
>> 
>> 
>> 
>>> On 2018. Sep 13., at 8:38, Enrico Olivelli <eolivelli@gmail.com> wrote:
>>> 
>>> Il gio 13 set 2018, 01:00 Patrick Hunt <phunt@apache.org <mailto:
>> phunt@apache.org>> ha scritto:
>>> 
>>>> Historically we've always defined a minimum version and let users
>> decide.
>>>> That seems to have worked pretty well. It provides the most flexibility
>> and
>>>> hasn't really bothered us too much. It limits our use of new language
>>>> features of Java, but typically Java is ensuring b/w compat from a
>> runtime
>>>> perspective and as a result there's isn't much of a burden to say we
>>>> support 6 and laters vs alternately saying we support 6&8 exclusively.
>>>> 
>>> 
>>> The problem is only about a test case. We can copy the test case 3.5
>> branch
>>> which is using Kerby and run that one in case of java >= 11 using junit
>>> 'assumptions'.
>>> 
>>> Enrico
>>> 
>>> 
>>>> Patrick
>>>> 
>>>> On Wed, Sep 12, 2018 at 7:16 AM Enrico Olivelli <eolivelli@gmail.com>
>>>> wrote:
>>>> 
>>>>> Il mer 12 set 2018, 11:37 Norbert Kalmar <nkalmar@cloudera.com.invalid
>>> 
>>>> ha
>>>>> scritto:
>>>>> 
>>>>>> Thanks Enrico!
>>>>>> 
>>>>>> Agree, as I mentioned, only JDK8 and 11 should be tested on 3.4 and
>>>> other
>>>>>> branches as well.
>>>>>> 
>>>>>> I checked the Kerby problems, 3.4 does not have Kerby, it uses Apache
>>>>>> directory server.
>>>>>> Maybe we should introduce also introduce Kerby on 3.4? Or just try
to
>>>> fix
>>>>>> the problems with directory server.
>>>>>> 
>>>>> 
>>>>> Directory Server supports jdk6 and Kerby not.
>>>>> If wr drop JDK6 we  can switch to Kerby
>>>>> 
>>>>> Enrico
>>>>> 
>>>>> 
>>>>> 
>>>>>> Regards,
>>>>>> Norbert
>>>>>> 
>>>>>> On Wed, Sep 12, 2018 at 11:22 AM Enrico Olivelli <eolivelli@gmail.com
>>> 
>>>>>> wrote:
>>>>>> 
>>>>>>> Il giorno mer 12 set 2018 alle ore 11:04 Norbert Kalmar
>>>>>>> <nkalmar@cloudera.com.invalid> ha scritto:
>>>>>>> 
>>>>>>>> Hi all,
>>>>>>>> 
>>>>>>>> Oracle8 will have it's support end in January. They changed
there
>>>>>> release
>>>>>>>> drastically.
>>>>>>>> A good article on that:
>>>>>>>> https://dev.karakun.com/java/2018/06/25/java-releases.html
>>>>>>>> 
>>>>>>>> Long story short: From January, no Oracle JDK version can
be used
>>>> in
>>>>>> PROD
>>>>>>>> environment without a license. End every release, even LTS
(next
>>>> one
>>>>> is
>>>>>>>> version 11) will only have a 6 month public update period.
>>>>>>>> 
>>>>>>>> We should also decide on the supported versions of Java.
>>>>>>>> 
>>>>>>>> My opinion: We should make sure ZK is compatible with Oracle
8 and
>>>>> 11,
>>>>>>> and
>>>>>>>> also openJDK 8 and 11.
>>>>>>>> 
>>>>>>>> But after that, every 6 month, there will be a new Oracle
Java
>>>>> version
>>>>>>>> which we should support.
>>>>>>>> 
>>>>>>>> What do you think? What version to support? What about 3.4
now that
>>>>> 3.5
>>>>>>> is
>>>>>>>> getting close to stable? (I think fix 3.4 on Oracle 11 and
that's
>>>> it
>>>>> -
>>>>>>> 3.5
>>>>>>>> stable should be out by the time 12 comes out).
>>>>>>>> 
>>>>>>> 
>>>>>>> As far as I know ZK is running fine on JDK11, even 3.4.
>>>>>>> We have a problem with Kerberos tests on 3.4, but we can fix
them.
>>>>>>> 
>>>>>>> 
>>>>>>> I can add that as far as I know there will not be any 'Oracle
JDK 12"
>>>>> GA,
>>>>>>> but only OpenJDK will be released to GA from Oracle
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> Once we have an agreement, we should create jira's to fix
Java11
>>>>>>> problems.
>>>>>>>> 
>>>>>>> 
>>>>>>> Ok to me
>>>>>>> 
>>>>>>> We can consider also dropping support for JDK6 on 3.4 branch,
this is
>>>>>>> actually the problem
>>>>>>> 
>>>>>>> Enrico
>>>>>>> 
>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Norbert
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> --
>>>>> 
>>>>> 
>>>>> -- Enrico Olivelli
>>>>> 
>>>> 
>>> --
>>> 
>>> 
>>> -- Enrico Olivelli


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message