Re: [DISCUSS] Cassandra and future Java

[kurt greaves]

I suppose so, I guess just highlighting that we shouldn't bother dedicating
much testing resources to 4.0 on 11.

I will note however that if we wanted to start making changes to support 11
it'd have to be (as Robert alluded to) based off an incomplete 11 as I'm
assuming we'd make no further changes after 4.0 is frozen and instead
they'd go to 4.1.

On Wed., 30 May 2018, 20:40 Stefan Podkowinski,  wrote:

> That's probably not far off what Robert suggested:
>
> "The idea here is to default to Java 8, but the code also runs on 11"
>
> "Initially, only the combination of C* 4.0 + Java 8 would be labeled as
> "stable" and the combination of C* 4.0 + Java 11 as "experimental"."
>
> If Robert wants to go ahead making the code "also run Java 11", while we
> keep testing for and officially supporting Java 8, then I can't really
> think of any argument against that, as long as we don't end up with tons
> of version based code toggles, or too risky changes regarding stability
> in general. We would still release 4.0 for Java 8 and afterwards
> officially switch to 11 in 4.1, based on the work done in #9608 and
> already merged into 4.0. Downloads and packages for 4.0 would be
> released for Java 8, while running 4.0 with Java 11 would produce a
> warning message indicating that it's experimental.
>
>
> On 30.05.2018 08:54, kurt greaves wrote:
> > So for anyone that missed it, Java 11 will be released in September 2018.
> >
> > I'd prefer we target one Java release only. This is purely because we
> don't
> > have the capacity or capability to test both releases. We hardly do a
> good
> > enough job as it is of testing and lumping another JVM into the mix is
> just
> > going to complicate things a lot and all the effort we expend into
> testing
> > both releases is probably better off just spent focusing on one.
> >
> > At this point I don't think there is *much* value in supporting 11 for
> 4.0,
> > seeing as we won't be able to fully utilise features in 11 as our feature
> > freeze for 4.0 will occur before 11 is released. There is obviously the
> > support problem but adoptOpenJDK are claiming they'll support Java 8
> until
> > September 2022 (https://adoptopenjdk.net/support.html) - which on top of
> > all the existing releases is probably good enough for us, and 2022 is far
> > enough away that hopefully 4.0 will be EOL'd by then. I don't think it's
> a
> > big risk that support for Java 8 will stop anytime soon, it's pretty
> > widespread and it's going to take people a *long* time to get off 8.
> >
> > It would make much more sense to me to support 11 in 4.1 that way we can
> > actually utilise any benefits of 11.
> >
> > On 29 May 2018 at 12:22, Robert Stupp  wrote:
> >
> >> Ideally, CI would run against both Java 8 and 11. I’ve no clue about
> b.a.o
> >> though.
> >>
> >> There will definitely be a log of smaller issues - both for OpenJDK 8
> and
> >> 11.
> >> I think, it’s sufficient to deal with the Linux distros' (RH/deb)
> openjdk
> >> dependencies - just making sure, that we’re using the right Java
> version -
> >> and not let the package manger just pull the newest available.
> >> The version-string from adoptopenjdk for example is one of these “minor
> >> issues"...
> >>
> >> —
> >> Robert Stupp
> >> @snazy
> >>
> >> On 28. May 2018, at 15:46, Stefan Podkowinski  wrote:
> >>
> >> The main issue that I see, for supporting both Java 8 + 11, is testing.
> >> We should first decide how this would effect builds.apache.org, or how
> >> we're going to do CI testing in general for that situation.
> >>
> >> There are probably also smaller issues that we're not aware of yet, such
> >> as which Java dependency to use for our deb and rpm packages,
> >> differences in Java distributions (Oracle, AdoptOpenJDK, Redhat,..) and
> >> so on. I'd expect we could deal with this on the Java side, but the
> >> infra, scripting and testing implications give me a greater headache
> >> when thinking of it.
> >>
> >>
> >> On 25.05.2018 15:33, J. D. Jordan wrote:
> >>
> >> +1 for “Option 3: both 8 + 11” it shouldn’t be too hard to maintain code
> >> wise, and leaves people’s options open.
> >>
> >> -Jeremiah
> >>
> >> On May 25, 2018, at 6:31 AM, Robert Stupp  wrote:
> >>
> >> I'd like to bring up the C*/Java discussion again. It's been a while
> since
> >> we've discussed this.
> >>
> >> To me it sounds like there's still the question about which version(s)
> of
> >> Java we want to support beginning with C* 4.0.
> >>
> >> I assume, that it's legit (and probably very necessary) to assume that
> >> OpenJDK is now (i.e. after Java 6) considered as "production ready" for
> C*.
> >> The public (and legal and free) availability of Oracle's Java 8 will
> end in
> >> January 2019 (unless you're using it privately on your desktop). Java 9
> and
> >> 10 are not a thing, as both will be EOL when the C* 4.0 branch is about
> to
> >> be cut. The most recent available Java version will be 11, which is
> meant
> >> to be publicly available 

Re: [DISCUSS] Cassandra and future Java

[Stefan Podkowinski]

That's probably not far off what Robert suggested:

"The idea here is to default to Java 8, but the code also runs on 11"

"Initially, only the combination of C* 4.0 + Java 8 would be labeled as
"stable" and the combination of C* 4.0 + Java 11 as "experimental"."

If Robert wants to go ahead making the code "also run Java 11", while we
keep testing for and officially supporting Java 8, then I can't really
think of any argument against that, as long as we don't end up with tons
of version based code toggles, or too risky changes regarding stability
in general. We would still release 4.0 for Java 8 and afterwards
officially switch to 11 in 4.1, based on the work done in #9608 and
already merged into 4.0. Downloads and packages for 4.0 would be
released for Java 8, while running 4.0 with Java 11 would produce a
warning message indicating that it's experimental.


On 30.05.2018 08:54, kurt greaves wrote:
> So for anyone that missed it, Java 11 will be released in September 2018.
> 
> I'd prefer we target one Java release only. This is purely because we don't
> have the capacity or capability to test both releases. We hardly do a good
> enough job as it is of testing and lumping another JVM into the mix is just
> going to complicate things a lot and all the effort we expend into testing
> both releases is probably better off just spent focusing on one.
> 
> At this point I don't think there is *much* value in supporting 11 for 4.0,
> seeing as we won't be able to fully utilise features in 11 as our feature
> freeze for 4.0 will occur before 11 is released. There is obviously the
> support problem but adoptOpenJDK are claiming they'll support Java 8 until
> September 2022 (https://adoptopenjdk.net/support.html) - which on top of
> all the existing releases is probably good enough for us, and 2022 is far
> enough away that hopefully 4.0 will be EOL'd by then. I don't think it's a
> big risk that support for Java 8 will stop anytime soon, it's pretty
> widespread and it's going to take people a *long* time to get off 8.
> 
> It would make much more sense to me to support 11 in 4.1 that way we can
> actually utilise any benefits of 11.
> 
> On 29 May 2018 at 12:22, Robert Stupp  wrote:
> 
>> Ideally, CI would run against both Java 8 and 11. I’ve no clue about b.a.o
>> though.
>>
>> There will definitely be a log of smaller issues - both for OpenJDK 8 and
>> 11.
>> I think, it’s sufficient to deal with the Linux distros' (RH/deb) openjdk
>> dependencies - just making sure, that we’re using the right Java version -
>> and not let the package manger just pull the newest available.
>> The version-string from adoptopenjdk for example is one of these “minor
>> issues"...
>>
>> —
>> Robert Stupp
>> @snazy
>>
>> On 28. May 2018, at 15:46, Stefan Podkowinski  wrote:
>>
>> The main issue that I see, for supporting both Java 8 + 11, is testing.
>> We should first decide how this would effect builds.apache.org, or how
>> we're going to do CI testing in general for that situation.
>>
>> There are probably also smaller issues that we're not aware of yet, such
>> as which Java dependency to use for our deb and rpm packages,
>> differences in Java distributions (Oracle, AdoptOpenJDK, Redhat,..) and
>> so on. I'd expect we could deal with this on the Java side, but the
>> infra, scripting and testing implications give me a greater headache
>> when thinking of it.
>>
>>
>> On 25.05.2018 15:33, J. D. Jordan wrote:
>>
>> +1 for “Option 3: both 8 + 11” it shouldn’t be too hard to maintain code
>> wise, and leaves people’s options open.
>>
>> -Jeremiah
>>
>> On May 25, 2018, at 6:31 AM, Robert Stupp  wrote:
>>
>> I'd like to bring up the C*/Java discussion again. It's been a while since
>> we've discussed this.
>>
>> To me it sounds like there's still the question about which version(s) of
>> Java we want to support beginning with C* 4.0.
>>
>> I assume, that it's legit (and probably very necessary) to assume that
>> OpenJDK is now (i.e. after Java 6) considered as "production ready" for C*.
>> The public (and legal and free) availability of Oracle's Java 8 will end in
>> January 2019 (unless you're using it privately on your desktop). Java 9 and
>> 10 are not a thing, as both will be EOL when the C* 4.0 branch is about to
>> be cut. The most recent available Java version will be 11, which is meant
>> to be publicly available from Oracle until March 2019 and should get LTS
>> support for OpenJDK 11 from major Linux distros (RHEL and derivates,
>> Ubuntu, Azul Zulu).
>>
>> (Side note: adoptopenjdk is different here, because it does not include
>> the patch version in the version banner (java.version=1.8.0-adoptopenjdk),
>> so difficult to check the minimum patch version on startup of C*.)
>>
>> (Attn, rant: I'm not particularly happy with the new release and support
>> model for Java, because developing something now, that's about to release
>> end of the year on a Java version that has not even reached
>> feature-complete status, is, 

Re: [DISCUSS] Cassandra and future Java

[kurt greaves]

So for anyone that missed it, Java 11 will be released in September 2018.

I'd prefer we target one Java release only. This is purely because we don't
have the capacity or capability to test both releases. We hardly do a good
enough job as it is of testing and lumping another JVM into the mix is just
going to complicate things a lot and all the effort we expend into testing
both releases is probably better off just spent focusing on one.

At this point I don't think there is *much* value in supporting 11 for 4.0,
seeing as we won't be able to fully utilise features in 11 as our feature
freeze for 4.0 will occur before 11 is released. There is obviously the
support problem but adoptOpenJDK are claiming they'll support Java 8 until
September 2022 (https://adoptopenjdk.net/support.html) - which on top of
all the existing releases is probably good enough for us, and 2022 is far
enough away that hopefully 4.0 will be EOL'd by then. I don't think it's a
big risk that support for Java 8 will stop anytime soon, it's pretty
widespread and it's going to take people a *long* time to get off 8.

It would make much more sense to me to support 11 in 4.1 that way we can
actually utilise any benefits of 11.

On 29 May 2018 at 12:22, Robert Stupp  wrote:

> Ideally, CI would run against both Java 8 and 11. I’ve no clue about b.a.o
> though.
>
> There will definitely be a log of smaller issues - both for OpenJDK 8 and
> 11.
> I think, it’s sufficient to deal with the Linux distros' (RH/deb) openjdk
> dependencies - just making sure, that we’re using the right Java version -
> and not let the package manger just pull the newest available.
> The version-string from adoptopenjdk for example is one of these “minor
> issues"...
>
> —
> Robert Stupp
> @snazy
>
> On 28. May 2018, at 15:46, Stefan Podkowinski  wrote:
>
> The main issue that I see, for supporting both Java 8 + 11, is testing.
> We should first decide how this would effect builds.apache.org, or how
> we're going to do CI testing in general for that situation.
>
> There are probably also smaller issues that we're not aware of yet, such
> as which Java dependency to use for our deb and rpm packages,
> differences in Java distributions (Oracle, AdoptOpenJDK, Redhat,..) and
> so on. I'd expect we could deal with this on the Java side, but the
> infra, scripting and testing implications give me a greater headache
> when thinking of it.
>
>
> On 25.05.2018 15:33, J. D. Jordan wrote:
>
> +1 for “Option 3: both 8 + 11” it shouldn’t be too hard to maintain code
> wise, and leaves people’s options open.
>
> -Jeremiah
>
> On May 25, 2018, at 6:31 AM, Robert Stupp  wrote:
>
> I'd like to bring up the C*/Java discussion again. It's been a while since
> we've discussed this.
>
> To me it sounds like there's still the question about which version(s) of
> Java we want to support beginning with C* 4.0.
>
> I assume, that it's legit (and probably very necessary) to assume that
> OpenJDK is now (i.e. after Java 6) considered as "production ready" for C*.
> The public (and legal and free) availability of Oracle's Java 8 will end in
> January 2019 (unless you're using it privately on your desktop). Java 9 and
> 10 are not a thing, as both will be EOL when the C* 4.0 branch is about to
> be cut. The most recent available Java version will be 11, which is meant
> to be publicly available from Oracle until March 2019 and should get LTS
> support for OpenJDK 11 from major Linux distros (RHEL and derivates,
> Ubuntu, Azul Zulu).
>
> (Side note: adoptopenjdk is different here, because it does not include
> the patch version in the version banner (java.version=1.8.0-adoptopenjdk),
> so difficult to check the minimum patch version on startup of C*.)
>
> (Attn, rant: I'm not particularly happy with the new release and support
> model for Java, because developing something now, that's about to release
> end of the year on a Java version that has not even reached
> feature-complete status, is, gently speaking, difficult. But sticking to an
> "antique" Java version (8) has its own risks as well.)
>
> I'm silently ignoring any Java release, that's not aimed to get any
> LTS(-ish?) support from anybody - so only Java 8 + 11 remain.
>
> There are generally three (IMO legit) options here: only support Java 8,
> only support Java 11, support both Java 8 and Java 11. All three options
> have a bunch of pros and cons.
>
> Option 1, only Java 8: Probably the safest option. Considering the
> potential lifetimes of Java 8 and C* 4.0, even the most enthusiastic
> maintainers may stop backporting security or bug fixes to OpenJDK 8. It
> might not be an issue in practice, but if there's for example a severe
> issue in the SSL/TLS area and nobody fixes it in 8, well, good luck.
>
> Option 2, only Java 11: The option with the most risks IMO. Java 11 is not
> even feature complete, and there a bunch of big projects that still may
> make it into 11 (think: Valhalla). There's no guarantee whether the C* code
> or 

Re: [DISCUSS] Cassandra and future Java

[Robert Stupp]

Ideally, CI would run against both Java 8 and 11. I’ve no clue about b.a.o 
though.

There will definitely be a log of smaller issues - both for OpenJDK 8 and 11.
I think, it’s sufficient to deal with the Linux distros' (RH/deb) openjdk 
dependencies - just making sure, that we’re using the right Java version - and 
not let the package manger just pull the newest available.
The version-string from adoptopenjdk for example is one of these “minor 
issues"...

—
Robert Stupp
@snazy

> On 28. May 2018, at 15:46, Stefan Podkowinski  wrote:
> 
> The main issue that I see, for supporting both Java 8 + 11, is testing.
> We should first decide how this would effect builds.apache.org, or how
> we're going to do CI testing in general for that situation.
> 
> There are probably also smaller issues that we're not aware of yet, such
> as which Java dependency to use for our deb and rpm packages,
> differences in Java distributions (Oracle, AdoptOpenJDK, Redhat,..) and
> so on. I'd expect we could deal with this on the Java side, but the
> infra, scripting and testing implications give me a greater headache
> when thinking of it.
> 
> 
> On 25.05.2018 15:33, J. D. Jordan wrote:
>> +1 for “Option 3: both 8 + 11” it shouldn’t be too hard to maintain code 
>> wise, and leaves people’s options open.
>> 
>> -Jeremiah
>> 
>>> On May 25, 2018, at 6:31 AM, Robert Stupp  wrote:
>>> 
>>> I'd like to bring up the C*/Java discussion again. It's been a while since 
>>> we've discussed this.
>>> 
>>> To me it sounds like there's still the question about which version(s) of 
>>> Java we want to support beginning with C* 4.0.
>>> 
>>> I assume, that it's legit (and probably very necessary) to assume that 
>>> OpenJDK is now (i.e. after Java 6) considered as "production ready" for C*. 
>>> The public (and legal and free) availability of Oracle's Java 8 will end in 
>>> January 2019 (unless you're using it privately on your desktop). Java 9 and 
>>> 10 are not a thing, as both will be EOL when the C* 4.0 branch is about to 
>>> be cut. The most recent available Java version will be 11, which is meant 
>>> to be publicly available from Oracle until March 2019 and should get LTS 
>>> support for OpenJDK 11 from major Linux distros (RHEL and derivates, 
>>> Ubuntu, Azul Zulu).
>>> 
>>> (Side note: adoptopenjdk is different here, because it does not include the 
>>> patch version in the version banner (java.version=1.8.0-adoptopenjdk), so 
>>> difficult to check the minimum patch version on startup of C*.)
>>> 
>>> (Attn, rant: I'm not particularly happy with the new release and support 
>>> model for Java, because developing something now, that's about to release 
>>> end of the year on a Java version that has not even reached 
>>> feature-complete status, is, gently speaking, difficult. But sticking to an 
>>> "antique" Java version (8) has its own risks as well.)
>>> 
>>> I'm silently ignoring any Java release, that's not aimed to get any 
>>> LTS(-ish?) support from anybody - so only Java 8 + 11 remain.
>>> 
>>> There are generally three (IMO legit) options here: only support Java 8, 
>>> only support Java 11, support both Java 8 and Java 11. All three options 
>>> have a bunch of pros and cons.
>>> 
>>> Option 1, only Java 8: Probably the safest option. Considering the 
>>> potential lifetimes of Java 8 and C* 4.0, even the most enthusiastic 
>>> maintainers may stop backporting security or bug fixes to OpenJDK 8. It 
>>> might not be an issue in practice, but if there's for example a severe 
>>> issue in the SSL/TLS area and nobody fixes it in 8, well, good luck.
>>> 
>>> Option 2, only Java 11: The option with the most risks IMO. Java 11 is not 
>>> even feature complete, and there a bunch of big projects that still may 
>>> make it into 11 (think: Valhalla). There's no guarantee whether the C* code 
>>> or any included library will actually work with Java 11 (think: if it works 
>>> now, it may not work with the final Java version). However, it leaves the 
>>> door wide open for all the neat and geeky things in Java 11.
>>> 
>>> Option 3: both 8 + 11: The idea here is to default to Java 8, but the code 
>>> also runs on 11. It leaves the option to benefit from optimizations that 
>>> are only available on 11 while maintaining the known stability of 8. 
>>> Initially, only the combination of C* 4.0 + Java 8 would be labeled as 
>>> "stable" and the combination of C* 4.0 + Java 11 as "experimental". But it 
>>> gives us time to "evaluate" 4.0 on 11. When we have enough experience with 
>>> 11, C* on 11 can be labeled as "stable" as well. The downside of this 
>>> "hybrid" is, that it's a bit more difficult to introduce features, that 
>>> depend on 11.
>>> 
>>> I think, 3) gives the best of both worlds: stability of 8 and an upgrade 
>>> path to 11 in the future, that people can actually test with C* 4.0. Happy 
>>> to make the patch for #9608 ready for option 3. But it would be great to 
>>> get a consensus here for either option 

Re: [DISCUSS] Cassandra and future Java

[Stefan Podkowinski]

The main issue that I see, for supporting both Java 8 + 11, is testing.
We should first decide how this would effect builds.apache.org, or how
we're going to do CI testing in general for that situation.

There are probably also smaller issues that we're not aware of yet, such
as which Java dependency to use for our deb and rpm packages,
differences in Java distributions (Oracle, AdoptOpenJDK, Redhat,..) and
so on. I'd expect we could deal with this on the Java side, but the
infra, scripting and testing implications give me a greater headache
when thinking of it.


On 25.05.2018 15:33, J. D. Jordan wrote:
> +1 for “Option 3: both 8 + 11” it shouldn’t be too hard to maintain code 
> wise, and leaves people’s options open.
> 
> -Jeremiah
> 
>> On May 25, 2018, at 6:31 AM, Robert Stupp  wrote:
>>
>> I'd like to bring up the C*/Java discussion again. It's been a while since 
>> we've discussed this.
>>
>> To me it sounds like there's still the question about which version(s) of 
>> Java we want to support beginning with C* 4.0.
>>
>> I assume, that it's legit (and probably very necessary) to assume that 
>> OpenJDK is now (i.e. after Java 6) considered as "production ready" for C*. 
>> The public (and legal and free) availability of Oracle's Java 8 will end in 
>> January 2019 (unless you're using it privately on your desktop). Java 9 and 
>> 10 are not a thing, as both will be EOL when the C* 4.0 branch is about to 
>> be cut. The most recent available Java version will be 11, which is meant to 
>> be publicly available from Oracle until March 2019 and should get LTS 
>> support for OpenJDK 11 from major Linux distros (RHEL and derivates, Ubuntu, 
>> Azul Zulu).
>>
>> (Side note: adoptopenjdk is different here, because it does not include the 
>> patch version in the version banner (java.version=1.8.0-adoptopenjdk), so 
>> difficult to check the minimum patch version on startup of C*.)
>>
>> (Attn, rant: I'm not particularly happy with the new release and support 
>> model for Java, because developing something now, that's about to release 
>> end of the year on a Java version that has not even reached feature-complete 
>> status, is, gently speaking, difficult. But sticking to an "antique" Java 
>> version (8) has its own risks as well.)
>>
>> I'm silently ignoring any Java release, that's not aimed to get any 
>> LTS(-ish?) support from anybody - so only Java 8 + 11 remain.
>>
>> There are generally three (IMO legit) options here: only support Java 8, 
>> only support Java 11, support both Java 8 and Java 11. All three options 
>> have a bunch of pros and cons.
>>
>> Option 1, only Java 8: Probably the safest option. Considering the potential 
>> lifetimes of Java 8 and C* 4.0, even the most enthusiastic maintainers may 
>> stop backporting security or bug fixes to OpenJDK 8. It might not be an 
>> issue in practice, but if there's for example a severe issue in the SSL/TLS 
>> area and nobody fixes it in 8, well, good luck.
>>
>> Option 2, only Java 11: The option with the most risks IMO. Java 11 is not 
>> even feature complete, and there a bunch of big projects that still may make 
>> it into 11 (think: Valhalla). There's no guarantee whether the C* code or 
>> any included library will actually work with Java 11 (think: if it works 
>> now, it may not work with the final Java version). However, it leaves the 
>> door wide open for all the neat and geeky things in Java 11.
>>
>> Option 3: both 8 + 11: The idea here is to default to Java 8, but the code 
>> also runs on 11. It leaves the option to benefit from optimizations that are 
>> only available on 11 while maintaining the known stability of 8. Initially, 
>> only the combination of C* 4.0 + Java 8 would be labeled as "stable" and the 
>> combination of C* 4.0 + Java 11 as "experimental". But it gives us time to 
>> "evaluate" 4.0 on 11. When we have enough experience with 11, C* on 11 can 
>> be labeled as "stable" as well. The downside of this "hybrid" is, that it's 
>> a bit more difficult to introduce features, that depend on 11.
>>
>> I think, 3) gives the best of both worlds: stability of 8 and an upgrade 
>> path to 11 in the future, that people can actually test with C* 4.0. Happy 
>> to make the patch for #9608 ready for option 3. But it would be great to get 
>> a consensus here for either option before we review #9608 and commit it.
>>
>> Another proposal, for both options 1+3: Raise the minimum supported version 
>> of 8 for C* 4.0 to something more recent than 8u40, which is quite from the 
>> stone-age. It could be 8u171 or whatever will be recent in autumn.
>>
>> Robert
>>
>> -- 
>> Robert Stupp
>> @snazy
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>
> 
> -
> To unsubscribe, e-mail: 

Re: [DISCUSS] Cassandra and future Java

[Jonathan Haddad]

Personally I don’t mind dropping support for previsous java versions.

On Fri, May 25, 2018 at 6:33 AM J. D. Jordan 
wrote:

> +1 for “Option 3: both 8 + 11” it shouldn’t be too hard to maintain code
> wise, and leaves people’s options open.
>
> -Jeremiah
>
> > On May 25, 2018, at 6:31 AM, Robert Stupp  wrote:
> >
> > I'd like to bring up the C*/Java discussion again. It's been a while
> since we've discussed this.
> >
> > To me it sounds like there's still the question about which version(s)
> of Java we want to support beginning with C* 4.0.
> >
> > I assume, that it's legit (and probably very necessary) to assume that
> OpenJDK is now (i.e. after Java 6) considered as "production ready" for C*.
> The public (and legal and free) availability of Oracle's Java 8 will end in
> January 2019 (unless you're using it privately on your desktop). Java 9 and
> 10 are not a thing, as both will be EOL when the C* 4.0 branch is about to
> be cut. The most recent available Java version will be 11, which is meant
> to be publicly available from Oracle until March 2019 and should get LTS
> support for OpenJDK 11 from major Linux distros (RHEL and derivates,
> Ubuntu, Azul Zulu).
> >
> > (Side note: adoptopenjdk is different here, because it does not include
> the patch version in the version banner (java.version=1.8.0-adoptopenjdk),
> so difficult to check the minimum patch version on startup of C*.)
> >
> > (Attn, rant: I'm not particularly happy with the new release and support
> model for Java, because developing something now, that's about to release
> end of the year on a Java version that has not even reached
> feature-complete status, is, gently speaking, difficult. But sticking to an
> "antique" Java version (8) has its own risks as well.)
> >
> > I'm silently ignoring any Java release, that's not aimed to get any
> LTS(-ish?) support from anybody - so only Java 8 + 11 remain.
> >
> > There are generally three (IMO legit) options here: only support Java 8,
> only support Java 11, support both Java 8 and Java 11. All three options
> have a bunch of pros and cons.
> >
> > Option 1, only Java 8: Probably the safest option. Considering the
> potential lifetimes of Java 8 and C* 4.0, even the most enthusiastic
> maintainers may stop backporting security or bug fixes to OpenJDK 8. It
> might not be an issue in practice, but if there's for example a severe
> issue in the SSL/TLS area and nobody fixes it in 8, well, good luck.
> >
> > Option 2, only Java 11: The option with the most risks IMO. Java 11 is
> not even feature complete, and there a bunch of big projects that still may
> make it into 11 (think: Valhalla). There's no guarantee whether the C* code
> or any included library will actually work with Java 11 (think: if it works
> now, it may not work with the final Java version). However, it leaves the
> door wide open for all the neat and geeky things in Java 11.
> >
> > Option 3: both 8 + 11: The idea here is to default to Java 8, but the
> code also runs on 11. It leaves the option to benefit from optimizations
> that are only available on 11 while maintaining the known stability of 8.
> Initially, only the combination of C* 4.0 + Java 8 would be labeled as
> "stable" and the combination of C* 4.0 + Java 11 as "experimental". But it
> gives us time to "evaluate" 4.0 on 11. When we have enough experience with
> 11, C* on 11 can be labeled as "stable" as well. The downside of this
> "hybrid" is, that it's a bit more difficult to introduce features, that
> depend on 11.
> >
> > I think, 3) gives the best of both worlds: stability of 8 and an upgrade
> path to 11 in the future, that people can actually test with C* 4.0. Happy
> to make the patch for #9608 ready for option 3. But it would be great to
> get a consensus here for either option before we review #9608 and commit it.
> >
> > Another proposal, for both options 1+3: Raise the minimum supported
> version of 8 for C* 4.0 to something more recent than 8u40, which is quite
> from the stone-age. It could be 8u171 or whatever will be recent in autumn.
> >
> > Robert
> >
> > --
> > Robert Stupp
> > @snazy
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
> --
Jon Haddad
http://www.rustyrazorblade.com
twitter: rustyrazorblade

Re: [DISCUSS] Cassandra and future Java

[J. D. Jordan]

+1 for “Option 3: both 8 + 11” it shouldn’t be too hard to maintain code wise, 
and leaves people’s options open.

-Jeremiah

> On May 25, 2018, at 6:31 AM, Robert Stupp  wrote:
> 
> I'd like to bring up the C*/Java discussion again. It's been a while since 
> we've discussed this.
> 
> To me it sounds like there's still the question about which version(s) of 
> Java we want to support beginning with C* 4.0.
> 
> I assume, that it's legit (and probably very necessary) to assume that 
> OpenJDK is now (i.e. after Java 6) considered as "production ready" for C*. 
> The public (and legal and free) availability of Oracle's Java 8 will end in 
> January 2019 (unless you're using it privately on your desktop). Java 9 and 
> 10 are not a thing, as both will be EOL when the C* 4.0 branch is about to be 
> cut. The most recent available Java version will be 11, which is meant to be 
> publicly available from Oracle until March 2019 and should get LTS support 
> for OpenJDK 11 from major Linux distros (RHEL and derivates, Ubuntu, Azul 
> Zulu).
> 
> (Side note: adoptopenjdk is different here, because it does not include the 
> patch version in the version banner (java.version=1.8.0-adoptopenjdk), so 
> difficult to check the minimum patch version on startup of C*.)
> 
> (Attn, rant: I'm not particularly happy with the new release and support 
> model for Java, because developing something now, that's about to release end 
> of the year on a Java version that has not even reached feature-complete 
> status, is, gently speaking, difficult. But sticking to an "antique" Java 
> version (8) has its own risks as well.)
> 
> I'm silently ignoring any Java release, that's not aimed to get any 
> LTS(-ish?) support from anybody - so only Java 8 + 11 remain.
> 
> There are generally three (IMO legit) options here: only support Java 8, only 
> support Java 11, support both Java 8 and Java 11. All three options have a 
> bunch of pros and cons.
> 
> Option 1, only Java 8: Probably the safest option. Considering the potential 
> lifetimes of Java 8 and C* 4.0, even the most enthusiastic maintainers may 
> stop backporting security or bug fixes to OpenJDK 8. It might not be an issue 
> in practice, but if there's for example a severe issue in the SSL/TLS area 
> and nobody fixes it in 8, well, good luck.
> 
> Option 2, only Java 11: The option with the most risks IMO. Java 11 is not 
> even feature complete, and there a bunch of big projects that still may make 
> it into 11 (think: Valhalla). There's no guarantee whether the C* code or any 
> included library will actually work with Java 11 (think: if it works now, it 
> may not work with the final Java version). However, it leaves the door wide 
> open for all the neat and geeky things in Java 11.
> 
> Option 3: both 8 + 11: The idea here is to default to Java 8, but the code 
> also runs on 11. It leaves the option to benefit from optimizations that are 
> only available on 11 while maintaining the known stability of 8. Initially, 
> only the combination of C* 4.0 + Java 8 would be labeled as "stable" and the 
> combination of C* 4.0 + Java 11 as "experimental". But it gives us time to 
> "evaluate" 4.0 on 11. When we have enough experience with 11, C* on 11 can be 
> labeled as "stable" as well. The downside of this "hybrid" is, that it's a 
> bit more difficult to introduce features, that depend on 11.
> 
> I think, 3) gives the best of both worlds: stability of 8 and an upgrade path 
> to 11 in the future, that people can actually test with C* 4.0. Happy to make 
> the patch for #9608 ready for option 3. But it would be great to get a 
> consensus here for either option before we review #9608 and commit it.
> 
> Another proposal, for both options 1+3: Raise the minimum supported version 
> of 8 for C* 4.0 to something more recent than 8u40, which is quite from the 
> stone-age. It could be 8u171 or whatever will be recent in autumn.
> 
> Robert
> 
> -- 
> Robert Stupp
> @snazy
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

[DISCUSS] Cassandra and future Java

[Robert Stupp]

I'd like to bring up the C*/Java discussion again. It's been a while 
since we've discussed this.


To me it sounds like there's still the question about which version(s) 
of Java we want to support beginning with C* 4.0.


I assume, that it's legit (and probably very necessary) to assume that 
OpenJDK is now (i.e. after Java 6) considered as "production ready" for 
C*. The public (and legal and free) availability of Oracle's Java 8 will 
end in January 2019 (unless you're using it privately on your desktop). 
Java 9 and 10 are not a thing, as both will be EOL when the C* 4.0 
branch is about to be cut. The most recent available Java version will 
be 11, which is meant to be publicly available from Oracle until March 
2019 and should get LTS support for OpenJDK 11 from major Linux distros 
(RHEL and derivates, Ubuntu, Azul Zulu).


(Side note: adoptopenjdk is different here, because it does not include 
the patch version in the version banner 
(java.version=1.8.0-adoptopenjdk), so difficult to check the minimum 
patch version on startup of C*.)


(Attn, rant: I'm not particularly happy with the new release and support 
model for Java, because developing something now, that's about to 
release end of the year on a Java version that has not even reached 
feature-complete status, is, gently speaking, difficult. But sticking to 
an "antique" Java version (8) has its own risks as well.)


I'm silently ignoring any Java release, that's not aimed to get any 
LTS(-ish?) support from anybody - so only Java 8 + 11 remain.


There are generally three (IMO legit) options here: only support Java 8, 
only support Java 11, support both Java 8 and Java 11. All three options 
have a bunch of pros and cons.


Option 1, only Java 8: Probably the safest option. Considering the 
potential lifetimes of Java 8 and C* 4.0, even the most enthusiastic 
maintainers may stop backporting security or bug fixes to OpenJDK 8. It 
might not be an issue in practice, but if there's for example a severe 
issue in the SSL/TLS area and nobody fixes it in 8, well, good luck.


Option 2, only Java 11: The option with the most risks IMO. Java 11 is 
not even feature complete, and there a bunch of big projects that still 
may make it into 11 (think: Valhalla). There's no guarantee whether the 
C* code or any included library will actually work with Java 11 (think: 
if it works now, it may not work with the final Java version). However, 
it leaves the door wide open for all the neat and geeky things in Java 11.


Option 3: both 8 + 11: The idea here is to default to Java 8, but the 
code also runs on 11. It leaves the option to benefit from optimizations 
that are only available on 11 while maintaining the known stability of 
8. Initially, only the combination of C* 4.0 + Java 8 would be labeled 
as "stable" and the combination of C* 4.0 + Java 11 as "experimental". 
But it gives us time to "evaluate" 4.0 on 11. When we have enough 
experience with 11, C* on 11 can be labeled as "stable" as well. The 
downside of this "hybrid" is, that it's a bit more difficult to 
introduce features, that depend on 11.


I think, 3) gives the best of both worlds: stability of 8 and an upgrade 
path to 11 in the future, that people can actually test with C* 4.0. 
Happy to make the patch for #9608 ready for option 3. But it would be 
great to get a consensus here for either option before we review #9608 
and commit it.


Another proposal, for both options 1+3: Raise the minimum supported 
version of 8 for C* 4.0 to something more recent than 8u40, which is 
quite from the stone-age. It could be 8u171 or whatever will be recent 
in autumn.


Robert

--
Robert Stupp
@snazy


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org