cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Angus <>
Subject Re: [DISCUSS] Move to jdk11 and use jlink
Date Thu, 21 Mar 2019 08:38:18 GMT
It sounds like a good idea to get ahead of the curve..
We probably need a 'plan' which we can all get behind and ready the users for.  especially
if it is going to mean dropping some OS support.

one question, if we 'bundle java' and a Java vulnerability is found are we likely to have
to release a CloudStack update, rather than advise users to upgrade their JRE?
From: Marc-Aurèle Brothier <>
Sent: 20 March 2019 17:31
Subject: Re: [DISCUSS] Move to jdk11 and use jlink

Hi Rohit,

I think it’s a good move. After some recent testing I found some incompatibility between
the jdk11 and older version of spring. I don’t have at hands the links but you have to upgrade
to some specific version to make it work.

Amadeus House, Floral Street, London  WC2E 9DPUK

> On 20 Mar 2019, at 05:59, Rohit Yadav <> wrote:
> All,
> JDK8 has reached eol wrt public updates from Oracle and JDK11 is the most recent LTS.
Should we discuss and plan the next release to move to JDK11, the effort may be as minimal
as changing the jdk requirements in maven config files.
> Wrt consumption on centos6 (was there was an argument to drop centos6 support?) , centos7
and ubuntu 16.04+ with project jigsaw and jdk11's jlink we can ship stripped down jre along
with CloudStack artifacts. This would mean we may no longer depend on distribution provided
JRE, much like shipping a single uberjar we can bundle stripped jre in it as well, including
for usage, kvm agent and systemvm agents. This can be beneficial in project's control wrt
security and CloudStack can still run on platforms that don't have openjdk11 packages. The
effort here I guess would be to create build assemblies or use a maven plugin to export such
a bundle. Thoughts?
> Regards,
> Rohit Yadav
> Amadeus House, Floral Street, London  WC2E 9DPUK
> @shapeblue

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message