On Wed, Mar 21, 2018 at 9:00 AM, Josh McKenzie <jmcken...@apache.org> wrote: >> 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.
Do we know this though? More frequent releases should also mean that each new release has accumulated less change (the typical trade-off). Also, these JDKs are supposed to be backward compatible, if this isn't the case because (for example) we are (ab)using private interfaces, that's probably worth looking at anyway. > 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 > -- Eric Evans john.eric.ev...@gmail.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
