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

[Jason Brown <ja...@gmail.com>]

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

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

[Gerald Henriksen <gh...@gmail.com>]

On Tue, 20 Mar 2018 16:26:30 -0500, you wrote:

>So this is basically Oracle imposing a rapid upgrade path on free users to
>force them to buy commercial to get LTS stability?
>
>This will probably shake out in the community somehow. Cassandra is complex
>but we are small fry in the land of IT supports and Enterprise upgrades.
>Something will organize around OpenJDK I'd guess. There's probably a

Don't forget that the commercial Linux distributions support what they
ship.

So for example if you purchase Red Hat Enterprise Linux they current
will provide support for Java 8 until October 2020(*).

I assume Ubuntu does something similar.

The only ones likely to be hurt by Oracle's actions are anyone who is
running anything Java based on either Windows or MacOS.

*https://access.redhat.com/articles/1299013

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Jason Brown <ja...@gmail.com>]

fwiw, a naive internet search turned up [1]. tl;dr use the java 9's jlink
(or java8's javapackager) to build a full app+jre package for distribution.

I started digging into the legal aspects, and (trying to) searching
legal-discuss@. May just send an email to them later today to speed up this
discovery process.

[1]
https://steveperkins.com/using-java-9-modularization-to-ship-zero-dependency-native-apps/

On Wed, Mar 21, 2018 at 8:25 AM, Stefan Podkowinski <sp...@apache.org> wrote:

> On 21.03.2018 15:41, Ariel Weisberg wrote:
> > I'm not clear on what building and bundling our own JRE/JDK accomplishes?
>
> If we talk about OpenJDK, there will be only a single Java version
> supported at any time and that is the latest Java version (11, 12, ..).
> There is no overlap between supported versions. Therefor it doesn't
> really make a lot of sense for us to officially support "a few releases
> of the JDK" when we talk about OpenJDK releases. What we'd have to do is
> to keep up with new Java versions by testing them and updating our code
> base if necessary. Keep in mind that branches like 4.0 and 3.11 will
> span several Java versions.
>
> We can do this by communicating a list of branches and corresponding
> Java releases that are officially supported. But we can also just bundle
> and ship the latest OpenJDK release that we know is to be working for
> any Cassandra branch right away, which would avoid any incompatibility
> issues between our releases and JREs installed by the user and is
> probably easier for everyone. But thats pretty much the biggest selling
> point on bundling the JRE, but will probably not happen anyway due to
> the licensing restrictions.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>

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

[Stefan Podkowinski <sp...@apache.org>]

On 21.03.2018 15:41, Ariel Weisberg wrote:
> I'm not clear on what building and bundling our own JRE/JDK accomplishes? 

If we talk about OpenJDK, there will be only a single Java version
supported at any time and that is the latest Java version (11, 12, ..).
There is no overlap between supported versions. Therefor it doesn't
really make a lot of sense for us to officially support "a few releases
of the JDK" when we talk about OpenJDK releases. What we'd have to do is
to keep up with new Java versions by testing them and updating our code
base if necessary. Keep in mind that branches like 4.0 and 3.11 will
span several Java versions.

We can do this by communicating a list of branches and corresponding
Java releases that are officially supported. But we can also just bundle
and ship the latest OpenJDK release that we know is to be working for
any Cassandra branch right away, which would avoid any incompatibility
issues between our releases and JREs installed by the user and is
probably easier for everyone. But thats pretty much the biggest selling
point on bundling the JRE, but will probably not happen anyway due to
the licensing restrictions.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Ariel Weisberg <ar...@weisberg.ws>]

Hi,

I'm not clear on what building and bundling our own JRE/JDK accomplishes? What is our source for JRE updates going to be? Are we going to build our own and does Oracle release the source for their LTS releases? Are we going to extract LTS updates from CentOS?

If the goal of bundling is to simplify upgrading the JRE/JDK for users by synchronizing it with updating Cassandra, well I think that isn't so bad. Sure it's a responsibility on our part, but if we can extract the Ubuntu or CentOS build it's "just" a matter of getting the latest bug fix JRE/JDK every time we cut a minor release. However it's us taking responsibility for it when we didn't previously and I don't see why we can't just document where to get updates from instead of bundling it ourselves.

Is there a licensing issue that forces us to just ship the JRE vs JDK or is it about download size? For release builds just the JRE is fine, but for building from source it would be nice if it bundled or fetched the full JDK. If we can avoid checking in a large binary distribution that would also be good.

Ariel

On Wed, Mar 21, 2018, at 10:21 AM, Gerald Henriksen wrote:
> On Wed, 21 Mar 2018 14:04:39 +0100, you 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.
> 
> To a certain extent though the issue isn't whether Cassandra works
> well with the given JRE but rather the issue of having a supported JRE
> in a production environment.
> 
> If Cassandra ships with a bundled JRE does that then mean the
> people/organizations downloading and using that product are going to
> expect the Cassandra project to provide bug and security updates to
> the JRE as well as Cassandra?
> 
> What happens if an organization gets hacked due to an issue in an out
> of date JRE that Cassandra bundled?  Yes, that can currently happen if
> the organization chooses to run Cassandra on an unsupported JRE.  But
> in that case the organization has made that decision, not Cassandra.
> 
> Essentially any security concious entity, whether a person or
> organization, running any software stack on top of Java (or I guess
> any of the other languages based on the JVM) is going to have to make
> a choice between constantly updating their JRE or going with a LTS
> version (either from Oracle or Red Hat or any other company that is
> willing to provide it).  Or maybe even move to .Net now that it is
> supported on Linux.
> 
> I don't think there are any great choices here for Cassandra or any of
> the other Java based projects but an easy solution (in terms of basing
> the project on a supported JRE that can be downloaded for free) would
> be to choose whatever version of OpenJDK is supported by Red Hat or
> any other Linux distribution that offers a LTS release.
> 
> So for example basing on OpenJDK 8 gets you support until October 2020
> with paying for Red Hat, or for free (with mainly security updates) by
> using Centos.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Gerald Henriksen <gh...@gmail.com>]

On Wed, 21 Mar 2018 10:52:06 -0400, you wrote:

>> Even if you are not running say Debian, or RedHat, those distributions
>> will be backporting critical fixes to their JVMs; This work is going
>> to be done, and will be available to anyone.
>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?

I am not familiar enough with the others to say definitely, but that
is the whole point of the distributions - though admittedly usually
better done for key things like kernels and compilers, less so for
random applications.  The distribution tests and releases, and then
maintains for the duration of the support of the release the software
contained in the release.

So in the case of the Red Hat / Fedora ecosystem you get:

Fedora - maintain the current version and the immediate preceding
version (usually means you get about 1 year).

Red Hat - their policy is given here* but can be up to 6 years
depending on which version of Red Hat you are on.  Those on Red Hat
will get the most benefit (being able to file bugs, etc) but even
those using the free Centos version will get the security fixes and
any other backported fixes given that Centos mirrors Red Hat EL.

So (at least for the Linux world) all that may be needed is surveying
the various distributions to find a version that has broad support for
a reasonable time period.

The problem will come for those using Windows or MacOS, where neither
Microsoft or Apple provide Java and thus those users will either have
to:

1) accept the JRE upgrade treadmill
2) adopt the Oracle JRE (and pay if necessary for it)
3) hope that some 3rd party either provides a free or cheaper than
Oracle version based off of OpenJDK

What Cassandra does in those cases will be a discussion to be had,
perhaps in a couple of months, when the available options is clearer.
In particular the big question for many organizations will be what is
the cost of Oracle support, and if they find it reasonable they may
just pay it.

I suppose there is also the possibility of whether Cassandra (or any
other Java based open source project) will continue to support Windows
or MacOS as platforms if they become to much hassle.

It may also be worth considering getting an informal group of projects
based on Java contacting the Java maintainers at various Linux/BSD
distributions and come up with a consence going forward as how to
handle the issue of what versions of Java to support and which to
skip.


* https://access.redhat.com/articles/1299013

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Gerald Henriksen <gh...@gmail.com>]

On Fri, 23 Mar 2018 15:52:51 +0000, you wrote:

>Java 8 was marked as EOL in the middle of last year, I hope we wouldn't
>require it for Cassandra 4.  At this point I feel like we should already be
>targeting Java 10 at a minimum.

Given that the last messages indicated aiming Cassandra 4 for the
3rd/4th quarter it is a bit of quandary.

Perhaps the answer is to aim for Q4 by for now building and testing on
Java 10, and then when Java 11 is released switching to that for
testing only, with the hope of getting Cassandra 4 out a couple of
months after Java 11 (assuming Java 11 is on time, but one of the
hoped for effects of a 6 month cadence is you don't run into big
changes that delay things).

With Java 11 you then get the latest LTS which Oracle and I would
assume Red Hat and other supporting for years instead of months.

Essentially, if organizations are going to go through the process of a
significant upgrade in Cassandra then let them at least at the same
time have the option of getting onto the lastest LTS Java so they can
mimize future disruptions.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Carl Mueller <ca...@smartthings.com>]

I am now thinking that aligning to the major JDK release that is for-pay
three years if you want it is the best strategy. What I think will happen
is that there will be a consortium that maintains/backports that release
level independent of oracle, if only to spite them. I'm thinking IBM, Azul,
etc will do so.

Fundamentally the project doesn't really care about the churn in the
language spec from new releases, except for breaking changes for a JDK8-ish
codebase, which should be, what, Jigsaw? What the project cares about are
security patches and JVM advancements.

JVM advancements will probably trickle into the long term non-Oracle
(assuming it appears) if it is important enough.

On Fri, Mar 23, 2018 at 11:16 AM, Jonathan Haddad <jo...@jonhaddad.com> wrote:

> I suppose given the short lifetime of each Java release you could argue
> we're always close to EOL.  I feel like we shouldn't ship with a version
> that is currently EOL.
>
> Coming up with a policy for all upcoming releases may also be incredibly
> difficult.  6 months java releases could pan out like Tick Tock and reveal
> itself to be a fun idea with some really bad consequences, and it goes away
> after Java 12.  Impossible to tell.  How about we figure out the next
> release and get a little experience under our belts with their new release
> schedule before we try to make long term decisions?
>
> On Fri, Mar 23, 2018 at 9:08 AM Josh McKenzie <jm...@apache.org>
> wrote:
>
> > > At this point I feel like we should already be
> > > targeting Java 10 at a minimum.
> > Barring some surprises from other people supporting 10 longer-term,
> > wouldn't that be coupling C*'s 4.0 release with a runtime that's
> > likely EOL shortly after?
> >
> > On Fri, Mar 23, 2018 at 11:52 AM, Jonathan Haddad <jo...@jonhaddad.com>
> > wrote:
> > > Java 8 was marked as EOL in the middle of last year, I hope we wouldn't
> > > require it for Cassandra 4.  At this point I feel like we should
> already
> > be
> > > targeting Java 10 at a minimum.
> > >
> > > Personally I'd prefer not to tie our releases to any vendor / product /
> > > package's release schedule.
> > >
> > >
> > > On Fri, Mar 23, 2018 at 6:49 AM Jason Brown <ja...@gmail.com>
> > wrote:
> > >
> > >> I'm coming to be on-board with #3.
> > >>
> > >> One thing to watch out for (we can't account for it now) is how our
> > >> dependencies choose to move forward. If we need to upgrade a jar
> (netty,
> > >> for example) due to some leak or vulnerability, and it only runs on a
> > >> higher version, we may be forced to upgrade the base java version.
> > Like, I
> > >> said we can't possibly foresee these things, and we'll just have to
> > make a
> > >> hard decision if the situation arises, but just something to keep in
> > mind.
> > >>
> > >>
> > >> On Fri, Mar 23, 2018 at 5:39 AM, Josh McKenzie <jm...@apache.org>
> > >> wrote:
> > >>
> > >> > >
> > >> > > 3) Release 4.0 for Java 8, *optionally* branch 4.1 for Java 11
> later
> > >> >
> > >> > This seems like the best of our bad options, with the addition of
> > >> > "optionally".
> > >> >
> > >> >
> > >> > On Fri, Mar 23, 2018 at 8:12 AM, Gerald Henriksen <
> ghenriks@gmail.com
> > >
> > >> > wrote:
> > >> >
> > >> > > On Fri, 23 Mar 2018 04:54:23 +0000, you wrote:
> > >> > >
> > >> > > >I think Michael is right. It would be impossible to make everyone
> > >> follow
> > >> > > >such a fast release scheme, and supporting it will be pressured
> > onto
> > >> the
> > >> > > >various distributions, M$ and Apple.
> > >> > > >On the other hand https://adoptopenjdk.net has already done a
> lot
> > of
> > >> > the
> > >> > > >work and it's already rumoured they may take up backporting of
> > >> > > security/bug
> > >> > > >fixes. I'd fully expect a lot of users to collaborate around this
> > (or
> > >> > > >similar), and there's no reason we couldn't do our part to
> > contribute.
> > >> > >
> > >> > > A posting on Reddit yesterday from someone from adoptopenjdk
> claimes
> > >> > > that they will be doing LTS releases starting with Java 11, and
> > there
> > >> > > should be updates to their website to reflect that soon:
> > >> > >
> > >> > >
> > https://www.reddit.com/r/java/comments/86ce66/java_long_term_support/
> > >> > >
> > >> > > So I guess a wait and see to what they commit could be worthwhile.
> > >> > >
> > >> > >
> > ---------------------------------------------------------------------
> > >> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > >> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >> > >
> > >> > >
> > >> >
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>

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

[Jonathan Haddad <jo...@jonhaddad.com>]

I suppose given the short lifetime of each Java release you could argue
we're always close to EOL.  I feel like we shouldn't ship with a version
that is currently EOL.

Coming up with a policy for all upcoming releases may also be incredibly
difficult.  6 months java releases could pan out like Tick Tock and reveal
itself to be a fun idea with some really bad consequences, and it goes away
after Java 12.  Impossible to tell.  How about we figure out the next
release and get a little experience under our belts with their new release
schedule before we try to make long term decisions?

On Fri, Mar 23, 2018 at 9:08 AM Josh McKenzie <jm...@apache.org> wrote:

> > At this point I feel like we should already be
> > targeting Java 10 at a minimum.
> Barring some surprises from other people supporting 10 longer-term,
> wouldn't that be coupling C*'s 4.0 release with a runtime that's
> likely EOL shortly after?
>
> On Fri, Mar 23, 2018 at 11:52 AM, Jonathan Haddad <jo...@jonhaddad.com>
> wrote:
> > Java 8 was marked as EOL in the middle of last year, I hope we wouldn't
> > require it for Cassandra 4.  At this point I feel like we should already
> be
> > targeting Java 10 at a minimum.
> >
> > Personally I'd prefer not to tie our releases to any vendor / product /
> > package's release schedule.
> >
> >
> > On Fri, Mar 23, 2018 at 6:49 AM Jason Brown <ja...@gmail.com>
> wrote:
> >
> >> I'm coming to be on-board with #3.
> >>
> >> One thing to watch out for (we can't account for it now) is how our
> >> dependencies choose to move forward. If we need to upgrade a jar (netty,
> >> for example) due to some leak or vulnerability, and it only runs on a
> >> higher version, we may be forced to upgrade the base java version.
> Like, I
> >> said we can't possibly foresee these things, and we'll just have to
> make a
> >> hard decision if the situation arises, but just something to keep in
> mind.
> >>
> >>
> >> On Fri, Mar 23, 2018 at 5:39 AM, Josh McKenzie <jm...@apache.org>
> >> wrote:
> >>
> >> > >
> >> > > 3) Release 4.0 for Java 8, *optionally* branch 4.1 for Java 11 later
> >> >
> >> > This seems like the best of our bad options, with the addition of
> >> > "optionally".
> >> >
> >> >
> >> > On Fri, Mar 23, 2018 at 8:12 AM, Gerald Henriksen <ghenriks@gmail.com
> >
> >> > wrote:
> >> >
> >> > > On Fri, 23 Mar 2018 04:54:23 +0000, you wrote:
> >> > >
> >> > > >I think Michael is right. It would be impossible to make everyone
> >> follow
> >> > > >such a fast release scheme, and supporting it will be pressured
> onto
> >> the
> >> > > >various distributions, M$ and Apple.
> >> > > >On the other hand https://adoptopenjdk.net has already done a lot
> of
> >> > the
> >> > > >work and it's already rumoured they may take up backporting of
> >> > > security/bug
> >> > > >fixes. I'd fully expect a lot of users to collaborate around this
> (or
> >> > > >similar), and there's no reason we couldn't do our part to
> contribute.
> >> > >
> >> > > A posting on Reddit yesterday from someone from adoptopenjdk claimes
> >> > > that they will be doing LTS releases starting with Java 11, and
> there
> >> > > should be updates to their website to reflect that soon:
> >> > >
> >> > >
> https://www.reddit.com/r/java/comments/86ce66/java_long_term_support/
> >> > >
> >> > > So I guess a wait and see to what they commit could be worthwhile.
> >> > >
> >> > >
> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> >> > >
> >> > >
> >> >
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>

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

[Josh McKenzie <jm...@apache.org>]

> At this point I feel like we should already be
> targeting Java 10 at a minimum.
Barring some surprises from other people supporting 10 longer-term,
wouldn't that be coupling C*'s 4.0 release with a runtime that's
likely EOL shortly after?

On Fri, Mar 23, 2018 at 11:52 AM, Jonathan Haddad <jo...@jonhaddad.com> wrote:
> Java 8 was marked as EOL in the middle of last year, I hope we wouldn't
> require it for Cassandra 4.  At this point I feel like we should already be
> targeting Java 10 at a minimum.
>
> Personally I'd prefer not to tie our releases to any vendor / product /
> package's release schedule.
>
>
> On Fri, Mar 23, 2018 at 6:49 AM Jason Brown <ja...@gmail.com> wrote:
>
>> I'm coming to be on-board with #3.
>>
>> One thing to watch out for (we can't account for it now) is how our
>> dependencies choose to move forward. If we need to upgrade a jar (netty,
>> for example) due to some leak or vulnerability, and it only runs on a
>> higher version, we may be forced to upgrade the base java version. Like, I
>> said we can't possibly foresee these things, and we'll just have to make a
>> hard decision if the situation arises, but just something to keep in mind.
>>
>>
>> On Fri, Mar 23, 2018 at 5:39 AM, Josh McKenzie <jm...@apache.org>
>> wrote:
>>
>> > >
>> > > 3) Release 4.0 for Java 8, *optionally* branch 4.1 for Java 11 later
>> >
>> > This seems like the best of our bad options, with the addition of
>> > "optionally".
>> >
>> >
>> > On Fri, Mar 23, 2018 at 8:12 AM, Gerald Henriksen <gh...@gmail.com>
>> > wrote:
>> >
>> > > On Fri, 23 Mar 2018 04:54:23 +0000, you wrote:
>> > >
>> > > >I think Michael is right. It would be impossible to make everyone
>> follow
>> > > >such a fast release scheme, and supporting it will be pressured onto
>> the
>> > > >various distributions, M$ and Apple.
>> > > >On the other hand https://adoptopenjdk.net has already done a lot of
>> > the
>> > > >work and it's already rumoured they may take up backporting of
>> > > security/bug
>> > > >fixes. I'd fully expect a lot of users to collaborate around this (or
>> > > >similar), and there's no reason we couldn't do our part to contribute.
>> > >
>> > > A posting on Reddit yesterday from someone from adoptopenjdk claimes
>> > > that they will be doing LTS releases starting with Java 11, and there
>> > > should be updates to their website to reflect that soon:
>> > >
>> > > https://www.reddit.com/r/java/comments/86ce66/java_long_term_support/
>> > >
>> > > So I guess a wait and see to what they commit could be worthwhile.
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> > > For additional commands, e-mail: dev-help@cassandra.apache.org
>> > >
>> > >
>> >
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Jonathan Haddad <jo...@jonhaddad.com>]

