Re: [DISCUSS] Cassandra and future Java
Personally I don’t mind dropping support for previsous java versions.
On Fri, May 25, 2018 at 6:33 AM J. D. Jordan <jeremiah.jordan@xxxxxxxxx>
> +1 for “Option 3: both 8 + 11” it shouldn’t be too hard to maintain code
> wise, and leaves people’s options open.
> > On May 25, 2018, at 6:31 AM, Robert Stupp <snazy@xxxxxxxx> 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-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> > For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx