+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