Java 8 was marked as EOL in the middle of last year, I hope we wouldn't
require it for Cassandra 4.  At this point I feel like we should already be
targeting Java 10 at a minimum.

Personally I'd prefer not to tie our releases to any vendor / product /
package's release schedule.


On Fri, Mar 23, 2018 at 6:49 AM Jason Brown <ja...@gmail.com> wrote:

> I'm coming to be on-board with #3.
>
> One thing to watch out for (we can't account for it now) is how our
> dependencies choose to move forward. If we need to upgrade a jar (netty,
> for example) due to some leak or vulnerability, and it only runs on a
> higher version, we may be forced to upgrade the base java version. Like, I
> said we can't possibly foresee these things, and we'll just have to make a
> hard decision if the situation arises, but just something to keep in mind.
>
>
> On Fri, Mar 23, 2018 at 5:39 AM, Josh McKenzie <jm...@apache.org>
> wrote:
>
> > >
> > > 3) Release 4.0 for Java 8, *optionally* branch 4.1 for Java 11 later
> >
> > This seems like the best of our bad options, with the addition of
> > "optionally".
> >
> >
> > On Fri, Mar 23, 2018 at 8:12 AM, Gerald Henriksen <gh...@gmail.com>
> > wrote:
> >
> > > On Fri, 23 Mar 2018 04:54:23 +0000, you wrote:
> > >
> > > >I think Michael is right. It would be impossible to make everyone
> follow
> > > >such a fast release scheme, and supporting it will be pressured onto
> the
> > > >various distributions, M$ and Apple.
> > > >On the other hand https://adoptopenjdk.net has already done a lot of
> > the
> > > >work and it's already rumoured they may take up backporting of
> > > security/bug
> > > >fixes. I'd fully expect a lot of users to collaborate around this (or
> > > >similar), and there's no reason we couldn't do our part to contribute.
> > >
> > > A posting on Reddit yesterday from someone from adoptopenjdk claimes
> > > that they will be doing LTS releases starting with Java 11, and there
> > > should be updates to their website to reflect that soon:
> > >
> > > https://www.reddit.com/r/java/comments/86ce66/java_long_term_support/
> > >
> > > So I guess a wait and see to what they commit could be worthwhile.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> > >
> >
>

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

[Jason Brown <ja...@gmail.com>]

I'm coming to be on-board with #3.

One thing to watch out for (we can't account for it now) is how our
dependencies choose to move forward. If we need to upgrade a jar (netty,
for example) due to some leak or vulnerability, and it only runs on a
higher version, we may be forced to upgrade the base java version. Like, I
said we can't possibly foresee these things, and we'll just have to make a
hard decision if the situation arises, but just something to keep in mind.


On Fri, Mar 23, 2018 at 5:39 AM, Josh McKenzie <jm...@apache.org> wrote:

> >
> > 3) Release 4.0 for Java 8, *optionally* branch 4.1 for Java 11 later
>
> This seems like the best of our bad options, with the addition of
> "optionally".
>
>
> On Fri, Mar 23, 2018 at 8:12 AM, Gerald Henriksen <gh...@gmail.com>
> wrote:
>
> > On Fri, 23 Mar 2018 04:54:23 +0000, you wrote:
> >
> > >I think Michael is right. It would be impossible to make everyone follow
> > >such a fast release scheme, and supporting it will be pressured onto the
> > >various distributions, M$ and Apple.
> > >On the other hand https://adoptopenjdk.net has already done a lot of
> the
> > >work and it's already rumoured they may take up backporting of
> > security/bug
> > >fixes. I'd fully expect a lot of users to collaborate around this (or
> > >similar), and there's no reason we couldn't do our part to contribute.
> >
> > A posting on Reddit yesterday from someone from adoptopenjdk claimes
> > that they will be doing LTS releases starting with Java 11, and there
> > should be updates to their website to reflect that soon:
> >
> > https://www.reddit.com/r/java/comments/86ce66/java_long_term_support/
> >
> > So I guess a wait and see to what they commit could be worthwhile.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>

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

[Josh McKenzie <jm...@apache.org>]

>
> 3) Release 4.0 for Java 8, *optionally* branch 4.1 for Java 11 later

This seems like the best of our bad options, with the addition of
"optionally".


On Fri, Mar 23, 2018 at 8:12 AM, Gerald Henriksen <gh...@gmail.com>
wrote:

> On Fri, 23 Mar 2018 04:54:23 +0000, you wrote:
>
> >I think Michael is right. It would be impossible to make everyone follow
> >such a fast release scheme, and supporting it will be pressured onto the
> >various distributions, M$ and Apple.
> >On the other hand https://adoptopenjdk.net has already done a lot of the
> >work and it's already rumoured they may take up backporting of
> security/bug
> >fixes. I'd fully expect a lot of users to collaborate around this (or
> >similar), and there's no reason we couldn't do our part to contribute.
>
> A posting on Reddit yesterday from someone from adoptopenjdk claimes
> that they will be doing LTS releases starting with Java 11, and there
> should be updates to their website to reflect that soon:
>
> https://www.reddit.com/r/java/comments/86ce66/java_long_term_support/
>
> So I guess a wait and see to what they commit could be worthwhile.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>

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

[Gerald Henriksen <gh...@gmail.com>]

On Fri, 23 Mar 2018 04:54:23 +0000, you wrote:

