From shade at redhat.com Mon Mar 23 19:22:34 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 23 Mar 2020 20:22:34 +0100 Subject: RFR (XS) 8241462: StripNativeDebugSymbols jlink plugin allocates huge arrays Message-ID: <65d59ecc-e999-e66a-4a03-27ec990f6ca5@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8241462 In some of my testing pipelines that deal with huge .so-s due to specific build configuration, tests that use the StripNativeDebugSymbols plugin fail with OOME. It can be fixed by using the method that copies the InputStream straight to destination file without instantiating the huge array. The only wrinkle is that we need to close the InputStream after we are done. diff -r c456587e7ef4 src/jdk.jlink/linux/classes/jdk/tools/jlink/internal/plugins/StripNativeDebugSymbolsPlugin.java --- a/src/jdk.jlink/linux/classes/jdk/tools/jlink/internal/plugins/StripNativeDebugSymbolsPlugin.java Mon Mar 23 19:14:01 2020 +0100 +++ b/src/jdk.jlink/linux/classes/jdk/tools/jlink/internal/plugins/StripNativeDebugSymbolsPlugin.java Mon Mar 23 20:13:15 2020 +0100 @@ -1,4 +1,4 @@ /* - * Copyright (c) 2019, Red Hat, Inc. + * Copyright (c) 2019, 2020, Red Hat, Inc. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * @@ -25,4 +25,5 @@ package jdk.tools.jlink.internal.plugins; +import java.io.InputStream; import java.io.IOException; import java.lang.ProcessBuilder.Redirect; @@ -314,5 +315,8 @@ String relativeDbgFileName = relativeFileName + "." + debugExt; - Files.write(resourceFileBinary, resource.contentBytes()); + try (InputStream in = resource.content()) { + Files.copy(in, resourceFileBinary); + } + Path resourceFileDebugSymbols; if (includeDebug) { Testing: tools/jlink, tools/jpackage, jdk-submit (running) -- Thanks, -Aleksey From mandy.chung at oracle.com Mon Mar 23 20:19:13 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 23 Mar 2020 13:19:13 -0700 Subject: RFR: JDK-8241463 Move build tools to respective modules In-Reply-To: References: Message-ID: <53d7119b-5e7e-22fe-97c1-0382f2d94fbc@oracle.com> Hi Magnus, Modularizing the build tools is a good move.??? This patch suggests to place the build tools under ??? src/$MODULE/share/tools/$PACKAGE/*.java I think the modular source location of the build tools needs more discussion, including jigsaw-dev for this discussion. The JDK source as specified in JEP 201 is under: ??? src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java Compiling the source files from the `src` directory are the intermediate input to build the resulting image.??? Build tools are used to generate additional intermediate input (that is not part of the `src` directory) to build the image.?? So I wonder if make/$MODULE/share/tools or make/tools/$MODULE? may be better location for the build tools. Mandy On 3/23/20 12:03 PM, Magnus Ihse Bursie wrote: > The build tools (small java tools that are run during the build to > generate source code, or data, needed in the JDK) have historically > been placed in the "make" directory. This maybe made sense long time > ago, but does not do so anymore. > > Instead, the build tools source code should move the the module that > needs them. For instance, compilefontconfig should move to > java.desktop, etc. > > There are multiple reasons for this: > > * Currently we build *all* build tools at once, which mean that we > cannot compile java.base until e.g. the compilefontconfig tool is > compiled, even though it is not needed. > > * If a build tool, e.g. compilefontconfig is modified, all build tools > are recompiled, which triggers a rebuild of more or less the entire > JDK. This makes development of the build tools unnecessary tedious. > > * When the build tools are modified, the group owning the > corresponding module is the proper review instance, not the build > team. But since they reside under "make", the review mails often > include build-dev, but this is mostly noise for us. With this move, > the ownership is made clear. > > In this patch, I have not modified how and when the build tools are > compiled, but this shuffle is the prerequisite for continuing with > that in a follow-up patch. > > I have also moved the build tools to the org.openjdk.buildtools.* > package name space (inspired by Skara), instead of the strangely named > build.tools.* name space. > > A few build tools are not moved in this patch. Two of them, > charsetmapping and cldrconverter, are shared between two modules. (I > think they should move to modules nevertheless, but they need some > more thought to make sure I do this right.) The rest are tools that > are needed for the build in general, like linking or javadoc support. > I'll move this to a better location too, but in a separate patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241463 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01 > > /Magnus > From Alan.Bateman at oracle.com Mon Mar 23 20:35:52 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Mar 2020 20:35:52 +0000 Subject: RFR (XS) 8241462: StripNativeDebugSymbols jlink plugin allocates huge arrays In-Reply-To: <65d59ecc-e999-e66a-4a03-27ec990f6ca5@redhat.com> References: <65d59ecc-e999-e66a-4a03-27ec990f6ca5@redhat.com> Message-ID: On 23/03/2020 19:22, Aleksey Shipilev wrote: > : > > +import java.io.InputStream; > import java.io.IOException; > import java.lang.ProcessBuilder.Redirect; > @@ -314,5 +315,8 @@ > String relativeDbgFileName = relativeFileName + "." + debugExt; > > - Files.write(resourceFileBinary, resource.contentBytes()); > + try (InputStream in = resource.content()) { > + Files.copy(in, resourceFileBinary); > + } > + > Path resourceFileDebugSymbols; > if (includeDebug) { > This looks okay. -Alan. From shade at redhat.com Tue Mar 24 11:03:34 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 24 Mar 2020 12:03:34 +0100 Subject: RFR (XS) 8241462: StripNativeDebugSymbols jlink plugin allocates huge arrays In-Reply-To: References: <65d59ecc-e999-e66a-4a03-27ec990f6ca5@redhat.com> Message-ID: <019318a9-995e-3e0f-28e0-67030297d5b7@redhat.com> On 3/23/20 9:35 PM, Alan Bateman wrote: > On 23/03/2020 19:22, Aleksey Shipilev wrote: >> +import java.io.InputStream; >> import java.io.IOException; >> import java.lang.ProcessBuilder.Redirect; >> @@ -314,5 +315,8 @@ >> String relativeDbgFileName = relativeFileName + "." + debugExt; >> >> - Files.write(resourceFileBinary, resource.contentBytes()); >> + try (InputStream in = resource.content()) { >> + Files.copy(in, resourceFileBinary); >> + } >> + >> Path resourceFileDebugSymbols; >> if (includeDebug) { >> > This looks okay. Thanks Alan. Severin, you're good with this? -- -Aleksey From magnus.ihse.bursie at oracle.com Tue Mar 24 11:16:39 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 24 Mar 2020 12:16:39 +0100 Subject: RFR: JDK-8241463 Move build tools to respective modules In-Reply-To: <53d7119b-5e7e-22fe-97c1-0382f2d94fbc@oracle.com> References: <53d7119b-5e7e-22fe-97c1-0382f2d94fbc@oracle.com> Message-ID: <4d36d2d4-9fc2-5476-9af7-127c4a69f23c@oracle.com> On 2020-03-23 21:19, Mandy Chung wrote: > Hi Magnus, > > Modularizing the build tools is a good move. Thanks! > This patch suggests to place the build tools under > ??? src/$MODULE/share/tools/$PACKAGE/*.java > > I think the modular source location of the build tools needs more > discussion, including jigsaw-dev for this discussion. Ok, I've pruned the recipient list down to just jigsaw-dev and build-dev. Let's keep this thread for discussing where to put the code in the source tree, and when we agree on that I can make an updated webrev and get buy-in from the component owners. > > The JDK source as specified in JEP 201 is under: > ??? src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java > > Compiling the source files from the `src` directory are the > intermediate input to build the resulting image.??? Build tools are > used to generate additional intermediate input (that is not part of > the `src` directory) to build the image.?? So I wonder if > make/$MODULE/share/tools or make/tools/$MODULE? may be better location > for the build tools. That's certainly a possibility. Ever since the big jigsaw restructuring, Erik and I have discussed how to modularize the build system. I did not even like the original jigsaw push, but there was not enough time to fix the build system, and as a compromise we opened a bunch of JBS issues to fix this in a follow-up fashion. Two are still remaining: JDK-8055192 and JDK-8055193, and JDK-8241463 is a part of that, even though it seems to have not been written down in a bug report at that time. At the core, we'd like to "invert" the current structure where we have files like: make/lib/Lib-java.base.gmk make/lib/Lib-java.desktop.gmk make/gensrc/Gensrc-java.base.gmk make/gensrc/Gensrc-java.desktop.gmk ... etc and instead have like: make/modules/java.base/lib.gmk make/modules/java.base/gensrc.gmk make/modules/java.desktop/lib.gmk make/modules/java.desktop/gensrc.gmk However, this stuff is clearly a core part of the build system, so there is no question that this belongs under "make". In contrast, the build tools are only interacting with the build system on the surface. There is some kind of an API here -- the build tools have some kind of calling convention, wants some input and produces some output, which is consumed by the build system. But the actual workings of the build tools have 100% to do with the component. In some cases, the original developer found it more suitable to create a tool for generating programmatically a number of classes, rather than doing that once, for hand, and check in the code. (I'm a bit skeptical towards those build tools, btw, even though I understand the reason.) But this clearly is just another way to express the core functionality of that module. If anything is causing confusion right now, it's when the component teams do not know about or take responsibility for the build tools. So I think the build tools are just like much of the rest of the product -- the build system needs to be aware of them and how they work, but they are really the expression -- and responsibility -- of the component owners. And thus, I believe they are much better suited in the src tree. Furthermore, we have JDK-8055193, about modularizing the make/data directory. This is something I care even more about. And here I'm quite firm in my conviction that this has nothing to do in the make directory. It's just a remnant of the old thinking of "Oh, I don't know where to put this. Let's just continue using 'make' as our misc trashcan". Things like make/data/macosxicons should move to src/java.desktop/data/macosxicons, and make/data/publicsuffixlist to src/java.base/data/publicsuffixlist, and so forth. There's absolutely nothing here that has anything to do with the build system. (With the possible exception of product-wide stuff, I know these exists among the tools, I'm not sure about the data.) And since there is a strong correlation between the data files and the build tools -- many build tools are custom made to process things in the data directory -- I think it makes much sense to move the source code of the tools along with them. We already have collected everything else that belongs to a module under src/$module/share. Apart from classes, and native, we have: * conf * lib * legal * man for those modules that require them. My suggestion is that we add, for those module that require them: * data * tools If the name of the latter is not good enough, I'm open for suggestions. Maybe "build-tools", "buildtools", "tools-src", "tools-classes", "classes-tools"...? My idea for picking "tools" was that it was short, and seemed to fit in well with the style of the other names. An additional? benefit was that it was not as limiting as "buildtools", and thus allowing for the modules to put other kinds of tools there that might not be needed at build time -- for instance, tools that are needed every once in a while to update some checked-in files, like make/script/generate-symbol-data.sh (which really belongs to jdk.compiler). And regarding JEP 201, as far as I can tell the additional "man" and "lib" directories do not seem to be reflected in JEP 201. I do not know if this is considered an oversight, or just reflecting the fact that the directory structure will continue to evolve after JEP 201 were delivered. But if you think JEP 201 needs to be updated, fine, I'll gladly help with that. /Magnus > > Mandy > > On 3/23/20 12:03 PM, Magnus Ihse Bursie wrote: >> The build tools (small java tools that are run during the build to >> generate source code, or data, needed in the JDK) have historically >> been placed in the "make" directory. This maybe made sense long time >> ago, but does not do so anymore. >> >> Instead, the build tools source code should move the the module that >> needs them. For instance, compilefontconfig should move to >> java.desktop, etc. >> >> There are multiple reasons for this: >> >> * Currently we build *all* build tools at once, which mean that we >> cannot compile java.base until e.g. the compilefontconfig tool is >> compiled, even though it is not needed. >> >> * If a build tool, e.g. compilefontconfig is modified, all build >> tools are recompiled, which triggers a rebuild of more or less the >> entire JDK. This makes development of the build tools unnecessary >> tedious. >> >> * When the build tools are modified, the group owning the >> corresponding module is the proper review instance, not the build >> team. But since they reside under "make", the review mails often >> include build-dev, but this is mostly noise for us. With this move, >> the ownership is made clear. >> >> In this patch, I have not modified how and when the build tools are >> compiled, but this shuffle is the prerequisite for continuing with >> that in a follow-up patch. >> >> I have also moved the build tools to the org.openjdk.buildtools.* >> package name space (inspired by Skara), instead of the strangely >> named build.tools.* name space. >> >> A few build tools are not moved in this patch. Two of them, >> charsetmapping and cldrconverter, are shared between two modules. (I >> think they should move to modules nevertheless, but they need some >> more thought to make sure I do this right.) The rest are tools that >> are needed for the build in general, like linking or javadoc support. >> I'll move this to a better location too, but in a separate patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8241463 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01 >> >> /Magnus >> > From jendrik at gradle.com Tue Mar 24 15:15:53 2020 From: jendrik at gradle.com (Jendrik Johannes) Date: Tue, 24 Mar 2020 16:15:53 +0100 Subject: Java Module support in Gradle 6.4 - request for feedback Message-ID: Hi, Gradle 6.4 (to be released in April) will finally have built-in support for building Java modules. The initial implementation has just been merged and is available in the latest nightly. https://services.gradle.org/distributions-snapshots/gradle-6.4-20200323230320+0000-bin.zip We are interested in early feedback! As there is no official documentation yet, we have assembled a sample and added some more information here: https://github.com/gradle/gradle/issues/890#issuecomment-603289940 If you are using Gradle to build Java modules, or have been waiting for this to start doing so, we would love to hear from you by commenting on the GH issue above. Regards, Jendrik on behalf of the Gradle team From sgehwolf at redhat.com Tue Mar 24 17:40:53 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 24 Mar 2020 18:40:53 +0100 Subject: RFR (XS) 8241462: StripNativeDebugSymbols jlink plugin allocates huge arrays In-Reply-To: <019318a9-995e-3e0f-28e0-67030297d5b7@redhat.com> References: <65d59ecc-e999-e66a-4a03-27ec990f6ca5@redhat.com> <019318a9-995e-3e0f-28e0-67030297d5b7@redhat.com> Message-ID: On Tue, 2020-03-24 at 12:03 +0100, Aleksey Shipilev wrote: > On 3/23/20 9:35 PM, Alan Bateman wrote: > > On 23/03/2020 19:22, Aleksey Shipilev wrote: > > > +import java.io.InputStream; > > > import java.io.IOException; > > > import java.lang.ProcessBuilder.Redirect; > > > @@ -314,5 +315,8 @@ > > > String relativeDbgFileName = relativeFileName + "." + debugExt; > > > > > > - Files.write(resourceFileBinary, resource.contentBytes()); > > > + try (InputStream in = resource.content()) { > > > + Files.copy(in, resourceFileBinary); > > > + } > > > + > > > Path resourceFileDebugSymbols; > > > if (includeDebug) { > > > > > This looks okay. > > Thanks Alan. > > Severin, you're good with this? Looks good. Thanks, Severin From shade at redhat.com Tue Mar 24 17:43:44 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 24 Mar 2020 18:43:44 +0100 Subject: RFR (XS) 8241462: StripNativeDebugSymbols jlink plugin allocates huge arrays In-Reply-To: References: <65d59ecc-e999-e66a-4a03-27ec990f6ca5@redhat.com> <019318a9-995e-3e0f-28e0-67030297d5b7@redhat.com> Message-ID: <299f0538-db8b-0e56-f71d-6599e3bc2294@redhat.com> On 3/24/20 6:40 PM, Severin Gehwolf wrote: > On Tue, 2020-03-24 at 12:03 +0100, Aleksey Shipilev wrote: >> On 3/23/20 9:35 PM, Alan Bateman wrote: >>> On 23/03/2020 19:22, Aleksey Shipilev wrote: >>>> +import java.io.InputStream; >>>> import java.io.IOException; >>>> import java.lang.ProcessBuilder.Redirect; >>>> @@ -314,5 +315,8 @@ >>>> String relativeDbgFileName = relativeFileName + "." + debugExt; >>>> >>>> - Files.write(resourceFileBinary, resource.contentBytes()); >>>> + try (InputStream in = resource.content()) { >>>> + Files.copy(in, resourceFileBinary); >>>> + } >>>> + >>>> Path resourceFileDebugSymbols; >>>> if (includeDebug) { >>>> >>> This looks okay. >> >> Thanks Alan. >> >> Severin, you're good with this? > > Looks good. Thanks! -- -Aleksey From mandy.chung at oracle.com Wed Mar 25 20:04:00 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 Mar 2020 13:04:00 -0700 Subject: RFR: JDK-8241463 Move build tools to respective modules In-Reply-To: <4d36d2d4-9fc2-5476-9af7-127c4a69f23c@oracle.com> References: <53d7119b-5e7e-22fe-97c1-0382f2d94fbc@oracle.com> <4d36d2d4-9fc2-5476-9af7-127c4a69f23c@oracle.com> Message-ID: Hi Magnus, On 3/24/20 4:16 AM, Magnus Ihse Bursie wrote: > > At the core, we'd like to "invert" the current structure where we have > files like: > make/lib/Lib-java.base.gmk > make/lib/Lib-java.desktop.gmk > make/gensrc/Gensrc-java.base.gmk > make/gensrc/Gensrc-java.desktop.gmk > ... etc > > and instead have like: > make/modules/java.base/lib.gmk > make/modules/java.base/gensrc.gmk > make/modules/java.desktop/lib.gmk > make/modules/java.desktop/gensrc.gmk > > : > > We already have collected everything else that belongs to a module > under src/$module/share. Apart from classes, and native, we have: > * conf > * lib > * legal > * man > for those modules that require them. > > My suggestion is that we add, for those module that require them: > * data > * tools > I think we should take at modularizing make/data, build tools, make/gensrc etc as a whole and put down other options considered. I haven't had time looking closely but I try to understand how make/data are used.? Here are some examples of it that produces either gensrc/$MODULE/$PACKAGE/*.java files or files in jdk build output. ?? - generate source files from gensrc/$MODULE/$PACKAGE/*.java.template ?? - generate resource bundle from gensrc/$MODULE/$PACKAGE/resource/*.properties ?? - generate CLDR locale data from make/data/cldr files ?? - generate jdk/lib/tzdb.dat from make/data/tzdata ?? - generate jdk/lib/ct.sym from make/data/symbol ?? - generate jdk/lib/security/cacerts from make/data/cacerts ?? - generate jdk/lib/security/backlisted.certs from make/data/blacklistedcertsconverter ?? - generate jdk/lib/security/public_suffix_list.data from make/data/publicsuffixlist I can see why you propose the data files are moved to the source. There could be other options to explore. Another observation:? Some build tools are module-specific (e.g. generate icons .png.java files) that is clearly used only by one module.?? There are other build tools that can be used by any module e.g. generate resource bundle .java source. > And regarding JEP 201, as far as I can tell the additional "man" and > "lib" directories do not seem to be reflected in JEP 201. I do not > know if this is considered an oversight, or just reflecting the fact > that the directory structure will continue to evolve after JEP 201 > were delivered. But if you think JEP 201 needs to be updated, fine, > I'll gladly help with that. > JEP 299 discusses the reorganization of man pages and specification and specifies the man directory.? When JEP 201 was written, the man directory was not present (part of moving the specs effort to the openjdk source).?? It was added in JDK 12.? "lib" directory is an oversight. JEP 201 may need update for this build modularization work too. Mandy From sebastian.stenzel at gmail.com Tue Mar 31 07:18:24 2020 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Tue, 31 Mar 2020 09:18:24 +0200 Subject: jlink fails with "Hash of java.xyz differs to expected hash recorded in java.base" Message-ID: <8AD7B489-4C00-4F20-B23D-FD0E35AE54A6@gmail.com> Hi all, not sure if this is the right mailing list to ask about this, but I found some previous mails in the archive that suggested it. I noticed that whenever I use OpenJDK 11 - 14 on Ubuntu from the distro's official package repo, jlink always fails with messages like these: Hash of java.xml (c043b4c28b897656e2a4d36c92ba2f5d52134bce79643236dd36295e14178be7) differs to expected hash (4e7db7fc941d9f316c4aafe02717b5809ee722be8433d283050365e7fd49331f) recorded in java.base Using adoptopenjdk, it works just fine. So I believe there is something wrong with Ubuntu's OpenJDK package, however I can hardly tell what they did wrong, since I don't understand what exactly jlink hashes and where the expected hashes are stored. Can anyone shed some light on what is happening here? Thanks! Sebastian From Alan.Bateman at oracle.com Tue Mar 31 07:47:25 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 31 Mar 2020 08:47:25 +0100 Subject: jlink fails with "Hash of java.xyz differs to expected hash recorded in java.base" In-Reply-To: <8AD7B489-4C00-4F20-B23D-FD0E35AE54A6@gmail.com> References: <8AD7B489-4C00-4F20-B23D-FD0E35AE54A6@gmail.com> Message-ID: <9a67b36d-a72d-b360-13b8-6e774dff6865@oracle.com> On 31/03/2020 08:18, Sebastian Stenzel wrote: > Hi all, > > not sure if this is the right mailing list to ask about this, but I found some previous mails in the archive that suggested it. > > I noticed that whenever I use OpenJDK 11 - 14 on Ubuntu from the distro's official package repo, jlink always fails with messages like these: > > Hash of java.xml (c043b4c28b897656e2a4d36c92ba2f5d52134bce79643236dd36295e14178be7) differs to expected hash (4e7db7fc941d9f316c4aafe02717b5809ee722be8433d283050365e7fd49331f) recorded in java.base > > The hashes of the standard and JDK modules are stored in the java.base module to prevent accidental mismatch at link time. In this case it suggests that java.base and java.xml came from different builds or maybe the Ubuntu is doing stripping or other modifications to the packaged modules. I did a quick search and it looks like it has been noticed by others too [1] -Alan [1] https://bugs.launchpad.net/ubuntu/+source/openjdk-14/+bug/1868699 From sebastian.stenzel at gmail.com Tue Mar 31 07:50:46 2020 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Tue, 31 Mar 2020 09:50:46 +0200 Subject: jlink fails with "Hash of java.xyz differs to expected hash recorded in java.base" In-Reply-To: <9a67b36d-a72d-b360-13b8-6e774dff6865@oracle.com> References: <8AD7B489-4C00-4F20-B23D-FD0E35AE54A6@gmail.com> <9a67b36d-a72d-b360-13b8-6e774dff6865@oracle.com> Message-ID: <0A5BD631-2CA9-44E4-B76A-F025590337F6@gmail.com> > Am 31.03.2020 um 09:47:25 schrieb Alan Bateman : > > On 31/03/2020 08:18, Sebastian Stenzel wrote: >> Hi all, >> >> not sure if this is the right mailing list to ask about this, but I found some previous mails in the archive that suggested it. >> >> I noticed that whenever I use OpenJDK 11 - 14 on Ubuntu from the distro's official package repo, jlink always fails with messages like these: >> >> Hash of java.xml (c043b4c28b897656e2a4d36c92ba2f5d52134bce79643236dd36295e14178be7) differs to expected hash (4e7db7fc941d9f316c4aafe02717b5809ee722be8433d283050365e7fd49331f) recorded in java.base >> >> > The hashes of the standard and JDK modules are stored in the java.base module to prevent accidental mismatch at link time. In this case it suggests that java.base and java.xml came from different builds or maybe the Ubuntu is doing stripping or other modifications to the packaged modules. I did a quick search and it looks like it has been noticed by others too [1] > > -Alan > > [1] https://bugs.launchpad.net/ubuntu/+source/openjdk-14/+bug/1868699 This was my bug report, that's why I'm investigating to give the Ubuntu guys some tips on how they can solve it (if they caused it in the first place). ;-) From Alan.Bateman at oracle.com Tue Mar 31 08:04:19 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 31 Mar 2020 09:04:19 +0100 Subject: jlink fails with "Hash of java.xyz differs to expected hash recorded in java.base" In-Reply-To: <0A5BD631-2CA9-44E4-B76A-F025590337F6@gmail.com> References: <8AD7B489-4C00-4F20-B23D-FD0E35AE54A6@gmail.com> <9a67b36d-a72d-b360-13b8-6e774dff6865@oracle.com> <0A5BD631-2CA9-44E4-B76A-F025590337F6@gmail.com> Message-ID: <15bdf5ce-f73d-6380-cc47-b5c45553f3a7@oracle.com> On 31/03/2020 08:50, Sebastian Stenzel wrote: > : > This was my bug report, that's why I'm investigating to give the Ubuntu guys some tips on how they can solve it (if they caused it in the first place). ;-) Ah, didn't see it was you :-) I've seen a few reports of issues on Ubuntu go by (like the javac launcher missing from a run-time image that claims to have the jdk.compiler module) which hints to me that the bits in the Ubuntu openjdk-* packages have additional patches and/or they are processed by something that is changing the bits. I don't have cycles to dig into it so hopefully your bug report will help the maintainers to track it down. -Alan.