Similar to Josh, I like Stefan's idea, a lot. iirc, the Basho folks used to ship a specific version of erlang with Riak, so it's not a new precedent in the (nosql) database space. I'm not sure about the licensing, though, as openjdk is GPLv2 w/ classpath exception - but I can ask Apache Legal about it.
On Wed, Mar 21, 2018 at 6:10 AM, Josh McKenzie <jmcken...@apache.org> wrote: > As a gut check, the idea of bundling a JRE with C* appeals to me from > a "control your variables" perspective. Simplifies quite a bit of this > problem imo. > > On Wed, Mar 21, 2018 at 9: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. > > > > > > 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