>I think Michael is right. It would be impossible to make everyone follow
>such a fast release scheme, and supporting it will be pressured onto the
>various distributions, M$ and Apple.
>On the other hand https://adoptopenjdk.net has already done a lot of the
>work and it's already rumoured they may take up backporting of security/bug
>fixes. I'd fully expect a lot of users to collaborate around this (or
>similar), and there's no reason we couldn't do our part to contribute.

A posting on Reddit yesterday from someone from adoptopenjdk claimes
that they will be doing LTS releases starting with Java 11, and there
should be updates to their website to reflect that soon:

https://www.reddit.com/r/java/comments/86ce66/java_long_term_support/

So I guess a wait and see to what they commit could be worthwhile.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[kurt greaves <ku...@instaclustr.com>]

I think Michael is right. It would be impossible to make everyone follow
such a fast release scheme, and supporting it will be pressured onto the
various distributions, M$ and Apple.
On the other hand https://adoptopenjdk.net has already done a lot of the
work and it's already rumoured they may take up backporting of security/bug
fixes. I'd fully expect a lot of users to collaborate around this (or
similar), and there's no reason we couldn't do our part to contribute.

On Fri., 23 Mar. 2018, 09:37 Gerald Henriksen, <gh...@gmail.com> wrote:

> On Thu, 22 Mar 2018 16:04:16 -0500, you wrote:
>
> >Is OpenJDK really not addressing this at all? Is that because OpenJDK is
> >beholden to Oracle somehow?
>
> I suspect it is more a case of OpenJDK (as in the entitites other than
> Oracle that are members) haven't historically been involved in the
> providing of JRE/JDK to the public.  Oracle (previously Sun) handled
> that entirely and so there is no group outside of Oracle prepared (at
> least at this point in time) to do anything.
>
> >There is no looming deadline on this, is there?
>
> Less than a year.  Java 8 is currently scheduled to get dropped (as in
> no more updates) in January 2019 (the actual plan is 4 months after
> Java 11, so if 11 is late then that date will get changed).
>
> > Can we just let the dust
> >settle on this in the overall ecosystem to see what happens?
>
> Not a lot of time to organize an alternative if too much time is spent
> seeing if someone else does anything.
>
> I don't see Apple picking up supporting Java again on MacOS, I suppose
> Microsoft might be convinced to pick up Java for Windows if they felt
> it helped either Windows or Azure (on the other hand though this might
> convince a lot of organizations to move to the now multi-platform
> .Net).
>
> The question really becomes who sees it in their interest to come up
> with the money to support (either through OpenJDK or an outside group)
> the process of building and maintaining a free set of Java binaries.
>
> Unless someone steps up then the best anyone can do (at least in terms
> of no-cost use of Java) is to work around where we know there will be
> long term Java support, that being the Linux/BSD versions that provide
> long term support through the distribution.
>
> If that is the case, then it might be worth someone creating an
> informal group to discuss between the distributions and the software
> projects that rely on Java what version of Java to support.  If for
> example Red Hat, Ubuntu, Debian, FreeBSD, etc. can't come to an
> informal agreement to all support the same version of Java we could in
> 5 years end up with Red Hat supporting X, Ubuntu X+1, Debian X-1, etc.
> with the result that the software have to try and pick and choose.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>

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

[Gerald Henriksen <gh...@gmail.com>]

On Thu, 22 Mar 2018 16:04:16 -0500, you wrote:

>Is OpenJDK really not addressing this at all? Is that because OpenJDK is
>beholden to Oracle somehow?

I suspect it is more a case of OpenJDK (as in the entitites other than
Oracle that are members) haven't historically been involved in the
providing of JRE/JDK to the public.  Oracle (previously Sun) handled
that entirely and so there is no group outside of Oracle prepared (at
least at this point in time) to do anything.

>There is no looming deadline on this, is there?

Less than a year.  Java 8 is currently scheduled to get dropped (as in
no more updates) in January 2019 (the actual plan is 4 months after
Java 11, so if 11 is late then that date will get changed).

> Can we just let the dust
>settle on this in the overall ecosystem to see what happens?

Not a lot of time to organize an alternative if too much time is spent
seeing if someone else does anything.

I don't see Apple picking up supporting Java again on MacOS, I suppose
Microsoft might be convinced to pick up Java for Windows if they felt
it helped either Windows or Azure (on the other hand though this might
convince a lot of organizations to move to the now multi-platform
.Net).

The question really becomes who sees it in their interest to come up
with the money to support (either through OpenJDK or an outside group)
the process of building and maintaining a free set of Java binaries.

Unless someone steps up then the best anyone can do (at least in terms
of no-cost use of Java) is to work around where we know there will be
long term Java support, that being the Linux/BSD versions that provide
long term support through the distribution.

If that is the case, then it might be worth someone creating an
informal group to discuss between the distributions and the software
projects that rely on Java what version of Java to support.  If for
example Red Hat, Ubuntu, Debian, FreeBSD, etc. can't come to an
informal agreement to all support the same version of Java we could in
5 years end up with Red Hat supporting X, Ubuntu X+1, Debian X-1, etc.
with the result that the software have to try and pick and choose.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Stefan Podkowinski <sp...@apache.org>]

The idea was not about building a custom JDK and ship it along with
Cassandra, rather than using the new modular run-time images feature [0]
introduced in Java 9. See also the link posted by Jason [1] for an
practical introduction.

[0] http://openjdk.java.net/jeps/220
[1]
https://steveperkins.com/using-java-9-modularization-to-ship-zero-dependency-native-apps/


On 21.03.18 17:26, Michael Burman 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@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[kurt greaves <ku...@instaclustr.com>]

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, <ca...@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.mueller@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 <ja...@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 <jasedbrown@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 <jasedbrown@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 <
> >>>>>>>> miburman@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-unsubscribe@cassandra.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>
> >>> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>
> >>
> > --
> > Robert Stupp
> > @snazy
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>

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

[Carl Mueller <ca...@smartthings.com>]

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.mueller@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 <ja...@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 <ja...@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 <ja...@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 <
>>>>>>>> miburman@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-unsubscribe@cassandra.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>
>>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>>
> --
> Robert Stupp
> @snazy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>

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

[Robert Stupp <sn...@gmx.de>]

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 <ca...@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 <ja...@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 <ja...@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 <ja...@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 <mi...@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-unsubscribe@cassandra.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>
>>>>>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>

-- 
Robert Stupp
@snazy


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Stefan Podkowinski <sp...@apache.org>]

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 <ca...@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 <ja...@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 <ja...@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 <ja...@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 <mi...@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-unsubscribe@cassandra.apache.org
>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Michael Shuler <mi...@pbandjelly.org>]

