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