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