RFR: 8221610: Resurrect (legacy) JRE bundle target

[Langer, Christoph]

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: http://cr.openjdk.java.net/~clanger/webrevs/8221610.1/

Thanks
Christoph


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


Hello,
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). $(JDK_BUNDLE_EXTENSION)


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

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 [0], the JRE build has been moved to legacy.
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 [1]. 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 [2]. 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!

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

Thanks
Christoph

[0] https://bugs.openjdk.java.net/browse/JDK-8200132
[1] https://mail.openjdk.java.net/pipermail/build-dev/2018-June/022249.html
[2] https://mail.openjdk.java.net/pipermail/build-dev/2018-June/022274.html