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,
wrote:
> And here we go!
>
> from here:
> https://www.reddit.com/r/java/comments/86ce66/java_long_term_support/
>
>
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
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
On Fri, 23 Mar 2018 15:52:51 +, 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
3
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
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 Tic
> 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 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,
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
>
> 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
wrote:
> On Fri, 23 Mar 2018 04:54:23 +, you wrote:
>
> >I think Michael is right. It w
On Fri, 23 Mar 2018 04:54:23 +, 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 lo
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
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 tak
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
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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cass
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 de
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
wrote:
> Is OpenJDK
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 s
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 wrote:
> ftr, I've sent a message to legal-discuss to inquire about the licensing
> aspect of the OpenJDK as we've been disc
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
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 w
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/
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 pu
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
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
disc
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 v
> 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 publ
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
On Wed, Mar 21, 2018 at 9: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 JR
> On Mar 21, 2018, at 7:21 AM, Gerald Henriksen 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 versi
On Wed, Mar 21, 2018 at 9:00 AM, Josh McKenzie 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 o
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
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.
-Jer
> 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 p
On Wed, Mar 21, 2018 at 8:04 AM, Stefan Podkowinski 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 deliv
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
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 wrote:
> There's also another option, which I just want to mention here for the
> sake of d
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 whil
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 supp
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 alt
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
> 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 versio
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
copied directly from dev channel, just to keep with this ML conversation
08:08:26 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: "Th
Java 10 is releasing today!
On Tue, Mar 20, 2018 at 9:07 AM, Ariel Weisberg 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 a
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
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, wi
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 wrote:
>
> Don't forget that you have to spend bucks to g
>> 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
v
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 wi
>> 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
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
fo
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 superce
53 matches
Mail list logo
