From Alan.Bateman at oracle.com Tue May 5 19:05:05 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 May 2020 20:05:05 +0100 Subject: 8243596: ModuleLayer::parents should return an unmodifiable list Message-ID: <6611dc87-52ae-faa9-f449-2d82cf2b78a7@oracle.com> This is an small oversight and inconsistency that crept in when the ModuleLayer was updated to support multiple parents. The list of parent layers returned by the parents() method should be specified (and implemented) to return an unmodifiable list. It currently returns a modifiable list. The equivalent Configuration::parents is correctly specified, as is the Configuration::modules and ModuleLayer::modules methods. The change proposed here fixes the javadoc and implementation. The compatibility impact is minimal as nothing could depend on being able to dynamically change the list of parents (as it can't be changed dynamically). I've extended the existing tests to ensure that ::modules, Configuration::parents, ModuleLayer::modules and ModuleLayer::parents return unmodifiable collections. In passing, there is also a typo in the Configuration::modules where the javadoc says "immutable" instead of "unmodifiable". http://cr.openjdk.java.net/~alanb/8243596/webrev/ The patch doesn't update the date in the copyright headers, I'll update those before pushing after the changes (and CSR) are agreed. -Alan From james.laskey at oracle.com Tue May 5 19:56:03 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 5 May 2020 16:56:03 -0300 Subject: RFR: JDK-8241602 jlink does not produce reproducible jimage files Message-ID: <0449756E-0941-4FC1-9FA6-E36B4244A34D@oracle.com> This fix addresses the inconsistent ordering by jimage content by jlink from run to run. Bottom line, the implementer was using HashSet without defining hashcode/equals for the Set entry classes. webrev: http://cr.openjdk.java.net/~jlaskey/8241602/webrev-00 jbs: https://bugs.openjdk.java.net/browse/JDK-8241602 Cheers, -- Jim From mandy.chung at oracle.com Tue May 5 22:16:29 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 5 May 2020 15:16:29 -0700 Subject: 8243596: ModuleLayer::parents should return an unmodifiable list In-Reply-To: <6611dc87-52ae-faa9-f449-2d82cf2b78a7@oracle.com> References: <6611dc87-52ae-faa9-f449-2d82cf2b78a7@oracle.com> Message-ID: On 5/5/20 12:05 PM, Alan Bateman wrote: > > This is an small oversight and inconsistency that crept in when the > ModuleLayer was updated to support multiple parents. The list of > parent layers returned by the parents() method should be specified > (and implemented) to return an unmodifiable list. It currently returns > a modifiable list. The equivalent Configuration::parents is correctly > specified, as is the Configuration::modules and ModuleLayer::modules > methods. > > The change proposed here fixes the javadoc and implementation. The > compatibility impact is minimal as nothing could depend on being able > to dynamically change the list of parents (as it can't be changed > dynamically). > > I've extended the existing tests to ensure that ::modules, > Configuration::parents, ModuleLayer::modules and ModuleLayer::parents > return unmodifiable collections. In passing, there is also a typo in > the Configuration::modules where the javadoc says "immutable" instead > of "unmodifiable". > > http://cr.openjdk.java.net/~alanb/8243596/webrev/ > This patch looks good. Mandy From magnus.ihse.bursie at oracle.com Wed May 6 07:00:43 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 6 May 2020 09:00:43 +0200 Subject: RFR: JDK-8241602 jlink does not produce reproducible jimage files In-Reply-To: <0449756E-0941-4FC1-9FA6-E36B4244A34D@oracle.com> References: <0449756E-0941-4FC1-9FA6-E36B4244A34D@oracle.com> Message-ID: <91dc6628-1adf-eb76-c893-ccd1b1fd7800@oracle.com> On 2020-05-05 21:56, Jim Laskey wrote: > This fix addresses the inconsistent ordering by jimage content by jlink from run to run. Bottom line, the implementer was using HashSet without defining hashcode/equals for the Set entry classes. > > webrev: http://cr.openjdk.java.net/~jlaskey/8241602/webrev-00 Looks good to me. /Magnus > jbs: https://bugs.openjdk.java.net/browse/JDK-8241602 > > Cheers, > > -- Jim > From Alan.Bateman at oracle.com Wed May 6 07:14:22 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 May 2020 08:14:22 +0100 Subject: RFR: JDK-8241602 jlink does not produce reproducible jimage files In-Reply-To: <0449756E-0941-4FC1-9FA6-E36B4244A34D@oracle.com> References: <0449756E-0941-4FC1-9FA6-E36B4244A34D@oracle.com> Message-ID: On 05/05/2020 20:56, Jim Laskey wrote: > This fix addresses the inconsistent ordering by jimage content by jlink from run to run. Bottom line, the implementer was using HashSet without defining hashcode/equals for the Set entry classes. > > webrev: http://cr.openjdk.java.net/~jlaskey/8241602/webrev-00 > jbs: https://bugs.openjdk.java.net/browse/JDK-8241602 > DirArchive and JmodArchive look okay. They could use Objects.hash/equals but what you have is okay too. Can you re-check JarArchive as it is created with a runtime version so equals should be checking 3 fields. The existing test for reproducible builds is JLinkReproducibleTest. Adding a new test is okay too but we should at least try to keep the names consistent. A couple of suggestions for the test in the webrev: - the @modules tag needs to include java.desktop as it is needed by the test. Better still would be to change to java.se so that there are more modules in the images. - Did you mean to open jdk.tools.jlink.internal? Maybe its a leftover from a previous iteration of the test? - You can use Files.mismatch to compare the lib/modules files are identical (like JLinkReproducibleTest).? It's okay to use the jimage ImageReaderFactory to check the names tables too but I think it's more important to check that the lib/modules files are identical before probing further. -Alan From james.laskey at oracle.com Wed May 6 13:42:46 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 6 May 2020 10:42:46 -0300 Subject: RFR: JDK-8241602 jlink does not produce reproducible jimage files In-Reply-To: References: <0449756E-0941-4FC1-9FA6-E36B4244A34D@oracle.com> Message-ID: <0CD37DE0-D3BA-4260-96B4-A960CBF81962@oracle.com> Thank you. Notes below. updated webrev: http://cr.openjdk.java.net/~jlaskey/8241602/webrev-00 > On May 6, 2020, at 4:14 AM, Alan Bateman wrote: > > On 05/05/2020 20:56, Jim Laskey wrote: >> This fix addresses the inconsistent ordering by jimage content by jlink from run to run. Bottom line, the implementer was using HashSet without defining hashcode/equals for the Set entry classes. >> >> webrev: http://cr.openjdk.java.net/~jlaskey/8241602/webrev-00 >> jbs: https://bugs.openjdk.java.net/browse/JDK-8241602 >> > DirArchive and JmodArchive look okay. They could use Objects.hash/equals but what you have is okay too. Can you re-check JarArchive as it is created with a runtime version so equals should be checking 3 fields. Opted to use Objects. Added version for JarArchive (not convinced needed but should be benign.) > > The existing test for reproducible builds is JLinkReproducibleTest. Adding a new test is okay too but we should at least try to keep the names consistent. A couple of suggestions for the test in the webrev: > - the @modules tag needs to include java.desktop as it is needed by the test. Better still would be to change to java.se so that there are more modules in the images. Switched to java.se, only a second slower than java.desktop . Overall better test than JLinkReproducibleTest for increased likelihood of variance. > - Did you mean to open jdk.tools.jlink.internal? Maybe its a leftover from a previous iteration of the test? Nope, Yep. > - You can use Files.mismatch to compare the lib/modules files are identical (like JLinkReproducibleTest). It's okay to use the jimage ImageReaderFactory to check the names tables too but I think it's more important to check that the lib/modules files are identical before probing further. I had it in my mind there was a timestamp in the file, but then I remembered there wasn't. Switched to Files.mismatch. Everything else is redundant. Aside: The order in the file is still somewhat scattered, based on archive and archive content. We have the a pattern based sorting plugin which we don't use and we never did any locality vs performance testing. > > -Alan From Alan.Bateman at oracle.com Wed May 6 14:05:14 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 May 2020 15:05:14 +0100 Subject: RFR: JDK-8241602 jlink does not produce reproducible jimage filesJ In-Reply-To: <0CD37DE0-D3BA-4260-96B4-A960CBF81962@oracle.com> References: <0449756E-0941-4FC1-9FA6-E36B4244A34D@oracle.com> <0CD37DE0-D3BA-4260-96B4-A960CBF81962@oracle.com> Message-ID: <8b1b7f66-ae6b-54b7-2185-74ec20ab2b07@oracle.com> On 06/05/2020 14:42, Jim Laskey wrote: > : > > Aside: The order in the file is still somewhat scattered, based on > archive and archive content. ?We have the a pattern based sorting > plugin which we don't use and we never did any locality vs performance > testing. > Not in the test but the JDK does use the order-resources plugin with the following pattern: JLINK_ORDER_RESOURCES += \ ??? /java.base/java/** \ ??? /java.base/jdk/** \ ??? /java.base/sun/** \ ??? /java.base/com/** \ ??? /jdk.localedata/** \ ??? # Anyway, I looked at webrev-01 and the jlink changes look good. The updated test doesn't use the jimage API so no need to open jdk.internal.jimage. The imports can be removed too, also RUNTIME is no longer used in this version. Have you decided on a test name? The rallying call is "reproducible builds" and I'd prefer to have "Reproducible" in the test name so its consistent with the existing test that checks for reproducible with user modules. -Alan. From james.laskey at oracle.com Wed May 6 14:45:32 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 6 May 2020 11:45:32 -0300 Subject: RFR: JDK-8241602 jlink does not produce reproducible jimage filesJ In-Reply-To: <8b1b7f66-ae6b-54b7-2185-74ec20ab2b07@oracle.com> References: <0449756E-0941-4FC1-9FA6-E36B4244A34D@oracle.com> <0CD37DE0-D3BA-4260-96B4-A960CBF81962@oracle.com> <8b1b7f66-ae6b-54b7-2185-74ec20ab2b07@oracle.com> Message-ID: <7449D5CF-5757-4E12-884A-D651A14AE523@oracle.com> http://cr.openjdk.java.net/~jlaskey/8241602/webrev-02 > On May 6, 2020, at 11:05 AM, Alan Bateman wrote: > > On 06/05/2020 14:42, Jim Laskey wrote: >> : >> >> Aside: The order in the file is still somewhat scattered, based on archive and archive content. We have the a pattern based sorting plugin which we don't use and we never did any locality vs performance testing. >> > Not in the test but the JDK does use the order-resources plugin with the following pattern: > > JLINK_ORDER_RESOURCES += \ > /java.base/java/** \ > /java.base/jdk/** \ > /java.base/sun/** \ > /java.base/com/** \ > /jdk.localedata/** \ > # > > Anyway, I looked at webrev-01 and the jlink changes look good. The updated test doesn't use the jimage API so no need to open jdk.internal.jimage. The imports can be removed too, also RUNTIME is no longer used in this version. Have you decided on a test name? The rallying call is "reproducible builds" and I'd prefer to have "Reproducible" in the test name so its consistent with the existing test that checks for reproducible with user modules. > > -Alan. > > From Alan.Bateman at oracle.com Wed May 6 15:12:59 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 May 2020 16:12:59 +0100 Subject: RFR: JDK-8241602 jlink does not produce reproducible jimage filesJ In-Reply-To: <7449D5CF-5757-4E12-884A-D651A14AE523@oracle.com> References: <0449756E-0941-4FC1-9FA6-E36B4244A34D@oracle.com> <0CD37DE0-D3BA-4260-96B4-A960CBF81962@oracle.com> <8b1b7f66-ae6b-54b7-2185-74ec20ab2b07@oracle.com> <7449D5CF-5757-4E12-884A-D651A14AE523@oracle.com> Message-ID: <122dc847-5d5b-512b-d589-31157d1ecdf9@oracle.com> On 06/05/2020 15:45, Jim Laskey wrote: > http://cr.openjdk.java.net/~jlaskey/8241602/webrev-02 This version looks okay to me. -Alan. From mandy.chung at oracle.com Thu May 7 17:12:14 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 7 May 2020 10:12:14 -0700 Subject: Review Request 8240910: jmod rejects duplicate entries in --class-path jars Message-ID: jmod tool should ignore duplicated resources from class path and emit a warning.? It currently ignores duplicated resources when read from a directory but not from JAR entries.? It's an oversight from the fix for JDK-8134779 [1] http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8240910/webrev.00/ This is a simple fix applying the same fix for JDK-8134779 to ignore duplicated entries processed from a JAR file. Thanks Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8134779 From lance.andersen at oracle.com Thu May 7 17:21:53 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 7 May 2020 13:21:53 -0400 Subject: Review Request 8240910: jmod rejects duplicate entries in --class-path jars In-Reply-To: References: Message-ID: +1 > On May 7, 2020, at 1:12 PM, Mandy Chung wrote: > > jmod tool should ignore duplicated resources from class path and emit a warning. It currently ignores duplicated resources when read from a directory but not from JAR entries. It's an oversight from the fix for JDK-8134779 [1] > > http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8240910/webrev.00/ > > This is a simple fix applying the same fix for JDK-8134779 to ignore duplicated entries processed from a JAR file. > > Thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8134779 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mandy.chung at oracle.com Thu May 7 18:39:45 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 7 May 2020 11:39:45 -0700 Subject: Review Request 8240910: jmod rejects duplicate entries in --class-path jars In-Reply-To: References: Message-ID: <21917d42-d7a6-f764-fdff-69cabf470d0a@oracle.com> I have taken a further step to clean this up by recording the written entries such that it can filter out duplicated entries properly: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8240910/webrev.01/ thanks Mandy On 5/7/20 10:12 AM, Mandy Chung wrote: > jmod tool should ignore duplicated resources from class path and emit > a warning.? It currently ignores duplicated resources when read from a > directory but not from JAR entries.? It's an oversight from the fix > for JDK-8134779 [1] > > http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8240910/webrev.00/ > > This is a simple fix applying the same fix for JDK-8134779 to ignore > duplicated entries processed from a JAR file. > > Thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8134779 From Alan.Bateman at oracle.com Thu May 7 18:55:52 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 7 May 2020 19:55:52 +0100 Subject: Review Request 8240910: jmod rejects duplicate entries in --class-path jars In-Reply-To: <21917d42-d7a6-f764-fdff-69cabf470d0a@oracle.com> References: <21917d42-d7a6-f764-fdff-69cabf470d0a@oracle.com> Message-ID: <0de7def5-190e-5070-4844-976bf66dd9d3@oracle.com> On 07/05/2020 19:39, Mandy Chung wrote: > I have taken a further step to clean this up by recording the written > entries such that it can filter out duplicated entries properly: > > http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8240910/webrev.01/ This version looks okay to me as it cleans up the original code for the exploded case too. -Alan From lance.andersen at oracle.com Thu May 7 20:48:14 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 7 May 2020 16:48:14 -0400 Subject: Review Request 8240910: jmod rejects duplicate entries in --class-path jars In-Reply-To: <21917d42-d7a6-f764-fdff-69cabf470d0a@oracle.com> References: <21917d42-d7a6-f764-fdff-69cabf470d0a@oracle.com> Message-ID: Hi Mandy, The extra updates look good. Thank you for adding the additional clean up! Best Lance > On May 7, 2020, at 2:39 PM, Mandy Chung wrote: > > I have taken a further step to clean this up by recording the written entries such that it can filter out duplicated entries properly: > > http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8240910/webrev.01/ > > thanks > Mandy > > On 5/7/20 10:12 AM, Mandy Chung wrote: >> jmod tool should ignore duplicated resources from class path and emit a warning. It currently ignores duplicated resources when read from a directory but not from JAR entries. It's an oversight from the fix for JDK-8134779 [1] >> >> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8240910/webrev.00/ >> >> This is a simple fix applying the same fix for JDK-8134779 to ignore duplicated entries processed from a JAR file. >> >> Thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8134779 > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From ooo_saturn7 at mail.ru Sat May 16 16:53:16 2020 From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=) Date: Sat, 16 May 2020 19:53:16 +0300 Subject: =?UTF-8?B?SmF2YUNvbXBpbGVyIGNhbGxlZCBmcm9tIEpQTVMgbW9kdWxl?= Message-ID: <1589647996.253846762@f108.i.mail.ru> Hi all, ? I am working with H2 java database that allows to create triggers from java source code. To compile the trigger the following code is used: ? ??? JavaCompiler JAVA_COMPILER = ToolProvider.getSystemJavaCompiler(); ??? String fullClassName = packageName + "." + className; ??? StringWriter writer = new StringWriter(); ??? try (JavaFileManager fileManager = new ??????????? ClassFileManager(JAVA_COMPILER ??????????????? .getStandardFileManager(null, null, null))) { ??????? ArrayList compilationUnits = new ArrayList<>(); ??????? compilationUnits.add(new StringJavaFileObject(fullClassName, source)); ??????? // cannot concurrently compile ??????? final boolean ok; ??????? synchronized (JAVA_COMPILER) { ??????????? ok = JAVA_COMPILER.getTask(writer, fileManager, null, null, ??????????????????? null, compilationUnits).call(); ??????? } ??????? String output = writer.toString(); ??????? handleSyntaxError(output, (ok? 0: 1)); ??????? return fileManager.getClassLoader(null).loadClass(fullClassName); ??? } catch (ClassNotFoundException | IOException e) { ??????? throw DbException.convert(e); ??? } ? Trigger `fullClassName` = `org.h2.dynamic.trigger.SOME_TRIGGER`. And the trigger `source` = ??? package org.h2.dynamic.trigger; ??? import java.util.*; ??? import java.math.*; ??? import java.sql.*; ??? public class SOME_TRIGGER { ??????? public static org.h2.api.Trigger create() { ?? ? ??????? return new org.h2.api.Trigger() { ?????????? ? ??????????? @Override ??????????? public void init(Connection conn, String schemaName, String triggerName, ??????????????????? String tableName, boolean before, int type) throws SQLException { } ?????????? ? ??????????? @Override ??????????? public void fire(Connection conn, Object[] oldRow, Object[] newRow) throws SQLException { } ?? ? ??????????? @Override ??????????? public void close() throws SQLException { } ?? ? ??????????? @Override ??????????? public void remove() throws SQLException { } ?? ? ??????? }; ??? } ??? } ? ? When H2 is on classpath I don't have any problems - trigger is compiled. However, when H2 is on module path (H2 has in manifest Automatic-Module-Name: com.h2database) on some of child layers (not boot layer) I get the following `output`: ? ??? /org/h2/dynamic/trigger/SOME_TRIGGER.java:6: error: package org.h2.api does not exist ??????? public static org.h2.api.Trigger create() { ??????????????????????????????? ^ ??? 1 error ? As I understand the problem is with classloader and JavaCompiler. Could anyone say how it can be fixed? ? Best regards, Alex From Alan.Bateman at oracle.com Sat May 16 17:23:49 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 16 May 2020 18:23:49 +0100 Subject: JavaCompiler called from JPMS module In-Reply-To: <1589647996.253846762@f108.i.mail.ru> References: <1589647996.253846762@f108.i.mail.ru> Message-ID: <3410006c-12b3-cc78-4cfb-5ae67b5fbbb4@oracle.com> On 16/05/2020 17:53, Alex Sviridov wrote: > : > > > When H2 is on classpath I don't have any problems - trigger is compiled. However, when H2 is on > module path (H2 has in manifest Automatic-Module-Name: com.h2database) on some of child layers > (not boot layer) I get the following `output`: > > ??? /org/h2/dynamic/trigger/SOME_TRIGGER.java:6: error: package org.h2.api does not exist > ??????? public static org.h2.api.Trigger create() { > ??????????????????????????????? ^ > ??? 1 error > > As I understand the problem is with classloader and JavaCompiler. Could anyone say how it can be fixed? > You can't compile against modules in module layers. Instead you'll need to specify the module path where the compiler can find the JAR file with module com.h2database. This snippet might help: ??????? Path src = ...?????? // path to the source code for SOME_TRIGGER ??????? Path dir = ...?????? // directory that contains com.h2database ??????? Path output = ... // output directory ??????? JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); ??????? StandardJavaFileManager fm = compiler.getStandardFileManager(null, null, null); ??????? fm.setLocationFromPaths(StandardLocation.MODULE_PATH, List.of(dir)); ??????? fm.setLocationFromPaths(StandardLocation.CLASS_OUTPUT, List.of(output)); ??????? Iterable paths = fm.getJavaFileObjects(src); ??????? JavaCompiler.CompilationTask task = compiler.getTask(null, fm, null, null, null, paths); ??????? task.addModules(List.of("com.h2database")); ??????? task.call(); The call to addModules is needed because SOME_TRIGGER isn't being compiled as a module so there is nobody to require com.h2database. -Alan From ooo_saturn7 at mail.ru Tue May 19 08:00:44 2020 From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBPcmxvdg==?=) Date: Tue, 19 May 2020 11:00:44 +0300 Subject: =?UTF-8?B?SlBNUyBtb2R1bGUtcGF0aCBhbmQgbGF5ZXJz?= Message-ID: <1589875244.739422859@f415.i.mail.ru> Hi all, ? I want to understand all details of module-path and layers in java9+ and I have two questions: * As I understand modules on module-path are added automatically only to boot layer and not added automatically to any other layers. I mean, if any child layers are created module-path will be ignored for them. Is this correct? * Not all modules from module-path are added to boot layer, but only main module and dependent modules. For example, if we have A , B , C , D modules on module-path and A is main module and uses B , B uses C , then D module won't be added to boot layer. Is this correct? Could anyone help me with these questions? ? -- Alex Orlov From Alan.Bateman at oracle.com Tue May 19 13:50:43 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 May 2020 14:50:43 +0100 Subject: JPMS module-path and layers In-Reply-To: <1589875244.739422859@f415.i.mail.ru> References: <1589875244.739422859@f415.i.mail.ru> Message-ID: <0c0bc7eb-7de6-baa8-a08e-f8b1a12a2f44@oracle.com> On 19/05/2020 09:00, Alex Orlov wrote: > Hi all, > > I want to understand all details of module-path and layers in java9+ and I have two questions: > * As I understand modules on module-path are added automatically only to boot layer and not added automatically to any other layers. I mean, if any child layers are created module-path will be ignored for them. Is this correct? > * Not all modules from module-path are added to boot layer, but only main module and dependent modules. For example, if we have A , B , C , D modules on module-path and A is main module and uses B , B uses C , then D module won't be added to boot layer. Is this correct? > Could anyone help me with these questions? > Have you been through the java.lang.module package description and the APIs for Configuration.resolve? I think the main thing to understand is that A, B, C, and D are observable when doing the module resolution and creating the readability graph for the boot layer. D is not in the readability graph because it's not required by any of the other modules in the graph. Later you will use Configuration.resolve to do module resolution for what will become the child layer. The module finders that you specify to the resolve method will determine if D is observable or not. Depending on the root modules that you specify to resolve, then it might be that D is the readability graph for the child layer. -Alan From sundararajan.athijegannathan at oracle.com Thu May 28 06:14:19 2020 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 28 May 2020 11:44:19 +0530 Subject: RFR 8246034: Remove java.base/share/classes/jdk/internal/jrtfs/jrtfsviewer.js and java.base/share/classes/jdk/internal/jrtfs/jrtls.js Message-ID: <31dc2ed7-91b9-9fce-f0b2-6724da5cacdd@oracle.com> Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8246034 Webrev: http://cr.openjdk.java.net/~sundar/8246034/webrev.00/ Thanks -Sundar From james.laskey at oracle.com Thu May 28 06:43:47 2020 From: james.laskey at oracle.com (James Laskey) Date: Thu, 28 May 2020 03:43:47 -0300 Subject: RFR 8246034: Remove java.base/share/classes/jdk/internal/jrtfs/jrtfsviewer.js and java.base/share/classes/jdk/internal/jrtfs/jrtls.js In-Reply-To: <31dc2ed7-91b9-9fce-f0b2-6724da5cacdd@oracle.com> References: <31dc2ed7-91b9-9fce-f0b2-6724da5cacdd@oracle.com> Message-ID: <43B3B1B8-4448-4D98-8445-F11B491D3A29@oracle.com> +1 ?? > On May 28, 2020, at 3:16 AM, sundararajan.athijegannathan at oracle.com wrote: > > ?Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8246034 > > Webrev: http://cr.openjdk.java.net/~sundar/8246034/webrev.00/ > > Thanks > > -Sundar > From Alan.Bateman at oracle.com Thu May 28 06:58:49 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 May 2020 07:58:49 +0100 Subject: RFR 8246034: Remove java.base/share/classes/jdk/internal/jrtfs/jrtfsviewer.js and java.base/share/classes/jdk/internal/jrtfs/jrtls.js In-Reply-To: <31dc2ed7-91b9-9fce-f0b2-6724da5cacdd@oracle.com> References: <31dc2ed7-91b9-9fce-f0b2-6724da5cacdd@oracle.com> Message-ID: On 28/05/2020 07:14, sundararajan.athijegannathan at oracle.com wrote: > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8246034 > > Webrev: http://cr.openjdk.java.net/~sundar/8246034/webrev.00/ Have you checked if there are any make file configured to copy .js files? Otherwise looks good. -Alan From sundararajan.athijegannathan at oracle.com Thu May 28 07:05:45 2020 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 28 May 2020 12:35:45 +0530 Subject: RFR 8246034: Remove java.base/share/classes/jdk/internal/jrtfs/jrtfsviewer.js and java.base/share/classes/jdk/internal/jrtfs/jrtls.js In-Reply-To: References: <31dc2ed7-91b9-9fce-f0b2-6724da5cacdd@oracle.com> Message-ID: Yes, checked. No config file refers to these .js files. -Sundar On 28/05/20 12:28 pm, Alan Bateman wrote: > On 28/05/2020 07:14, sundararajan.athijegannathan at oracle.com wrote: >> Please review. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8246034 >> >> Webrev: http://cr.openjdk.java.net/~sundar/8246034/webrev.00/ > Have you checked if there are any make file configured to copy .js > files? Otherwise looks good. > > -Alan From sormuras at gmail.com Sat May 30 16:40:53 2020 From: sormuras at gmail.com (Christian Stein) Date: Sat, 30 May 2020 18:40:53 +0200 Subject: jlink 14.0.1 with 100 modules fail Message-ID: Hi, the modular [bach-demo-99] I generated to check my build tool against, failed to create a custom runtime image using jlink via itsToolProvider-based service entry-point. The project consists of 100 module descriptors. No other Java source files (for classes and interfaces) are part of that demo. Each descriptor ball${i}n declares a "requires ball${j}n;" with j set to a number from 0 to i-1 ... in words, all lower modules. javac compiles this project with problems. Arguments passed to jlink (as an array of string) reads: jlink --add-modules ball27n,ball43n,ball88n,[...],ball77n,ball93n --module-path .bach\workspace\modules --output .bach\workspace\image --compress 2 --no-header-files --no-man-pages The error message reads: jdk.internal.org.objectweb.asm.MethodTooLargeException: Method too large: jdk/internal/module/SystemModules$all.moduleDescriptors ()[Ljava/lang/module/ModuleDescriptor; Is there a limitation of supported modules that can be linked? Is the module graph of this conceived project too far out of scope? Shall I open an issue at JBS? Cheers, Christian [ bach-demo-99]: https://github.com/sormuras/bach/blob/master/src/bach/bach-demo-99.jsh From forax at univ-mlv.fr Sat May 30 17:05:44 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 30 May 2020 19:05:44 +0200 (CEST) Subject: jlink 14.0.1 with 100 modules fail In-Reply-To: References: Message-ID: <1292146296.1548141.1590858344228.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Christian Stein" > ?: "jigsaw-dev" > Envoy?: Samedi 30 Mai 2020 18:40:53 > Objet: jlink 14.0.1 with 100 modules fail > Hi, > > the modular [bach-demo-99] I generated to check my build tool > against, failed to create a custom runtime image using jlink > via itsToolProvider-based service entry-point. > > The project consists of 100 module descriptors. No other Java > source files (for classes and interfaces) are part of that demo. > Each descriptor ball${i}n declares a "requires ball${j}n;" with j > set to a number from 0 to i-1 ... in words, all lower modules. > > javac compiles this project with problems. > > Arguments passed to jlink (as an array of string) reads: > > jlink > --add-modules ball27n,ball43n,ball88n,[...],ball77n,ball93n > --module-path .bach\workspace\modules > --output .bach\workspace\image > --compress 2 > --no-header-files > --no-man-pages > > The error message reads: > > jdk.internal.org.objectweb.asm.MethodTooLargeException: Method too large: > jdk/internal/module/SystemModules$all.moduleDescriptors > ()[Ljava/lang/module/ModuleDescriptor; > > Is there a limitation of supported modules that can be linked? It's a bug in the implementation, jlink pre-resolve the module graph and encodes it in a generated classfile. The fact that that classfile can have a method too big was overlooked. > Is the module graph of this conceived project too far out of scope? > > Shall I open an issue at JBS? yes ! > > Cheers, > Christian regards, R?mi > > [ bach-demo-99]: > https://github.com/sormuras/bach/blob/master/src/bach/bach-demo-99.jsh From sormuras at gmail.com Sat May 30 17:10:28 2020 From: sormuras at gmail.com (Christian Stein) Date: Sat, 30 May 2020 19:10:28 +0200 Subject: jlink 14.0.1 with 100 modules fail In-Reply-To: <1292146296.1548141.1590858344228.JavaMail.zimbra@u-pem.fr> References: <1292146296.1548141.1590858344228.JavaMail.zimbra@u-pem.fr> Message-ID: Thanks for the quick response. On Sat, May 30, 2020 at 7:05 PM Remi Forax wrote: > > > Shall I open an issue at JBS? > > yes ! > > Done: https://bugs.openjdk.java.net/browse/JDK-8246197 From Alan.Bateman at oracle.com Sun May 31 06:52:23 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 31 May 2020 07:52:23 +0100 Subject: jlink 14.0.1 with 100 modules fail In-Reply-To: References: Message-ID: On 30/05/2020 17:40, Christian Stein wrote: > Hi, > > the modular [bach-demo-99] I generated to check my build tool > against, failed to create a custom runtime image using jlink > via itsToolProvider-based service entry-point. > > The project consists of 100 module descriptors. No other Java > source files (for classes and interfaces) are part of that demo. > Each descriptor ball${i}n declares a "requires ball${j}n;" with j > set to a number from 0 to i-1 ... in words, all lower modules. > > javac compiles this project with problems. > > Arguments passed to jlink (as an array of string) reads: > > jlink > --add-modules ball27n,ball43n,ball88n,[...],ball77n,ball93n > --module-path .bach\workspace\modules > --output .bach\workspace\image > --compress 2 > --no-header-files > --no-man-pages > > The error message reads: > > jdk.internal.org.objectweb.asm.MethodTooLargeException: Method too large: > jdk/internal/module/SystemModules$all.moduleDescriptors > ()[Ljava/lang/module/ModuleDescriptor; > > Is there a limitation of supported modules that can be linked? > Is the module graph of this conceived project too far out of scope? > > Shall I open an issue at JBS? > Yeah, this is an issue with the jlink system modules plugin where it needs to split the initialization when it results in a method size more than 64k. It it tracked by JDK-8240567. Can you add `--disable-plugin system-modules` to the jlink command as workaround until this is fixed? -Alan From sormuras at gmail.com Sun May 31 15:07:02 2020 From: sormuras at gmail.com (Christian Stein) Date: Sun, 31 May 2020 17:07:02 +0200 Subject: jlink 14.0.1 with 100 modules fail In-Reply-To: References: Message-ID: On Sun, May 31, 2020 at 8:52 AM Alan Bateman wrote: > > > On 30/05/2020 17:40, Christian Stein wrote: > > Hi, > > > > the modular [bach-demo-99] I generated to check my build tool > > against, failed to create a custom runtime image using jlink > > via itsToolProvider-based service entry-point. > > > > The project consists of 100 module descriptors. No other Java > > source files (for classes and interfaces) are part of that demo. > > Each descriptor ball${i}n declares a "requires ball${j}n;" with j > > set to a number from 0 to i-1 ... in words, all lower modules. > > > > javac compiles this project with problems. > > > > Arguments passed to jlink (as an array of string) reads: > > > > jlink > > --add-modules ball27n,ball43n,ball88n,[...],ball77n,ball93n > > --module-path .bach\workspace\modules > > --output .bach\workspace\image > > --compress 2 > > --no-header-files > > --no-man-pages > > > > The error message reads: > > > > jdk.internal.org.objectweb.asm.MethodTooLargeException: Method too large: > > jdk/internal/module/SystemModules$all.moduleDescriptors > > ()[Ljava/lang/module/ModuleDescriptor; > > > > Is there a limitation of supported modules that can be linked? > > Is the module graph of this conceived project too far out of scope? > > > > Shall I open an issue at JBS? > > > Yeah, this is an issue with the jlink system modules plugin where it > needs to split the initialization when it results in a method size more > than 64k. It it tracked by JDK-8240567. Can you add `--disable-plugin > system-modules` to the jlink command as workaround until this is fixed? > Thanks for the heads-up, Alan. Didn't find the issue you linked by a brief search. Working workarounds: - add `--disable-plugin system-modules` works with 100 modules. - use only 90 modules instead of 100 modules as described above. Cheers, Christian From fw at deneb.enyo.de Sun May 31 17:31:48 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 31 May 2020 19:31:48 +0200 Subject: ModuleMainClass attribute via module-info.java Message-ID: <87r1v02epn.fsf@mid.deneb.enyo.de> Is it possible to instruct javac to generate a ModuleMainClass attribute via a module declaration? I can't find the appropriate syntax in the JLS. If there is no way to get javac to generate the attribute, what is the reason for that? From forax at univ-mlv.fr Sun May 31 21:35:05 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 31 May 2020 23:35:05 +0200 (CEST) Subject: ModuleMainClass attribute via module-info.java In-Reply-To: <87r1v02epn.fsf@mid.deneb.enyo.de> References: <87r1v02epn.fsf@mid.deneb.enyo.de> Message-ID: <64199231.5886.1590960905521.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Florian Weimer" > ?: "jigsaw-dev" > Envoy?: Dimanche 31 Mai 2020 19:31:48 > Objet: ModuleMainClass attribute via module-info.java > Is it possible to instruct javac to generate a ModuleMainClass > attribute via a module declaration? I can't find the appropriate > syntax in the JLS. If there is no way to get javac to generate the > attribute, what is the reason for that? Hi Florian, the design of JPMS separates what is useful for Java described by the module-info.java (required modules, exported or open packages, etc) and what is metadata for distribution (module version, module main, modules hashes, etc) stored as supplementary attributes (or optional fields of the Module attribute) in the module-info.class. Changing the main class or the version of a module do not require a recompilation, so those information are not handled by javac but injected into the module-info.class by jar, because those information are useful only when you want to create a jar in order to distribute it. We came to that design to be able to support already existing ways of packaging the metadata associated with a jar file so a jar can be at the same time a module for JPMS and also a module for Jboss module or an OSGI bundle, etc. As an example of metadata fusion, you can use a tool like bnd [1], a tool developed originally to package OSGI bundles, if you want to use a Java annotation to specify the main class. regards, R?mi [1] https://bnd.bndtools.org/chapters/330-jpms.html