On 03/22/2018 05:30 PM, Michael Shuler wrote:

> Ubuntu 16.04 (Bionic (near release))

Ubuntu 18.04 (Bionic) :)

Michael

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Michael Shuler <mi...@pbandjelly.org>]

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 <ca...@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 <ja...@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 <ja...@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 <ja...@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 <mi...@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-unsubscribe@cassandra.apache.org
>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Jason Brown <ja...@gmail.com>]

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 <ca...@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 <ja...@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 <ja...@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 <ja...@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 <mi...@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-unsubscribe@cassandra.apache.org
> > >>> For additional commands, e-mail: dev-help@cassandra.apache.org
> > >>>
> > >>>
> > >>
> > >
> >
>

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

[Carl Mueller <ca...@smartthings.com>]

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 <ja...@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 <ja...@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 <ja...@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 <mi...@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-unsubscribe@cassandra.apache.org
> >>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>
> >>>
> >>
> >
>

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

[Jason Brown <ja...@gmail.com>]

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 <ja...@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 <ja...@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 <mi...@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-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>
>>>
>>
>

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

[Jason Brown <ja...@gmail.com>]

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 <ja...@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 <mi...@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-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>>
>

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

[Jason Brown <ja...@gmail.com>]

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 <mi...@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-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>

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

[Michael Burman <mi...@redhat.com>]

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@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Josh McKenzie <jm...@apache.org>]

> Even if you are not running say Debian, or RedHat, those distributions
> will be backporting critical fixes to their JVMs; This work is going
> to be done, and will be available to anyone.
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?

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.

The whole license restriction aspect of it, however, obviously is (and
makes complete sense).

On Wed, Mar 21, 2018 at 10:41 AM, Eric Evans <jo...@gmail.com> wrote:
> On Wed, Mar 21, 2018 at 9:21 AM, Gerald Henriksen <gh...@gmail.com> wrote:
>> On Wed, 21 Mar 2018 14:04:39 +0100, you 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.
>>
>> To a certain extent though the issue isn't whether Cassandra works
>> well with the given JRE but rather the issue of having a supported JRE
>> in a production environment.
>>
>> If Cassandra ships with a bundled JRE does that then mean the
>> people/organizations downloading and using that product are going to
>> expect the Cassandra project to provide bug and security updates to
>> the JRE as well as Cassandra?
>>
>> What happens if an organization gets hacked due to an issue in an out
>> of date JRE that Cassandra bundled?  Yes, that can currently happen if
>> the organization chooses to run Cassandra on an unsupported JRE.  But
>> in that case the organization has made that decision, not Cassandra.
>
> Exactly.  It is common for organizations to evaluate JVM errata
> against their environment/requirements and the use-cases they have,
> then act accordingly.  If applications start embedding their own JVM
> this becomes a combinatorial nightmare.
>
>> Essentially any security concious entity, whether a person or
>> organization, running any software stack on top of Java (or I guess
>> any of the other languages based on the JVM) is going to have to make
>> a choice between constantly updating their JRE or going with a LTS
>> version (either from Oracle or Red Hat or any other company that is
>> willing to provide it).  Or maybe even move to .Net now that it is
>> supported on Linux.
>>
>> I don't think there are any great choices here for Cassandra or any of
>> the other Java based projects but an easy solution (in terms of basing
>> the project on a supported JRE that can be downloaded for free) would
>> be to choose whatever version of OpenJDK is supported by Red Hat or
>> any other Linux distribution that offers a LTS release.
>>
>> So for example basing on OpenJDK 8 gets you support until October 2020
>> with paying for Red Hat, or for free (with mainly security updates) by
>> using Centos.
>
> Agreed.  Someone said this elsewhere as well, that the community will
> work this out.
>
> Even if you are not running say Debian, or RedHat, those distributions
> will be backporting critical fixes to their JVMs; This work is going
> to be done, and will be available to anyone.  If this becomes an
> issue, it'll be an issue facing a lot of people, and I expect
> unofficial LTS releases will quickly become available.
>
> --
> Eric Evans
> john.eric.evans@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Eric Evans <jo...@gmail.com>]

On Wed, Mar 21, 2018 at 9:21 AM, Gerald Henriksen <gh...@gmail.com> wrote:
> On Wed, 21 Mar 2018 14:04:39 +0100, you 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.
>
> To a certain extent though the issue isn't whether Cassandra works
> well with the given JRE but rather the issue of having a supported JRE
> in a production environment.
>
> If Cassandra ships with a bundled JRE does that then mean the
> people/organizations downloading and using that product are going to
> expect the Cassandra project to provide bug and security updates to
> the JRE as well as Cassandra?
>
> What happens if an organization gets hacked due to an issue in an out
> of date JRE that Cassandra bundled?  Yes, that can currently happen if
> the organization chooses to run Cassandra on an unsupported JRE.  But
> in that case the organization has made that decision, not Cassandra.

Exactly.  It is common for organizations to evaluate JVM errata
against their environment/requirements and the use-cases they have,
then act accordingly.  If applications start embedding their own JVM
this becomes a combinatorial nightmare.

> Essentially any security concious entity, whether a person or
> organization, running any software stack on top of Java (or I guess
> any of the other languages based on the JVM) is going to have to make
> a choice between constantly updating their JRE or going with a LTS
> version (either from Oracle or Red Hat or any other company that is
> willing to provide it).  Or maybe even move to .Net now that it is
> supported on Linux.
>
> I don't think there are any great choices here for Cassandra or any of
> the other Java based projects but an easy solution (in terms of basing
> the project on a supported JRE that can be downloaded for free) would
> be to choose whatever version of OpenJDK is supported by Red Hat or
> any other Linux distribution that offers a LTS release.
>
> So for example basing on OpenJDK 8 gets you support until October 2020
> with paying for Red Hat, or for free (with mainly security updates) by
> using Centos.

Agreed.  Someone said this elsewhere as well, that the community will
work this out.

Even if you are not running say Debian, or RedHat, those distributions
will be backporting critical fixes to their JVMs; This work is going
to be done, and will be available to anyone.  If this becomes an
issue, it'll be an issue facing a lot of people, and I expect
unofficial LTS releases will quickly become available.

-- 
Eric Evans
john.eric.evans@gmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Jeff Jirsa <jj...@gmail.com>]

