I say we give it a few weeks and let adoptopenjdk make an official statement before we make any kind of plan. We're not in a great rush.
On Mon., 26 Mar. 2018, 05:49 Carl Mueller, <carl.muel...@smartthings.com> wrote: > And here we go! > > from here: > https://www.reddit.com/r/java/comments/86ce66/java_long_term_support/ > > AdoptOpenJDK (https://www.adoptopenjdk.net) is a new non-profit community > build farm that will be providing LTS support (that means we will keep Java > 11, 17 etc up to date with security and stability patches) for OpenJDK > binaries for all platforms matching Oracle’s LTS roadmap (but for more > platforms and OpenJDK derivatives. > > We’ve just produced our first TCK passing builds and hope to have > everything ironed out by Java 11. > > Most of the major OpenJDK vendors are participating in this (Oracle, IBM, > Red Hat et al). The goal is for this to be shared common infrastructure for > all. > > Commercial vendors may choose to provide commercial support over and above > this 🙂 > > Disclaimer: I'm the chief Cat herder at the AdoptOpenJDK build farm. > > More tech details: https://ci.adoptopenjdk.net and > https://www.github.com/AdoptOpenJDK (start with the TSC repo) > > > On Sat, Mar 24, 2018 at 5:14 AM, Robert Stupp <sn...@gmx.de> wrote: > > > The current (old-ish) status of #9608 requires to be built on Java 8, but > > runs on both Java 8 and Java 9 (and should on 10). It comes with the > > inconvenience that there are two (new) jvm.options files for the > specifics > > of 8 and 9. This was done to make it a no-brainer to start in on either 8 > > or 9/10 - think: CI. It's not trivial but otoh also not complex and some > > changes in #9608 are already superfluous (#14173). Multi-release jars > > aren't required. > > > > At the moment I do not see any _major_ blocker that prevents a hybrid, > but > > having support for both 8 + 11 in 4.0 is not an appealing option IMO. It > > was ok at the time I built the initial patch, but I no longer think it's > > the "right" way. > > > > I think, option 1) here is the right way, considering the release date > > (maybe end of this year?) and the lifetime of 4.0. It's certainly a risk > at > > this point, but maybe less than the hassle to support 4.0 w/ Java 8 in > the > > next years. However, if I understand option 3) correctly and 4.0 and 4.1 > > only differ by the required Java version, I agree that this is also a > good > > option. > > > > TL;DR I'd vote for option 1, but would also be fine with 3, not ok with 2 > > > > > > On 03/23/2018 10:03 AM, Stefan Podkowinski wrote: > > > >> I think it's pretty safe to assume that Java 8 will stay around much > >> longer than by the end of the year, after Oracle dropped their official > >> maintainer role. I also think that we don't have to worry that much how > >> exactly Java 8 is going to be supported. It's a mature enough version > >> that I wouldn't expect significant incompatibilities between back-ports > >> or forks. In the best case, someone will even step up taking the > >> official maintainer role as part of the OpenJDK project. But I'm pretty > >> sure we'll manage to keeping up supporting Java 8 for Cassandra > >> throughout the next years, if we decide to do so. > >> > >> At the beginning, we've discussed the elastic search plans of supporting > >> the newest Java release and the latest LTS release at the same time. > >> Maybe it's a good time to get back thinking about this idea again and > >> ask us, do we really want to support the latest Java release, even if > >> it's a non-LTS release? Given the likely overlap of new major Java > >> releases and continued support for already released Cassandra branches, > >> I'd expect this to become a strain for developers and possible source of > >> confusion for users. Do we as developers or any users really care that > >> much about non-LTS releases in general, that we want to commit us to > that? > >> > >> Let's assume we're only going to support Java LTS releases for now. How > >> exactly would we want to go on from here? Keep in mind that Java 11 LTS > >> is already scheduled for September. Let's take a look at some LTS only > >> options: > >> > >> 1) Release 4.0 for Java 11 exclusively (3.11 for Java 8) > >> > >> Start upgrading CI to initial Java 11 release candidate, merge Robert's > >> Java 9 patch and start fixing all incompatibility issues. Release 4.0 at > >> some point after Java 11. This is probably the most risky option, as we > >> can't see yet how the Java 11 adoption rate will turn out to be. In the > >> worst case, Java 8 will still dominate for times to come and depending > >> on Java 11 as hard requirement may hurt 4.0 adoption. > >> > >> 2) Release 4.0 for Java 8 + 11 > >> > >> Support both LTS versions for 4.0. I'd expect this to be non-trivial, > >> but maybe Robert can share some first hand experience what would have to > >> be done to make this possible. As described in the elastic search blog, > >> what they plan to do is to create multi-release jars for code compiled > >> against different versions, which is only possible starting with Java 9. > >> We don't even have that and would still have to make sure the same code > >> runs on both 8 and 11. > >> > >> 3) Release 4.0 for Java 8, branch 4.1 for Java 11 later > >> > >> Don't do anything yet and release 4.0 for Java 8. Keep an eye on how the > >> situation unfolds during the next months and how fast Java 11 will be > >> adopted by Cassandra users. Branch 4.1 for Java 11, if there's public > >> demand and we agree that it makes sense at that point. This is basically > >> an incremental approach to 1), but we'll end up with another branch, > >> which we also would have to support in the future (4.0 for 8, 4.1 for > 11). > >> > >> > >> > >> > >> On 22.03.2018 23:30, Michael Shuler wrote: > >> > >>> As I mentioned in IRC and was pasted earlier in the thread, I believe > >>> the easiest path is to follow the major releases of OpenJDK in the > >>> long-term-support Linux OS releases. Currently, Debian Stable > (Stretch), > >>> Ubuntu 16.04 (Bionic (near release)), and Red Hat / CentOS 7 all have > >>> OpenJDK 8 as the default JDK. For long-term support, they all have > build > >>> facilities in place for their supported architectures and developers > >>> that care about security updates for users through their documented EOL > >>> dates. > >>> > >>> The current deb and rpm packages for Apache Cassandra all properly > >>> depend on OpenJDK 8, so there's really nothing to be done here, until > >>> the project decides to implicitly depend on a JDK version not easily > >>> installable on the major OS LTS releases. (Users of older OS versions > >>> may need to fiddle with yum and apt sources to get OpenJDK 8, but this > >>> is a relatively solved problem.) > >>> > >>> Users have the ability to deviate and set a JAVA_HOME env var to use a > >>> custom-installed JDK of their liking, or go down the `alternatives` > path > >>> of their favorite OS. > >>> > >>> 1) I don't think we should be get into the business of distributing > >>> Java, even if licensing allowed it. > >>> 2) The OS vendors are in the business of keeping users updated with > >>> upstream releases of Java, so there's no reason not to utilize them. > >>> > >>> Michael > >>> > >>> On 03/22/2018 05:12 PM, Jason Brown wrote: > >>> > >>>> See the legal-discuss@ thread: > >>>> https://mail-archives.apache.org/mod_mbox/www-legal-discuss/ > >>>> 201803.mbox/browser > >>>> . > >>>> > >>>> TL;DR jlink-based distributions are not gonna fly due to OpenJDK's > >>>> license, > >>>> so let's focus on other paths forward. > >>>> > >>>> > >>>> On Thu, Mar 22, 2018 at 2:04 PM, Carl Mueller < > >>>> carl.muel...@smartthings.com> > >>>> wrote: > >>>> > >>>> Is OpenJDK really not addressing this at all? Is that because OpenJDK > is > >>>>> beholden to Oracle somehow? This is a major disservice to Apache and > >>>>> the > >>>>> java ecosystem as a whole. > >>>>> > >>>>> When java was fully open sourced, it was supposed to free the > >>>>> ecosystem to > >>>>> a large degree from Oracle. Why is OpenJDK being so uncooperative? > Are > >>>>> they > >>>>> that resource strapped? Can no one, from consulting empires, Google, > >>>>> IBM, > >>>>> Amazon, and a host of other major companies take care of this? > >>>>> > >>>>> This is basically OpenSSL all over again. > >>>>> > >>>>> Deciding on a way to get a stable language runtime isn't our job. > It's > >>>>> the > >>>>> job of either the runtime authors (OpenJDK) or another group that > >>>>> should > >>>>> form around it. > >>>>> > >>>>> There is no looming deadline on this, is there? Can we just let the > >>>>> dust > >>>>> settle on this in the overall ecosystem to see what happens? And > again, > >>>>> what is the Apache Software Foundation's approach to this that > affects > >>>>> so > >>>>> many of their projects? > >>>>> > >>>>> On Wed, Mar 21, 2018 at 12:55 PM, Jason Brown <jasedbr...@gmail.com> > >>>>> wrote: > >>>>> > >>>>> Well, that was quick. TL;DR Redistributing any part of the OpenJDK is > >>>>>> basically a no-go. > >>>>>> > >>>>>> Thus, that option is off the table. > >>>>>> > >>>>>> On Wed, Mar 21, 2018 at 10:46 AM, Jason Brown <jasedbr...@gmail.com > > > >>>>>> wrote: > >>>>>> > >>>>>> ftr, I've sent a message to legal-discuss to inquire about the > >>>>>>> > >>>>>> licensing > >>>>> > >>>>>> aspect of the OpenJDK as we've been discussing. I believe anyone can > >>>>>>> > >>>>>> follow > >>>>>> > >>>>>>> the thread by subscribing to the legal-discuss@ ML, or you can > wait > >>>>>>> > >>>>>> for > >>>>> > >>>>>> updates on this thread as I get them. > >>>>>>> > >>>>>>> On Wed, Mar 21, 2018 at 9:49 AM, Jason Brown <jasedbr...@gmail.com > > > >>>>>>> > >>>>>> wrote: > >>>>>> > >>>>>>> If we went down this path, I can't imagine we would build OpenJDK > >>>>>>>> ourselves, but probably build a release with jlink or > javapackager. > >>>>>>>> I > >>>>>>>> haven't done homework on that yet, but i *think* it uses a blessed > >>>>>>>> > >>>>>>> OpenJDK > >>>>>> > >>>>>>> release for the packaging (or perhaps whatever JDK you happen to be > >>>>>>>> compiling/building with). Thus as long as we build/release when an > >>>>>>>> > >>>>>>> openJDK > >>>>>> > >>>>>>> rev is released, we would hypothetically be ok from a secutiry POV. > >>>>>>>> > >>>>>>>> That being said, Micke's points about multiple architectures and > >>>>>>>> other > >>>>>>>> OSes (Windows for sure, macOS not so sure) are a legit concern as > >>>>>>>> > >>>>>>> those > >>>>> > >>>>>> would need to be separate packages, with separate CI/testing and so > on > >>>>>>>> > >>>>>>> :( > >>>>>> > >>>>>>> I'm not sure betting the farm on linux disto support is the path to > >>>>>>>> happiness, either. Not everyone uses one of the distros mentioned > >>>>>>>> (RH, > >>>>>>>> ubuntu), nor does everyone use linux (sure, the vast majority is > >>>>>>>> > >>>>>>> Linux/x86, > >>>>>> > >>>>>>> but we do support Windows deployment and macOS development). > >>>>>>>> > >>>>>>>> -Jason > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Wed, Mar 21, 2018 at 9:26 AM, Michael Burman < > >>>>>>>> mibur...@redhat.com> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>> On 03/21/2018 04:52 PM, Josh McKenzie wrote: > >>>>>>>>> > >>>>>>>>> This would certainly mitigate a lot of the core problems with the > >>>>>>>>> new > >>>>>>>>> > >>>>>>>>>> release model. Has there been any public statements of > >>>>>>>>>> plans/intent > >>>>>>>>>> with regards to distros doing this? > >>>>>>>>>> > >>>>>>>>>> Since the latest official LTS version is Java 8, that's the only > >>>>>>>>> one > >>>>>>>>> with publicly available information For RHEL, OpenJDK8 will > receive > >>>>>>>>> > >>>>>>>> updates > >>>>>> > >>>>>>> until October 2020. "A major version of OpenJDK is supported for a > >>>>>>>>> > >>>>>>>> period > >>>>>> > >>>>>>> of six years from the time that it is first introduced in any > version > >>>>>>>>> > >>>>>>>> of > >>>>>> > >>>>>>> RHEL, or until the retirement date of the underlying RHEL platform > , > >>>>>>>>> whichever is earlier." [1] > >>>>>>>>> > >>>>>>>>> [1] https://access.redhat.com/articles/1299013 > >>>>>>>>> > >>>>>>>>> In terms of the burden of bugfixes and security fixes if we > >>>>>>>>> bundled a > >>>>>>>>> > >>>>>>>>>> JRE w/C*, cutting a patch release of C* with a new JRE > >>>>>>>>>> distribution > >>>>>>>>>> would be a really low friction process (add to build, check CI, > >>>>>>>>>> > >>>>>>>>> green, > >>>>> > >>>>>> done), so I don't think that would be a blocker for the concept. > >>>>>>>>>> > >>>>>>>>>> And do we have someone actively monitoring CVEs for this? Would > we > >>>>>>>>>> > >>>>>>>>> ship > >>>>>> > >>>>>>> a version of OpenJDK which ensures that it works with all the major > >>>>>>>>> distributions? Would we run tests against all the major > >>>>>>>>> distributions > >>>>>>>>> > >>>>>>>> for > >>>>>> > >>>>>>> each of the OpenJDK version we would ship after each CVE with each > >>>>>>>>> Cassandra version? Who compiles the OpenJDK distribution we would > >>>>>>>>> > >>>>>>>> create > >>>>>> > >>>>>>> (which wouldn't be the official one if we need to maintain support > >>>>>>>>> > >>>>>>>> for > >>>>> > >>>>>> each > >>>>>> > >>>>>>> distribution we support) ? What if one build doesn't work for one > >>>>>>>>> > >>>>>>>> distro? > >>>>>> > >>>>>>> Would we not update that CVE? OpenJDK builds that are in the > distros > >>>>>>>>> > >>>>>>>> are > >>>>>> > >>>>>>> not necessarily the pure ones from the upstream, they might include > >>>>>>>>> > >>>>>>>> patches > >>>>>> > >>>>>>> that provide better support for the distribution - or even fix bugs > >>>>>>>>> > >>>>>>>> that > >>>>>> > >>>>>>> are not yet in the upstream version. > >>>>>>>>> > >>>>>>>>> I guess we also need the Windows versions, maybe the PowerPC & > ARM > >>>>>>>>> versions also at some point. I'm not sure if we plan to support > J9 > >>>>>>>>> or > >>>>>>>>> > >>>>>>>> other > >>>>>> > >>>>>>> JVMs at some point. > >>>>>>>>> > >>>>>>>>> We would also need to create CVE reports after each Java CVE for > >>>>>>>>> Cassandra as well I would assume since it would affect us > >>>>>>>>> separately > >>>>>>>>> > >>>>>>>> (and > >>>>>> > >>>>>>> updating only the Java wouldn't help). > >>>>>>>>> > >>>>>>>>> To me this sounds like an understatement of the amount of work > that > >>>>>>>>> would go to this. Not to mention the bad publicity if Java CVEs > are > >>>>>>>>> > >>>>>>>> not > >>>>> > >>>>>> actually patched instantly in the Cassandra also (and then each user > >>>>>>>>> > >>>>>>>> would > >>>>>> > >>>>>>> have to validate that the shipped version actually works with their > >>>>>>>>> installation in their hardware since they won't get support for > it > >>>>>>>>> > >>>>>>>> from the > >>>>>> > >>>>>>> vendors as it's unofficial package). > >>>>>>>>> > >>>>>>>>> - Micke > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> ------------------------------------------------------------ > >>>>>>>>> > >>>>>>>> --------- > >>>>> > >>>>>> 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 > >> > >> > > -- > > Robert Stupp > > @snazy > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
