> 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 <john.eric.ev...@gmail.com> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
