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/using-java-9-modularization-to-ship-zero-dependency-native-apps/ On 21.03.18 17:26, Michael Burman 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
