Personally I don’t mind dropping support for previsous java versions. On Fri, May 25, 2018 at 6:33 AM J. D. Jordan <jeremiah.jor...@gmail.com> 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 <sn...@snazy.de> 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
