I was reading up on the bundling possibility the other day as well. I like the idea from release standpoint. And if someone wants to use a different version they can always recompile it themselves. As Stefan pointed out, the main issue I see is the one of how licensing plays out with this.
-Jeremiah > On 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
