On Wed, Mar 21, 2018 at 9:21 AM, Gerald Henriksen <ghenr...@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.ev...@gmail.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