> On Mar 21, 2018, at 7:21 AM, Gerald Henriksen <gh...@gmail.com> wrote:
> 
>> On Wed, 21 Mar 2018 14:04:39 +0100, you wrote:
>> 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.
> 
> To a certain extent though the issue isn't whether Cassandra works
> well with the given JRE but rather the issue of having a supported JRE
> in a production environment.
> 

This, plus the license issue, probably makes this a non-option.

(The license question is closed for the record:

https://www.apache.org/licenses/GPL-compatibility.html - The Apache Software Foundation does not allow its own projects to distribute software under licenses more restrictive than the Apache License)

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

[Gerald Henriksen <gh...@gmail.com>]

On Wed, 21 Mar 2018 14:04:39 +0100, you 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.

To a certain extent though the issue isn't whether Cassandra works
well with the given JRE but rather the issue of having a supported JRE
in a production environment.

If Cassandra ships with a bundled JRE does that then mean the
people/organizations downloading and using that product are going to
expect the Cassandra project to provide bug and security updates to
the JRE as well as Cassandra?

What happens if an organization gets hacked due to an issue in an out
of date JRE that Cassandra bundled?  Yes, that can currently happen if
the organization chooses to run Cassandra on an unsupported JRE.  But
in that case the organization has made that decision, not Cassandra.

Essentially any security concious entity, whether a person or
organization, running any software stack on top of Java (or I guess
any of the other languages based on the JVM) is going to have to make
a choice between constantly updating their JRE or going with a LTS
version (either from Oracle or Red Hat or any other company that is
willing to provide it).  Or maybe even move to .Net now that it is
supported on Linux.

I don't think there are any great choices here for Cassandra or any of
the other Java based projects but an easy solution (in terms of basing
the project on a supported JRE that can be downloaded for free) would
be to choose whatever version of OpenJDK is supported by Red Hat or
any other Linux distribution that offers a LTS release.

So for example basing on OpenJDK 8 gets you support until October 2020
with paying for Red Hat, or for free (with mainly security updates) by
using Centos.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

["J. D. Jordan" <je...@gmail.com>]

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 <ee...@wikimedia.org> wrote:
> 
>> On Wed, Mar 21, 2018 at 8:04 AM, Stefan Podkowinski <sp...@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 <ja...@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 <ka...@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 <ja...@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 <
>>>>>> jmckenzie@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 <
>>>>>> jasedbrown@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-unsubscribe@cassandra.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>> ------------------------------------------------------------
>> ---------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>> 
>>>>>>> 
>>>>>>> ------------------------------------------------------------
>> ---------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>> 
>> 
> 
> 
> -- 
> Eric Evans
> eevans@wikimedia.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Eric Evans <jo...@gmail.com>]

On Wed, Mar 21, 2018 at 9:00 AM, Josh McKenzie <jm...@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 <ee...@wikimedia.org> wrote:
>> On Wed, Mar 21, 2018 at 8:04 AM, Stefan Podkowinski <sp...@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 <ja...@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 <ka...@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 <ja...@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 <
>>> >>>> jmckenzie@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 <
>>> >>>> jasedbrown@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-unsubscribe@cassandra.apache.org
>>> >>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>
>>> >>>>>> ------------------------------------------------------------
>>> ---------
>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>> >>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>> >>>>>>
>>> >>>>>
>>> >>>>> ------------------------------------------------------------
>>> ---------
>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>> >>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>> >>>>>
>>> >>>>>
>>> >>>>
>>> >>>
>>> >>>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>> > For additional commands, e-mail: dev-help@cassandra.apache.org
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>
>>>
>>
>>
>> --
>> Eric Evans
>> eevans@wikimedia.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>



-- 
Eric Evans
john.eric.evans@gmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Josh McKenzie <jm...@apache.org>]

> 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.

On Wed, Mar 21, 2018 at 9:49 AM, Eric Evans <ee...@wikimedia.org> wrote:
> On Wed, Mar 21, 2018 at 8:04 AM, Stefan Podkowinski <sp...@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 <ja...@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 <ka...@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 <ja...@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 <
>> >>>> jmckenzie@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 <
>> >>>> jasedbrown@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-unsubscribe@cassandra.apache.org
>> >>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>
>> >>>>>> ------------------------------------------------------------
>> ---------
>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> >>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>> >>>>>>
>> >>>>>
>> >>>>> ------------------------------------------------------------
>> ---------
>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> >>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>> >>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> > For additional commands, e-mail: dev-help@cassandra.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>>
>
>
> --
> Eric Evans
> eevans@wikimedia.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Eric Evans <ee...@wikimedia.org>]

On Wed, Mar 21, 2018 at 8:04 AM, Stefan Podkowinski <sp...@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 <ja...@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 <ka...@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 <ja...@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 <
> >>>> jmckenzie@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 <
> >>>> jasedbrown@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-unsubscribe@cassandra.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>> ------------------------------------------------------------
> ---------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>
> >>>>>
> >>>>> ------------------------------------------------------------
> ---------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>


-- 
Eric Evans
eevans@wikimedia.org

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

[Jason Brown <ja...@gmail.com>]

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 <jm...@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 <sp...@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 <ja...@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 <ka...@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 <ja...@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 <
> >>>>> jmckenzie@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 <
> >>>>> jasedbrown@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-unsubscribe@cassandra.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>> ------------------------------------------------------------
> ---------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>>
> >>>>>>
> >>>>>> ------------------------------------------------------------
> ---------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>

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

[Josh McKenzie <jm...@apache.org>]

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 <sp...@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 <ja...@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 <ka...@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 <ja...@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 <
>>>>> jmckenzie@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 <
>>>>> jasedbrown@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-unsubscribe@cassandra.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Stefan Podkowinski <sp...@apache.org>]

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 <ja...@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 <ka...@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 <ja...@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 <
>>>> jmckenzie@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 <
>>>> jasedbrown@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-unsubscribe@cassandra.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>
>>>>>
>>>>
>>>
>>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Ariel Weisberg <ar...@weisberg.ws>]

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 <ja...@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 <ka...@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 <ja...@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 <
> >> jmckenzie@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 <
> >> jasedbrown@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-unsubscribe@cassandra.apache.org
> >> > > >> For additional commands, e-mail: dev-help@cassandra.apache.org
> >> > > >>
> >> > > >>
> >> > >
> >> > > ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> >> > >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >> >
> >> >
> >>
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Carl Mueller <ca...@smartthings.com>]

