RFR: 8221610: Resurrect (legacy) JRE bundle target
erik.joelsson at oracle.com
Fri Mar 29 15:45:38 UTC 2019
On 2019-03-29 04:30, Langer, Christoph wrote:
> Hi Erik, Arno,
> thanks for reviewing and spotting the $(JDK_BUNDLE_EXTENSION) macro. I
> simply forgot it because I was copying the original code as it was pre
> JDK-8200132. At that time, there was no $(JDK_BUNDLE_EXTENSION) macro yet.
> I already verified that using $(JDK_BUNDLE_EXTENSION) will correctly
> produce a zip bundle on Windows.
> I’ll test whether standard images will still get build (without
> legacy) as requested by Erik before pushing.
> This is the updated webrev:
> *From:*Erik Joelsson <erik.joelsson at oracle.com>
> *Sent:* Donnerstag, 28. März 2019 15:54
> *To:* Zeller, Arno <arno.zeller at sap.com>; Langer, Christoph
> <christoph.langer at sap.com>; build-dev at openjdk.java.net
> *Cc:* Schuenemann, Rene <rene.schuenemann at sap.com>
> *Subject:* Re: RFR: 8221610: Resurrect (legacy) JRE bundle target
> On 2019-03-28 04:47, Zeller, Arno wrote:
> Hi Christoph,
> thanks for the patch. Just one small suggestion – I think you
> could use the same extension for jdk archive also for the jre
> archive in make/autoconf/spec.gmk.in?
> Something like this:
> JRE_BUNDLE_NAME := jre-$(BASE_NAME)_bin$(DEBUG_PART).
> I think this makes sense.
> Otherwise this looks ok to me. Have you verified that it still works
> when not building any legacy-images and no legacy-image is present in
> the build dir?
> Otherwise you will have a difference between jdk and jre archives
> on windows and zip might be more common on windows. I think to get
> a real zip in the end you might need more changes.
> This is actually the only change needed. The makefile will figure out
> the tool to use based on the extension.
> Best regards,
> *From:*Langer, Christoph
> *Sent:* Donnerstag, 28. März 2019 10:07
> *To:* build-dev at openjdk.java.net
> <mailto:build-dev at openjdk.java.net>; Erik Joelsson
> <erik.joelsson at oracle.com> <mailto:erik.joelsson at oracle.com>
> *Cc:* Zeller, Arno <arno.zeller at sap.com>
> <mailto:arno.zeller at sap.com>; Schuenemann, Rene
> <rene.schuenemann at sap.com> <mailto:rene.schuenemann at sap.com>
> *Subject:* RFR: 8221610: Resurrect (legacy) JRE bundle target
> Hi build-dev,
> today I’m coming up with kind of a backward oriented suggestion…
> don’t know how well that would be received. Let’s see.
> For JDK 11, with JDK-8200132 , the JRE build has been moved to
> There has been some discussion beforehand whether the JRE build
> can completely be dropped or how far one can go removing the
> support for it . In the end the decision was made to at least
> remove the JRE from the main targets and only offer some “legacy”
> targets that would still build the JRE. Unfortunately, you were
> under the assumption that nobody except Oracle would use the
> bundle target and removed it as well . Unfortunately, this
> assumption was not quite true (and I was not there to raise my
> concern ☹). In SapMachine builds, we use the bundle targets and we
> are also still building JRE images for several stakeholders. So it
> would really be good if we could get the JRE bundle target back.
> At the moment we mimick the bundling in a shell script that is run
> after the build.
> I'm happy to hear that this got use outside of Oracle!
> So, I suggest to add back the BUILD_JRE_BUNDLE target in
> Bundles.gmk and add an additional main target called
> legacy-bundles which can be called for creating the JRE bundle.
> Of course, this can go eventually when JRE support is finally
> dropped for OpenJDK.
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8221610.0/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8221610
>  https://bugs.openjdk.java.net/browse/JDK-8200132
More information about the build-dev