> Wasn't portability supposed to be one of the > big selling points of Java? Historically, yes, but their change in release cadence and support structure is something they're pushing, not us. We have to figure out how to make the best of a change that is, at best, orthogonal to our interests as a project.
Maintaining portability within a few releases of the JDK for each supported version of C* is a non-trivial amount of work with a 6 month refresh timer on it. On Wed, Mar 21, 2018 at 9:49 AM, Eric Evans <eev...@wikimedia.org> wrote: > On Wed, Mar 21, 2018 at 8:04 AM, Stefan Podkowinski <s...@apache.org> wrote: > >> There's also another option, which I just want to mention here for the >> sake of discussion. >> >> Quoting the Oracle Support Roadmap: >> "Instead of relying on a pre-installed standalone JRE, we encourage >> application developers to deliver JREs with their applications." >> >> I've played around with Java 9 a while ago and also tested creating a >> self contained JRE using jlink, which you can bundle and ship with your >> application. So there's a technical solution for that with Java 9. Of >> course you'd have to clarify licensing issues (OpenJDK is GPLv2 + >> Classpath exception) first. >> >> Bundling a custom JRE along with Cassandra, would be convenient in a way >> that we can do all the testing against the bundled Java version. We >> could also switch to a new Java version whenever it fits us. Like e.g. >> apache-cassandra-4.0.14_openjdk11u321 and two months later release >> apache-cassandra-4.0.15_openjdk12u123. History has shown that planing >> and timing new releases isn't always working out for us as expected. I'd >> rather prefer not having to tightly coordinate our own releases together >> with OpenJDK releases, if it can be avoided. At the same time I'd like >> to avoid having users updating to incompatible JREs (think about >> 8u161/#14173), or have them constantly ask which JRE version to use for >> which Cassandra version, always with the risk of automatic updates >> causing unexpected issues. Bundling the JRE may help us with that, as it >> would become more a matter of testing and getting CI turn green, before >> we're ready to bundle the next major JRE update, without getting the >> user involved at all. >> >> If you would prefer using a global system JRE, that should still be >> possible by installing an unbundled Cassandra version, but you'd have to >> pay attention which Java version to use for which Cassandra release, >> possibly having to provide patches and do some testing for more recent >> Cassandra versions, in case of compatibility issues. If we update 3.11 >> to Java 13 in mid 2019, we'd have to provide release candidates that can >> be used for testing for such incompatibilities by LTS users and have >> them provide patches, which then have to fully work with Java 13 of >> course. Otherwise I can't see how to make Oracle/Redhat/IBM/Azul LTS >> releases work, except on this best effort basis without official support >> guarantees by us. >> >> I'm not too enthusiastic about this perspective. But I wouldn't >> completely dismiss it either, without talking about all the other >> options first. >> > > Personally, I don't like the idea of vendoring like this at all. Wasn't > portability supposed to be one of the big selling points of Java? Wouldn't > our efforts be better directed at being portable to within a few releases > of the JDK, than to tightly couple it to once specific version? > > >> On 20.03.2018 22:32, Ariel Weisberg wrote: >> > Hi, >> > >> > Synchronizing with Oracle LTS releases is kind of low value if it's a >> paid offering. But if someone in the community doesn't want to upgrade and >> pays Oracle we don't want to get in the way of that. >> > >> > Which is how you end up with what Jordan and ElasticSearch suggest. I'm >> still +1 on that although in my heart of hearts I want to only support the >> latest OpenJDK on trunk and after we cut a release only change the JDK if >> there is a serious issue. >> > >> > It's going to be annoying once we have a serious security or correctness >> issue and we need to move to a later OpenJDK. The majority won't be paying >> Oracle for LTS. I don't think that will happen that often though. >> > >> > Regards, >> > Ariel >> > >> > If that ends up not working and we find it's a problem to not be getting >> > On Tue, Mar 20, 2018, at 4:50 PM, Jason Brown wrote: >> >> Thanks to Hannu and others pointing out that the OracleJDK is a >> >> *commercial* LTS, and thus not an option. mea culpa for missing the >> >> "commercial" and just focusing on the "LTS" bit. OpenJDK is is, then. >> >> >> >> Stefan's elastic search link is rather interesting. Looks like they are >> >> compiling for both a LTS version as well as the current OpenJDK. They >> >> assume some of their users will stick to a LTS version and some will run >> >> the current version of OpenJDK. >> >> >> >> While it's extra work to add JDK version as yet another matrix variable >> in >> >> addition to our branching, is that something we should consider? Or are >> we >> >> going to burden maintainers even more? Do we have a choice? Note: I >> think >> >> this is similar to what Jeremiah is proposed. >> >> >> >> @Ariel: Going beyond 3 years could be tricky in the worst case because >> >> bringing in up to 3 years of JDK changes to an older release might mean >> >> some of our dependencies no longer function and now it's not just minor >> >> fixes it's bringing in who knows what in terms of updated dependencies >> >> >> >> I'm not sure we have a choice anymore, as we're basically bound to what >> the >> >> JDK developers choose to do (and we're bound to the JDK ...). However, >> if >> >> we have the changes necessary for the JDK releases higher than the LTS >> (if >> >> we following the elastic search model), perhaps it'll be a reasonably >> >> smooth transition? >> >> >> >> On Tue, Mar 20, 2018 at 1:31 PM, Jason Brown <jasedbr...@gmail.com> >> wrote: >> >> >> >>> copied directly from dev channel, just to keep with this ML >> conversation >> >>> >> >>> 08:08:26 <snazy> Robert Stupp jasobrown: https://www.azul.com/java- >> >>> stable-secure-free-choose-two-three/ and >> https://blogs.oracle.com/java- >> >>> platform-group/faster-and-easier-use-and-redistribution-of-java-se >> >>> 08:08:38 the 2nd says: "The Oracle JDK will continue as a commercial >> long >> >>> term support offering" >> >>> 08:08:46 also: http://www.oracle.com/technetwork/java/eol-135779.html >> >>> 08:09:21 the keyword in that cite is "commercial" >> >>> 08:21:21 <exlt> Michael Shuler a couple more thoughts.. 1) keep C* >> >>> support in step with latest Ubuntu LTS OpenJDK major in main, 2) >> bundle JRE >> >>> in C* releases? (JDK is not "legal" to bundle) >> >>> 08:23:44 <spodkowinski> https://www.elastic.co/blog/elasticsearch- >> >>> java-9-and-beyond - interesting read on that matter >> >>> 08:26:04 can't wait for the infra and CI testing implications.. will be >> >>> lot's of fun ;( >> >>> 08:42:13 <snazy> Robert Stupp Not sure whether stepping with Ubuntu is >> >>> necessary. It's not so difficult to update apt.source ;) >> >>> 08:42:43 CI ? It just let's your test matrix explode - a litte ;) >> >>> 08:46:48 <exlt> Michael Shuler yep, we currently `def jdkLabel = 'JDK >> 1.8 >> >>> (latest)'` in job DSL and could easily modify that >> >>> >> >>> On Tue, Mar 20, 2018 at 9:08 AM, Kant Kodali <k...@peernova.com> >> wrote: >> >>> >> >>>> Java 10 is releasing today! >> >>>> >> >>>> On Tue, Mar 20, 2018 at 9:07 AM, Ariel Weisberg <ar...@weisberg.ws> >> >>>> wrote: >> >>>> >> >>>>> Hi, >> >>>>> >> >>>>> +1 to what Jordan is saying. >> >>>>> >> >>>>> It seems like if we are cutting a release off of trunk we want to >> make >> >>>>> sure we get N years of supported JDK out of it. For a single LTS >> >>>> release N >> >>>>> could be at most 3 and historically that isn't long enough and it's >> very >> >>>>> likely we will get < 3 after a release is cut. >> >>>>> >> >>>>> Going beyond 3 years could be tricky in the worst case because >> bringing >> >>>> in >> >>>>> up to 3 years of JDK changes to an older release might mean some of >> our >> >>>>> dependencies no longer function and now it's not just minor fixes >> it's >> >>>>> bringing in who knows what in terms of updated dependencies. >> >>>>> >> >>>>> I think in some cases we are going to need to take a release we have >> >>>>> already cut and make it work with an LTS release that didn't exist >> when >> >>>> the >> >>>>> release was cut. >> >>>>> >> >>>>> We also need to update how CI works. We should at least build and >> run a >> >>>>> quick smoke test with the JDKs we are claiming to support and >> >>>>> asynchronously run all the tests on the rather large matrix that now >> >>>> exists. >> >>>>> >> >>>>> Ariel >> >>>>> >> >>>>> On Tue, Mar 20, 2018, at 11:07 AM, Jeremiah Jordan wrote: >> >>>>>> My suggestion would be to keep trunk on the latest LTS by default, >> but >> >>>>>> with compatibility with the latest release if possible. Since >> Oracle >> >>>>>> LTS releases are every 3 years, I would not want to tie us to that >> >>>>>> release cycle? >> >>>>>> So until Java 11 is out that would mean trunk should work under Java >> >>>> 8, >> >>>>>> with the option of being compiled/run under Java 9 or 10. Once Java >> >>>> 11 >> >>>>>> is out we could then switch to 11 only. >> >>>>>> >> >>>>>> -Jeremiah >> >>>>>> >> >>>>>> On Mar 20, 2018, at 10:48 AM, Jason Brown <jasedbr...@gmail.com> >> >>>> wrote: >> >>>>>> >> >>>>>>>>> Wouldn't that potentially leave us in a situation where we're >> >>>> ready >> >>>>> for >> >>>>>>> a C* release but blocked waiting on a new LTS cut? >> >>>>>>> >> >>>>>>> Agreed, and perhaps if we're close enough to a LTS release (say >> >>>> three >> >>>>>>> months or less), we could choose to delay (probably with community >> >>>>>>> input/vote). If we're a year or two out, then, no, we should not >> >>>> wait. >> >>>>> I >> >>>>>>> think this is what I meant to communicate by "Perhaps we can >> >>>> evaluate >> >>>>> this >> >>>>>>> over time." (poorly stated, in hindsight) >> >>>>>>> >> >>>>>>>> On Tue, Mar 20, 2018 at 7:22 AM, Josh McKenzie < >> >>>> jmcken...@apache.org> >> >>>>> wrote: >> >>>>>>>> >> >>>>>>>> Need a little clarification on something: >> >>>>>>>> >> >>>>>>>>> 2) always release cassandra on a LTS version >> >>>>>>>> combined with: >> >>>>>>>>> 3) keep trunk on the lasest jdk version, assumming we release a >> >>>> major >> >>>>>>>>> cassandra version close enough to a LTS release. >> >>>>>>>> >> >>>>>>>> Wouldn't that potentially leave us in a situation where we're >> ready >> >>>>>>>> for a C* release but blocked waiting on a new LTS cut? For >> >>>> example, if >> >>>>>>>> JDK 9 were the currently supported LTS and trunk was on JDK 11, >> >>>> we'd >> >>>>>>>> either have to get trunk to work with 9 or wait for 11 to resolve >> >>>>>>>> that. >> >>>>>>>> >> >>>>>>>>> On Tue, Mar 20, 2018 at 9:32 AM, Jason Brown < >> >>>> jasedbr...@gmail.com> >> >>>>> wrote: >> >>>>>>>>> Hi all, >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> TL;DR Oracle has started revving the JDK version much faster, and >> >>>> we >> >>>>> need >> >>>>>>>>> an agreed upon plan. >> >>>>>>>>> >> >>>>>>>>> Well, we probably should has this discussion this already by now, >> >>>> but >> >>>>>>>> here >> >>>>>>>>> we are. Oracle announced plans to release updated JDK version >> >>>> every >> >>>>> six >> >>>>>>>>> months, and each new version immediate supercedes the previous in >> >>>> all >> >>>>>>>> ways: >> >>>>>>>>> no updates/security fixes to previous versions is the main thing, >> >>>> and >> >>>>>>>>> previous versions are EOL'd immediately. In addition, Oracle has >> >>>>> planned >> >>>>>>>>> parallel LTS versions that will live for three years, and then >> >>>>> superceded >> >>>>>>>>> by the next LTS; but not immediately EOL'd from what I can tell. >> >>>>> Please >> >>>>>>>> see >> >>>>>>>>> [1, 2] for Oracle's offical comments about this change ([3] was >> >>>>>>>>> particularly useful, imo), [4] and many other postings on the >> >>>>> internet >> >>>>>>>> for >> >>>>>>>>> discussion/commentary. >> >>>>>>>>> >> >>>>>>>>> We have a jira [5] where Robert Stupp did most of the work to get >> >>>> us >> >>>>> onto >> >>>>>>>>> Java 9 (thanks, Robert), but then the announcement of the JDK >> >>>> version >> >>>>>>>>> changes happened last fall after Robert had done much of the work >> >>>> on >> >>>>> the >> >>>>>>>>> ticket. >> >>>>>>>>> >> >>>>>>>>> Here's an initial proposal of how to move forward. I don't >> suspect >> >>>>> it's >> >>>>>>>>> complete, but a decent place to start a conversation. >> >>>>>>>>> >> >>>>>>>>> 1) receommend OracleJDK over OpenJDK. IIUC from [3], the OpenJDK >> >>>> will >> >>>>>>>>> release every six months, and the OracleJDK will release every >> >>>> three >> >>>>>>>> years. >> >>>>>>>>> Thus, the OracleJDK is the LTS version, and it just comes from a >> >>>>> snapshot >> >>>>>>>>> of one of those OpenJDK builds. >> >>>>>>>>> >> >>>>>>>>> 2) always release cassandra on a LTS version. I don't think we >> can >> >>>>>>>>> reasonably expect operators to update the JDK every six months, >> on >> >>>>> time. >> >>>>>>>>> Further, if there are breaking changes to the JDK, we don't want >> >>>> to >> >>>>> have >> >>>>>>>> to >> >>>>>>>>> update established c* versions due to those changes, every six >> >>>>> months. >> >>>>>>>>> >> >>>>>>>>> 3) keep trunk on the lasest jdk version, assumming we release a >> >>>> major >> >>>>>>>>> cassandra version close enough to a LTS release. Currently that >> >>>> seems >> >>>>>>>>> reasonable for cassandra 4.0 to be released with java 11 (18.9 >> >>>> LTS) >> >>>>>>>>> support. Perhaps we can evaluate this over time. >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Once we agree on a path forward, *it is impreative that we >> publish >> >>>>> the >> >>>>>>>>> decision to the docs* so we can point contributors and operators >> >>>>> there, >> >>>>>>>>> instead of rehashing the same conversation. >> >>>>>>>>> >> >>>>>>>>> I look forward to a lively discussion. Thanks! >> >>>>>>>>> >> >>>>>>>>> -Jason >> >>>>>>>>> >> >>>>>>>>> [1] http://www.oracle.com/technetwork/java/eol-135779.html >> >>>>>>>>> [2] >> >>>>>>>>> https://blogs.oracle.com/java-platform-group/faster-and- >> >>>>>>>> easier-use-and-redistribution-of-java-se >> >>>>>>>>> [3] >> >>>>>>>>> https://www.oracle.com/java/java9-screencasts.html?bcid= >> >>>>>>>> 5582439790001&playerType=single-social&size=events >> >>>>>>>>> [4] >> >>>>>>>>> http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live. >> >>>>>>>> html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+ >> >>>>>>>> StephenColebournesBlog+%28Stephen+Colebourne%27s+blog%29 >> >>>>>>>>> [5] https://issues.apache.org/jira/browse/CASSANDRA-9608 >> >>>>>>>> >> >>>>>>>> ------------------------------------------------------------ >> >>>> --------- >> >>>>>>>> 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 >> >>>>> >> >>>>> >> >>>> >> >>> >> >>> >> > >> > --------------------------------------------------------------------- >> > 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 >> >> > > > -- > Eric Evans > eev...@wikimedia.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