So this is basically Oracle imposing a rapid upgrade path on free users to
force them to buy commercial to get LTS stability?

This will probably shake out in the community somehow. Cassandra is complex
but we are small fry in the land of IT supports and Enterprise upgrades.
Something will organize around OpenJDK I'd guess. There's probably a
collective tens or hundreds of billions of dollars in IT budgets affected
by this, so something will shake out.

So many other projects are impacted by this. What is the official/consensus
Apache Software Foundation strategy on this?

On Tue, Mar 20, 2018 at 3:50 PM, Jason Brown <ja...@gmail.com> 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 <ja...@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 <ka...@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 <ja...@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 <
> >> jmckenzie@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 <
> >> jasedbrown@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-unsubscribe@cassandra.apache.org
> >> > > >> For additional commands, e-mail: dev-help@cassandra.apache.org
> >> > > >>
> >> > > >>
> >> > >
> >> > > ------------------------------------------------------------
> ---------
> >> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> >> > >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >> >
> >> >
> >>
> >
> >
>

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

[Jeremiah D Jordan <je...@gmail.com>]

> 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.

Yes, this is basically what I was proposing for trunk.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Jason Brown <ja...@gmail.com>]

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 <ja...@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 <ka...@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 <ja...@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 <
>> jmckenzie@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 <
>> jasedbrown@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-unsubscribe@cassandra.apache.org
>> > > >> For additional commands, e-mail: dev-help@cassandra.apache.org
>> > > >>
>> > > >>
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> > > For additional commands, e-mail: dev-help@cassandra.apache.org
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> > For additional commands, e-mail: dev-help@cassandra.apache.org
>> >
>> >
>>
>
>

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

[Jason Brown <ja...@gmail.com>]

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 <ka...@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 <ja...@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 <
> jmckenzie@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 <jasedbrown@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-unsubscribe@cassandra.apache.org
> > > >> For additional commands, e-mail: dev-help@cassandra.apache.org
> > > >>
> > > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>

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

[Kant Kodali <ka...@peernova.com>]

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 <ja...@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 <jm...@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 <ja...@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-unsubscribe@cassandra.apache.org
> > >> For additional commands, e-mail: dev-help@cassandra.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>

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

[Ariel Weisberg <ar...@weisberg.ws>]

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 <ja...@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 <jm...@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 <ja...@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-unsubscribe@cassandra.apache.org
> >> For additional commands, e-mail: dev-help@cassandra.apache.org
> >> 
> >> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Jeremiah Jordan <je...@datastax.com>]

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 <ja...@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 <jm...@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 <ja...@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-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>> 
>> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Jason Brown <ja...@gmail.com>]

>> 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 <jm...@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 <ja...@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-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>

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

[Hannu Kröger <hk...@gmail.com>]

When reading about the LTS and JDK being non-free, OracleJDK requirement/recommendation seems like a sub-optimal idea:
https://medium.com/codefx-weekly/no-free-java-lts-version-b850192745fb

Hannu

> On 20 Mar 2018, at 16:56, Robert Stupp <sn...@gmx.de> wrote:
> 
> Don't forget that you have to spend bucks to get LTS.
> 
> My hope is that after that Java 9, upcoming releases should be smoother to use. I.e. settling the C* release on the Java release that's current at that point in time sounds good enough. I.e. my hope is that any C* release made for Java X will work with Java X+n (in the foreseeable future). Caveat is probably the use of "Unsafe"...
> 
> For example, if a major release would be planned for April, supporting Java 10 should be good enough. But that C* major release should stay on Java 10 and no code that requires a newer Java version must get in.
> 
> I'm not sure whether recommending OracleJDK over OpenJDK is required. You get some goodies with OracleJDK (CAs for example), sure.
> 
> On 03/20/2018 03:22 PM, Josh McKenzie 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 <ja...@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-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>> 
> 
> -- 
> Robert Stupp
> @snazy
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Jason Brown <ja...@gmail.com>]

>> Don't forget that you have to spend bucks to get LTS.

Huh? Is that true? Can you point me to any docs that I may have missed?
That would be an important point to consider.

>> supporting Java 10 should be good enough.

Sure but what about 2 years after we release a major, on a JDK that is 2-4
versions outdated? Are we going to get requests to keep
upgrading/validating all 'live' versions under the JDK flavor of the month?
That's what I'd like to avoid, if it's at all possible.

On Tue, Mar 20, 2018 at 7:56 AM, Robert Stupp <sn...@gmx.de> wrote:

> Don't forget that you have to spend bucks to get LTS.
>
> My hope is that after that Java 9, upcoming releases should be smoother to
> use. I.e. settling the C* release on the Java release that's current at
> that point in time sounds good enough. I.e. my hope is that any C* release
> made for Java X will work with Java X+n (in the foreseeable future). Caveat
> is probably the use of "Unsafe"...
>
> For example, if a major release would be planned for April, supporting
> Java 10 should be good enough. But that C* major release should stay on
> Java 10 and no code that requires a newer Java version must get in.
>
> I'm not sure whether recommending OracleJDK over OpenJDK is required. You
> get some goodies with OracleJDK (CAs for example), sure.
>
>
> On 03/20/2018 03:22 PM, Josh McKenzie 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 <ja...@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-easi
>>> er-use-and-redistribution-of-java-se
>>> [3]
>>> https://www.oracle.com/java/java9-screencasts.html?bcid=5582
>>> 439790001&playerType=single-social&size=events
>>> [4]
>>> http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live.ht
>>> ml?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-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>>
> --
> Robert Stupp
> @snazy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>

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

[Robert Stupp <sn...@gmx.de>]

Don't forget that you have to spend bucks to get LTS.

My hope is that after that Java 9, upcoming releases should be smoother 
to use. I.e. settling the C* release on the Java release that's current 
at that point in time sounds good enough. I.e. my hope is that any C* 
release made for Java X will work with Java X+n (in the foreseeable 
future). Caveat is probably the use of "Unsafe"...

For example, if a major release would be planned for April, supporting 
Java 10 should be good enough. But that C* major release should stay on 
Java 10 and no code that requires a newer Java version must get in.

I'm not sure whether recommending OracleJDK over OpenJDK is required. 
You get some goodies with OracleJDK (CAs for example), sure.

On 03/20/2018 03:22 PM, Josh McKenzie 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 <ja...@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-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>

-- 
Robert Stupp
@snazy


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

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

[Josh McKenzie <jm...@apache.org>]

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 <ja...@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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org