osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DISCUSS] java 9 and the future of cassandra on the jdk


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.mueller@xxxxxxxxxxxxxxx>
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 <snazy@xxxxxx> 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.mueller@xxxxxxxxxxxxxxx>
> >>>> 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 <jasedbrown@xxxxxxxxx>
> >>>>> 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 <jasedbrown@xxxxxxxxx
> >
> >>>>>> 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 <jasedbrown@xxxxxxxxx
> >
> >>>>>>>
> >>>>>> 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 <
> >>>>>>>> miburman@xxxxxxxxxx>
> >>>>>>>> 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-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> >>>>>>>>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> >>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> >>>
> >>> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> >> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> >>
> >>
> > --
> > Robert Stupp
> > @snazy
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> > For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> >
> >
>