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 <s...@apache.org> 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 <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 >
signature.asc
Description: Message signed with OpenPGP
