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 <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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
