From forax at univ-mlv.fr Sun Feb 4 11:30:13 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 4 Feb 2018 12:30:13 +0100 (CET) Subject: OpenJDK 10 and Oracle JDK10 doesn't have the same default modules Message-ID: <630514155.1872491.1517743813646.JavaMail.zimbra@u-pem.fr> Hi all, it seems that the OpenJDK 10 and OracleJDK 10 doest not declare the same set of default modules, so java --add-modules ALL-DEFAULT do not behave the same way :( With Oracle JDK 10 b42, module java.scripting is part of the default modules https://travis-ci.org/sormuras/beautiful_logger/jobs/337153634 With Oracle JDK 10 b42, module java.scripting is NOT part of the default modules, so javax/script/ScriptException is not found https://travis-ci.org/sormuras/beautiful_logger/jobs/337153635 Should not ALL-DEFAULT mean the same set of default modules for a JDK release ? cheers, R?mi From Alan.Bateman at oracle.com Sun Feb 4 12:38:53 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 4 Feb 2018 12:38:53 +0000 Subject: OpenJDK 10 and Oracle JDK10 doesn't have the same default modules In-Reply-To: <630514155.1872491.1517743813646.JavaMail.zimbra@u-pem.fr> References: <630514155.1872491.1517743813646.JavaMail.zimbra@u-pem.fr> Message-ID: On 04/02/2018 11:30, Remi Forax wrote: > Hi all, > it seems that the OpenJDK 10 and OracleJDK 10 doest not declare the same set of default modules, so java --add-modules ALL-DEFAULT do not behave the same way :( > > With Oracle JDK 10 b42, module java.scripting is part of the default modules > https://travis-ci.org/sormuras/beautiful_logger/jobs/337153634 > > With Oracle JDK 10 b42, module java.scripting is NOT part of the default modules, > so javax/script/ScriptException is not found > https://travis-ci.org/sormuras/beautiful_logger/jobs/337153635 > > Should not ALL-DEFAULT mean the same set of default modules for a JDK release ? > These Travis jobs seem to be using ALL-MODULE-PATH (not ALL-DEFAULT) so I don't think this is anything to do with the set of modules to resolve when running code on the class path. The NCFE appears to thrown by code in module org.junit.juniter.engine. If this an explicit module and it contains code with a reference to a class in java.scripting then it needs `requires java.scripting`, otherwise it will not compile or tun. Maybe it's an automatic module and so needs --add-modules to resolves the modules it depends on? -Alan From sormuras at gmail.com Sun Feb 4 12:45:59 2018 From: sormuras at gmail.com (Christian Stein) Date: Sun, 4 Feb 2018 13:45:59 +0100 Subject: OpenJDK 10 and Oracle JDK10 doesn't have the same default modules In-Reply-To: References: <630514155.1872491.1517743813646.JavaMail.zimbra@u-pem.fr> Message-ID: On Sun, Feb 4, 2018 at 1:38 PM, Alan Bateman wrote: > On 04/02/2018 11:30, Remi Forax wrote: > >> Hi all, >> it seems that the OpenJDK 10 and OracleJDK 10 doest not declare the same >> set of default modules, so java --add-modules ALL-DEFAULT do not behave the >> same way :( >> >> With Oracle JDK 10 b42, module java.scripting is part of the default >> modules >> https://travis-ci.org/sormuras/beautiful_logger/jobs/337153634 >> >> With Oracle JDK 10 b42, module java.scripting is NOT part of the default >> modules, >> so javax/script/ScriptException is not found >> https://travis-ci.org/sormuras/beautiful_logger/jobs/337153635 >> >> Should not ALL-DEFAULT mean the same set of default modules for a JDK >> release ? >> >> These Travis jobs seem to be using ALL-MODULE-PATH (not ALL-DEFAULT) so I > don't think this is anything to do with the set of modules to resolve when > running code on the class path. > > The NCFE appears to thrown by code in module org.junit.juniter.engine. If > this an explicit module and it contains code with a reference to a class in > java.scripting then it needs `requires java.scripting`, otherwise it will > not compile or tun. Maybe it's an automatic module and so needs > --add-modules to resolves the modules it depends on? > > > It's an automatic module. And it does run "as-is" on Oracle JDK, using ALL-MODULE-PATH. Here is the actual command: java --module-path bin/bach/target/classes/test:bin/bach/modules --add-modules ALL-MODULE-PATH --module org.junit.platform.console --scan-modules Perhaps the interpretation of " ALL-MODULE-PATH " by Oracle JDK is too generous, as it add all system modules as well? From org.openjdk at io7m.com Sun Feb 4 13:31:45 2018 From: org.openjdk at io7m.com (Mark Raynsford) Date: Sun, 4 Feb 2018 13:31:45 +0000 Subject: Module resource as seekable byte channel? Message-ID: <20180204133145.43b02a91@copperhead.int.arc7.info> Hello. I'm working on a problem that would seem to require accessing a (large) resource included inside a module in random manner. More specifically, I have some large audio resources inside a module and need to be able to get something analogous to a SeekableByteChannel for a given resource so that I can stream the audio and seek forwards/backwards. I could unpack the resources to the filesystem, but I'd prefer not to do this (because that would then mean I'm using double the amount of storage). Is there some way to get access to a module resource as a SeekableByteChannel in the standard library? -- Mark Raynsford | http://www.io7m.com From Alan.Bateman at oracle.com Sun Feb 4 13:39:12 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 4 Feb 2018 13:39:12 +0000 Subject: OpenJDK 10 and Oracle JDK10 doesn't have the same default modules In-Reply-To: References: <630514155.1872491.1517743813646.JavaMail.zimbra@u-pem.fr> Message-ID: <340a377b-cf27-feeb-ceb5-249ce716d792@oracle.com> On 04/02/2018 12:45, Christian Stein wrote: > : > > It's an automatic module. And it does run "as-is" on Oracle JDK, > using?ALL-MODULE-PATH. > > Here is the actual command: > > java > --module-path > ? bin/bach/target/classes/test:bin/bach/modules > --add-modules > ? ALL-MODULE-PATH > --module > ? org.junit.platform.console > --scan-modules > > > Perhaps the interpretation of " ALL-MODULE-PATH " by Oracle JDK is too > generous, as it add all system modules as well? > No, there is no difference there. The main difference between Oracle JDK and OpenJDK builds is that the Oracle JDK builds have additional modules and specifically the modules for the Java Plugin, Java Web Start, and the the JavaFX modules from the OpenJFX project. If you diff the `java --list-modules` output from both builds then you'll see the list of additional modules. I suspect this issue is nothing to do with `--add-modules ALL-MODULE-PATH`. Instead it's probably one of the JavaFX modules that `requires java.scripting`. You should be able to diagnose this quickly by running with `--show-module-resolution` and grep the output for "java.scripting". -Alan From sormuras at gmail.com Sun Feb 4 14:58:53 2018 From: sormuras at gmail.com (Christian Stein) Date: Sun, 4 Feb 2018 15:58:53 +0100 Subject: OpenJDK 10 and Oracle JDK10 doesn't have the same default modules In-Reply-To: <340a377b-cf27-feeb-ceb5-249ce716d792@oracle.com> References: <630514155.1872491.1517743813646.JavaMail.zimbra@u-pem.fr> <340a377b-cf27-feeb-ceb5-249ce716d792@oracle.com> Message-ID: On Sun, Feb 4, 2018 at 2:39 PM, Alan Bateman wrote: > [...] > I suspect this issue is nothing to do with `--add-modules > ALL-MODULE-PATH`. Instead it's probably one of the JavaFX modules that > `requires java.scripting`. You should be able to diagnose this quickly by > running with `--show-module-resolution` and grep the output for > "java.scripting". > > -Alan > It's module ' jdk.deploy' in Oracle JDK: [...] jdk.deploy requires java.scripting jrt:/java.scripting [...] https://travis-ci.org/sormuras/beautiful_logger/jobs/337219688#L660 OpenJDK does not ... deploy that one: https://travis-ci.org/sormuras/beautiful_logger/jobs/337219689#L587 From sormuras at gmail.com Sun Feb 4 15:32:23 2018 From: sormuras at gmail.com (Christian Stein) Date: Sun, 4 Feb 2018 16:32:23 +0100 Subject: OpenJDK 10 and Oracle JDK10 doesn't have the same default modules In-Reply-To: <340a377b-cf27-feeb-ceb5-249ce716d792@oracle.com> References: <630514155.1872491.1517743813646.JavaMail.zimbra@u-pem.fr> <340a377b-cf27-feeb-ceb5-249ce716d792@oracle.com> Message-ID: I solved the issue by also adding "ALL-DEFAULT" to the "--add-module" option. Now both JDK runtimes are happily executing JUnit 5 tests on the module path. java --module-path bin/bach/target/classes/test:bin/bach/modules --add-modules ALL-MODULE-PATH,ALL-DEFAULT --module org.junit.platform.console --scan-modules https://travis-ci.org/sormuras/beautiful_logger/builds/337224349 Hoping, that we soon my switch to explicit module descriptors. Perhaps using MR-JARs. Thanks for the help, Alan! Cheers, Christian On Sun, Feb 4, 2018 at 2:39 PM, Alan Bateman wrote: > On 04/02/2018 12:45, Christian Stein wrote: > > : > > It's an automatic module. And it does run "as-is" on Oracle JDK, > using ALL-MODULE-PATH. > > Here is the actual command: > > java > --module-path > bin/bach/target/classes/test:bin/bach/modules > --add-modules > ALL-MODULE-PATH > --module > org.junit.platform.console > --scan-modules > > > Perhaps the interpretation of " ALL-MODULE-PATH " by Oracle JDK is too > generous, as it add all system modules as well? > > No, there is no difference there. The main difference between Oracle JDK > and OpenJDK builds is that the Oracle JDK builds have additional modules > and specifically the modules for the Java Plugin, Java Web Start, and the > the JavaFX modules from the OpenJFX project. If you diff the `java > --list-modules` output from both builds then you'll see the list of > additional modules. > > I suspect this issue is nothing to do with `--add-modules > ALL-MODULE-PATH`. Instead it's probably one of the JavaFX modules that > `requires java.scripting`. You should be able to diagnose this quickly by > running with `--show-module-resolution` and grep the output for > "java.scripting". > > -Alan > From Alan.Bateman at oracle.com Sun Feb 4 20:24:11 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 4 Feb 2018 20:24:11 +0000 Subject: OpenJDK 10 and Oracle JDK10 doesn't have the same default modules In-Reply-To: References: <630514155.1872491.1517743813646.JavaMail.zimbra@u-pem.fr> <340a377b-cf27-feeb-ceb5-249ce716d792@oracle.com> Message-ID: <9590e748-d2fb-ce6a-a5b6-2464a5d83ea0@oracle.com> On 04/02/2018 14:58, Christian Stein wrote: > : > > It's module ' jdk.deploy' in Oracle JDK: > > [...] > jdk.deploy requires java.scripting jrt:/java.scripting > [...] > > https://travis-ci.org/sormuras/beautiful_logger/jobs/337219688#L660 > > > OpenJDK does not ... deploy that one: > https://travis-ci.org/sormuras/beautiful_logger/jobs/337219689#L587 > jdk.deploy is a supporting module for the Java Plugin and Java Web Start so this is why it's not in OpenJDK builds. The jdk.deploy module is being resolved because includes a security provider (`provides java.security.Provider with ...`) and java.base `uses java.security.Provider`. I see your other mail where you have found a workaround for this specific issue. The more general issue is of course that you are deploying a module that does not know what modules it depends. In these cases you have to help the module system by specifying --add-modules to force the modules that it depends on to be resolved. You got lucky with the Oracle JDK build because jdk.deploy pulled in the java.scripting module. -Alan From Alan.Bateman at oracle.com Sun Feb 4 20:41:48 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 4 Feb 2018 20:41:48 +0000 Subject: Module resource as seekable byte channel? In-Reply-To: <20180204133145.43b02a91@copperhead.int.arc7.info> References: <20180204133145.43b02a91@copperhead.int.arc7.info> Message-ID: <41267343-3ef5-cfcf-fadc-94190f988621@oracle.com> On 04/02/2018 13:31, Mark Raynsford wrote: > Hello. > > I'm working on a problem that would seem to require accessing a > (large) resource included inside a module in random manner. More > specifically, I have some large audio resources inside a module and > need to be able to get something analogous to a SeekableByteChannel > for a given resource so that I can stream the audio and seek > forwards/backwards. > > I could unpack the resources to the filesystem, but I'd prefer not to > do this (because that would then mean I'm using double the amount of > storage). > > Is there some way to get access to a module resource as a > SeekableByteChannel in the standard library? > The only support for random access is in the ModuleReader API where the read method returns a ByteBuffer containing the resource. This is very efficient for resources in modules that are linked into the runtime image as it's essentially a slice of a memory mapped region. It's not efficient for modules that are packaged as JAR files as random access poses challenges there (esp. when entries in JAR file are compressed). -Alan From org.openjdk at io7m.com Mon Feb 5 17:08:06 2018 From: org.openjdk at io7m.com (Mark Raynsford) Date: Mon, 5 Feb 2018 17:08:06 +0000 Subject: Module resource as seekable byte channel? In-Reply-To: <41267343-3ef5-cfcf-fadc-94190f988621@oracle.com> References: <20180204133145.43b02a91@copperhead.int.arc7.info> <41267343-3ef5-cfcf-fadc-94190f988621@oracle.com> Message-ID: <20180205170806.04e309bc@copperhead.int.arc7.info> On 2018-02-04T20:41:48 +0000 Alan Bateman wrote: > > The only support for random access is in the ModuleReader API where the > read method returns a ByteBuffer containing the resource. This is very > efficient for resources in modules that are linked into the runtime > image as it's essentially a slice of a memory mapped region. It's not > efficient for modules that are packaged as JAR files as random access > poses challenges there (esp. when entries in JAR file are compressed). OK, thanks, that's what I suspected. I decided I could probably get away with simply being able to restart streams rather than seeking backwards. Implementing this turned out to be as trivial as opening the resource twice yielding streams A and B, playing from stream A until EOF, and then playing from stream B (whilst opening stream C in the background to act as the new stream A when B reaches EOF). It uses a constant amount of storage (the fixed-size read buffer per-stream) and doesn't seem to consume any extra file descriptors (because the JVM is obviously just reading bytes from a ZipEntry that it already has open behind the scenes). -- Mark Raynsford | http://www.io7m.com From scolebourne at joda.org Wed Feb 7 14:23:15 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 7 Feb 2018 14:23:15 +0000 Subject: ClassLoader.getResources(String) Message-ID: I've been trying to use ClassLoader.getResources(String). The entire application is in one named module, this includes the code that invokes the ClassLoader method and the resource that it is trying to find. The Javadoc says: "Resources in named modules are subject to the encapsulation rules specified by Module.getResourceAsStream. Additionally, and except for the special case where the resource has a name ending with ".class", this method will only find resources in packages of named modules when the package is opened unconditionally (even if the caller of this method is in the same module as the resource)." https://docs.oracle.com/javase/9/docs/api/java/lang/ClassLoader.html#getResources-java.lang.String- The call to ClassLoader.getResources(String) does not find the resource. I assume that this is because of the last clause in the spec "even if the caller of this method is in the same module as the resource". But I can't for the life of me think why such a difficult to meet restriction has been added. The only way around it is to make the package open, which is far from ideal. If its all within one module, applying an access restriction like this is just unhelpful. Stephen From Alan.Bateman at oracle.com Wed Feb 7 16:35:14 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 7 Feb 2018 16:35:14 +0000 Subject: ClassLoader.getResources(String) In-Reply-To: References: Message-ID: On 07/02/2018 14:23, Stephen Colebourne wrote: > I've been trying to use ClassLoader.getResources(String). The entire > application is in one named module, this includes the code that > invokes the ClassLoader method and the resource that it is trying to > find. Can you summarize what you are trying to do? If this is code in a module trying to locate one of its own resources then Class.getResourceXXX or Module.getResourcAsStream are the candidate APIs to use (not ClassLoader.getResourceXXX as that can never locate resources that are encapsulated). -Alan From scolebourne at joda.org Wed Feb 7 16:56:55 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 7 Feb 2018 16:56:55 +0000 Subject: ClassLoader.getResources(String) In-Reply-To: References: Message-ID: On 7 February 2018 at 16:35, Alan Bateman wrote: > On 07/02/2018 14:23, Stephen Colebourne wrote: >> >> I've been trying to use ClassLoader.getResources(String). The entire >> application is in one named module, this includes the code that >> invokes the ClassLoader method and the resource that it is trying to >> find. > > Can you summarize what you are trying to do? If this is code in a module > trying to locate one of its own resources then Class.getResourceXXX or > Module.getResourcAsStream are the candidate APIs to use (not > ClassLoader.getResourceXXX as that can never locate resources that are > encapsulated). I was using maven to create a jar-with-dependencies file, so I could use jlink. With all the code in one jar file, there shouldn't be any access barriers to worry about. ClassLoader.getResources(String) worked just fine until Java 9. The two APIs are not comparable - the ClassLoader one returns all URLs found, whereas the Class one returns just one URL. Switching API would change behaviour. The code can be seen here: https://github.com/OpenGamma/Strata/blob/master/modules/collect/src/main/java/com/opengamma/strata/collect/io/ResourceConfig.java#L242 It is a core part of the system that loads configuration at startup. thanks Stephen From Alan.Bateman at oracle.com Wed Feb 7 20:11:38 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 7 Feb 2018 20:11:38 +0000 Subject: ClassLoader.getResources(String) In-Reply-To: References: Message-ID: <0d7c3dcd-8e19-5b4e-fe18-79d80652a7a2@oracle.com> On 07/02/2018 16:56, Stephen Colebourne wrote: > : > I was using maven to create a jar-with-dependencies file, so I could > use jlink. With all the code in one jar file, there shouldn't be any > access barriers to worry about. > > ClassLoader.getResources(String) worked just fine until Java 9. The > two APIs are not comparable - the ClassLoader one returns all URLs > found, whereas the Class one returns just one URL. Switching API would > change behaviour. ClassLoader.getResources searches the class path as it did in JDK 9 and older, it it just can't locate non-".class" resources in modules when they are encapsulated. Class loaders are oblivious as to who is ultimately attempting to load a class or locate a resource (the initiating and defining loader can be different, they can many class loaders in the delegation chain). With the uber modular JAR scenario then all classes for several libraries are in the same module. This means that the names of resources in that module are unique. If several libraries have the same resource then I assume you drop all but one when you create this uber JAR (or maybe you are merging some of the configuration files, I can't tell). So I assume you could change this code to use Class.getResource and it will locate at-most-one resource with a specific name. To do a proper migration means re-examining ResourceConfig of course. Using services is likely to be a lot cleaner and more robust than scanning for configuration files. -Alan From mvala at redhat.com Fri Feb 9 15:23:29 2018 From: mvala at redhat.com (Michal Vala) Date: Fri, 9 Feb 2018 16:23:29 +0100 Subject: RFR JDK-8170114 jimage extract to not an empty directory overwrites content of the directory Message-ID: <139c1eee-f026-da7c-4925-ef2f5c2d9dda@redhat.com> Hi, sending fix for jimage bug JDK-8170114[1]. I'm not sure whether this is correct list. If it is not, please direct me somewhere else. I don't have an openjdk account, so webrev is on my fedora public space. I will need a sponsor for this. webrev: https://michalvala.fedorapeople.org/webrevs/JDK-8170114/webrev.00/webrev/ Patch validates output directory before any jimage extracting happen. I've moved validation to extra private method as it is few lines of code. I've also added proper error message for case when output path is not a directory (JImageTask.java#449). I've implemented beforeTest method, that cleans cwd. This must be done because files were extracted to cwd and constantly overwriting and tests were non-deterministic (order did matter). Plus some tests added. I want to fix JDK-8170120 with IOException when file is not an jimage. It is blocked by this. This will fix 3 now problematic and excluded tests. [1] - https://bugs.openjdk.java.net/browse/JDK-8170114 -- Michal Vala OpenJDK QE Red Hat Czech From Alan.Bateman at oracle.com Fri Feb 9 15:38:09 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Feb 2018 15:38:09 +0000 Subject: RFR JDK-8170114 jimage extract to not an empty directory overwrites content of the directory In-Reply-To: <139c1eee-f026-da7c-4925-ef2f5c2d9dda@redhat.com> References: <139c1eee-f026-da7c-4925-ef2f5c2d9dda@redhat.com> Message-ID: <91c35b21-9875-e119-0fd9-9fe411a4145a@oracle.com> On 09/02/2018 15:23, Michal Vala wrote: > Hi, > > sending fix for jimage bug JDK-8170114[1]. I'm not sure whether this > is correct list. If it is not, please direct me somewhere else. > > I don't have an openjdk account, so webrev is on my fedora public > space. I will need a sponsor for this. > > webrev: > https://michalvala.fedorapeople.org/webrevs/JDK-8170114/webrev.00/webrev/ Do you have any buddies in Java team in Red Hat that you publish this on cr.openjdk.java.net? We can't look at/accept contributions that are published on non-OpenJDK infrastructure. If you don't then can you include the patch in a mail. -Alan From gnu.andrew at redhat.com Fri Feb 9 17:27:28 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 9 Feb 2018 17:27:28 +0000 Subject: RFR JDK-8170114 jimage extract to not an empty directory overwrites content of the directory In-Reply-To: <91c35b21-9875-e119-0fd9-9fe411a4145a@oracle.com> References: <139c1eee-f026-da7c-4925-ef2f5c2d9dda@redhat.com> <91c35b21-9875-e119-0fd9-9fe411a4145a@oracle.com> Message-ID: On 9 February 2018 at 15:38, Alan Bateman wrote: > On 09/02/2018 15:23, Michal Vala wrote: >> >> Hi, >> >> sending fix for jimage bug JDK-8170114[1]. I'm not sure whether this is >> correct list. If it is not, please direct me somewhere else. >> >> I don't have an openjdk account, so webrev is on my fedora public space. I >> will need a sponsor for this. >> >> webrev: >> https://michalvala.fedorapeople.org/webrevs/JDK-8170114/webrev.00/webrev/ > > Do you have any buddies in Java team in Red Hat that you publish this on > cr.openjdk.java.net? We can't look at/accept contributions that are > published on non-OpenJDK infrastructure. If you don't then can you include > the patch in a mail. > > -Alan http://cr.openjdk.java.net/~shade/8170114/webrev.01/ FWIW, it looks like a pretty straight-forward fix to me. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From mvala at redhat.com Fri Feb 9 18:09:54 2018 From: mvala at redhat.com (Michal Vala) Date: Fri, 9 Feb 2018 19:09:54 +0100 Subject: Fwd: RFR JDK-8170114 jimage extract to not an empty directory overwrites content of the directory In-Reply-To: References: <139c1eee-f026-da7c-4925-ef2f5c2d9dda@redhat.com> <91c35b21-9875-e119-0fd9-9fe411a4145a@oracle.com> Message-ID: ah, accidentally replied just to Alan :/ Here it is ---------- Forwarded message ---------- From: Michal Vala Date: Fri, Feb 9, 2018 at 6:21 PM Subject: Re: RFR JDK-8170114 jimage extract to not an empty directory overwrites content of the directory To: Alan Bateman sure, here it is http://cr.openjdk.java.net/~shade/8170114/webrev.01/ On Fri, Feb 9, 2018 at 4:38 PM, Alan Bateman wrote: > On 09/02/2018 15:23, Michal Vala wrote: >> >> Hi, >> >> sending fix for jimage bug JDK-8170114[1]. I'm not sure whether this is >> correct list. If it is not, please direct me somewhere else. >> >> I don't have an openjdk account, so webrev is on my fedora public space. I >> will need a sponsor for this. >> >> webrev: >> https://michalvala.fedorapeople.org/webrevs/JDK-8170114/webrev.00/webrev/ > > Do you have any buddies in Java team in Red Hat that you publish this on > cr.openjdk.java.net? We can't look at/accept contributions that are > published on non-OpenJDK infrastructure. If you don't then can you include > the patch in a mail. > > -Alan From mandy.chung at oracle.com Sat Feb 10 00:04:13 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 9 Feb 2018 16:04:13 -0800 Subject: RFR JDK-8170114 jimage extract to not an empty directory overwrites content of the directory In-Reply-To: <139c1eee-f026-da7c-4925-ef2f5c2d9dda@redhat.com> References: <139c1eee-f026-da7c-4925-ef2f5c2d9dda@redhat.com> Message-ID: On 2/9/18 7:23 AM, Michal Vala wrote: > > Patch validates output directory before any jimage extracting happen. > I've moved validation to extra private method as it is few lines of > code. I've also added proper error message for case when output path > is not a directory (JImageTask.java#449). > Thanks for looking at JDK-8170114 and JDK-8170120.? I took a look at? http://cr.openjdk.java.net/~shade/8170114/webrev.01/ Alternatively,? jimage extract can behave as jlink and it fails if the specified output directory exists including empty directory. It'd be easy to delete the directory in the command-line before running jimage. You extend JImageCliTest to handle the beforeTest method to be invoked before running each test case.? Is that necessary?? The test itself is creating temp file/directory for each test case.??? I think it'd be good to update the test to create a named file/dir under the scratch area as jtreg will take care of cleaning the scratch area. Mandy From Alan.Bateman at oracle.com Sat Feb 10 10:25:05 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 10 Feb 2018 10:25:05 +0000 Subject: RFR JDK-8170114 jimage extract to not an empty directory overwrites content of the directory In-Reply-To: References: <139c1eee-f026-da7c-4925-ef2f5c2d9dda@redhat.com> Message-ID: <70485fc9-e394-458d-ba39-8fd3abb23996@oracle.com> On 10/02/2018 00:04, mandy chung wrote: > On 2/9/18 7:23 AM, Michal Vala wrote: >> >> Patch validates output directory before any jimage extracting happen. >> I've moved validation to extra private method as it is few lines of >> code. I've also added proper error message for case when output path >> is not a directory (JImageTask.java#449). >> > > Thanks for looking at JDK-8170114 and JDK-8170120.? I took a look at? > http://cr.openjdk.java.net/~shade/8170114/webrev.01/ Yes, thanks for looking at these issues. For `jimage info ` issue then jimage correctly fails (with a non-zero status) but the IOException isn't converted into an error message as it does with other errors. Yes, it would be good to fix that. I think the `jimage extract --dir ` scenario needs discussion. If is a non-directory file then jimage has to fail, I don't expect disagreement on that. For the case where it is an existing directory then the options seem to be: 1. Extract into the existing directory (existing JDK 9 and JDK 10 behavior) 2. Fail if it's not empty (your patch) 3. Fail if it exists (Mandy's mail, the motivation being to keep it consistent with jlink) I view `jimage extract --dir ` as being similar to `unzip -d ` so I don't think existing behavior (#1) is incorrect, the only issue is that it silently overrides files whereas unzip will prompt before overriding (unless you specify -o). The `jar` tool, and legacy `tar` tool side with `jimage` and are happy to silently replace existing files. What would you think about focusing on the override case instead of disallowing extracting into an existing non-empty directory? I realize this is more work as it means deciding on whether to prompt, warn or fail. It also means thinking about the equivalent of unzip -o to allowing existing files be replaced. -Alan From nipa at codefx.org Sun Feb 11 15:31:21 2018 From: nipa at codefx.org (Nicolai Parlog) Date: Sun, 11 Feb 2018 16:31:21 +0100 Subject: Loading resource bundles across module boundaries Message-ID: <3f2810c8-be9a-5792-3666-78e76a2462ec@codefx.org> Hi! The ResourceBundle Javadoc[1] says: > * Code in a named module that calls getBundle(String, Locale) > will locate resource bundles in the caller's module (caller module). > * If resource bundles are deployed in named modules separate from the > caller module, those resource bundles need to be loaded from service > providers of ResourceBundleProvider. I interpreted this to mean that, without registering services, named modules can only load bundles from themselves. But in my experiments I could also load resource bundles from other modules as long as the package containing them was open. Did I make a mistake? Did I misinterpret the Javadoc? Is that behavior buggy? so long ... Nicolai [1] https://docs.oracle.com/javase/9/docs/api/java/util/ResourceBundle.html -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From Alan.Bateman at oracle.com Sun Feb 11 20:48:38 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 11 Feb 2018 20:48:38 +0000 Subject: Loading resource bundles across module boundaries In-Reply-To: <3f2810c8-be9a-5792-3666-78e76a2462ec@codefx.org> References: <3f2810c8-be9a-5792-3666-78e76a2462ec@codefx.org> Message-ID: <7c80c1a8-8b9b-9b52-bd6f-0956d5cbde31@oracle.com> On 11/02/2018 15:31, Nicolai Parlog wrote: > : > I interpreted this to mean that, without registering services, named > modules can only load bundles from themselves. But in my experiments I > could also load resource bundles from other modules as long as the > package containing them was open. > > Did I make a mistake? Did I misinterpret the Javadoc? Is that behavior > buggy? > The behavior is correct but isn't clearly covered in the Java SE 9 javadoc. Mandy has improved the javadoc for Java SE 10 [1] so it's much clearer and covers all the scenarios. -Alan [1] https://download.java.net/java/jdk10/docs/api/java/util/ResourceBundle.html From mvala at redhat.com Mon Feb 12 06:57:36 2018 From: mvala at redhat.com (Michal Vala) Date: Mon, 12 Feb 2018 07:57:36 +0100 Subject: RFR JDK-8170114 jimage extract to not an empty directory overwrites content of the directory In-Reply-To: References: <139c1eee-f026-da7c-4925-ef2f5c2d9dda@redhat.com> Message-ID: On 02/10/2018 01:04 AM, mandy chung wrote: > On 2/9/18 7:23 AM, Michal Vala wrote: >> >> Patch validates output directory before any jimage extracting happen. I've >> moved validation to extra private method as it is few lines of code. I've also >> added proper error message for case when output path is not a directory >> (JImageTask.java#449). >> > > Thanks for looking at JDK-8170114 and JDK-8170120.? I took a look at > http://cr.openjdk.java.net/~shade/8170114/webrev.01/ > > Alternatively,? jimage extract can behave as jlink and it fails if the specified > output directory exists including empty directory. It'd be easy to delete the > directory in the command-line before running jimage. > > You extend JImageCliTest to handle the beforeTest method to be invoked before > running each test case.? Is that necessary?? The test itself is creating temp > file/directory for each test case.??? I think it'd be good to update the test to > create a named file/dir under the scratch area as jtreg will take care of > cleaning the scratch area. It's because of extract tests without specifying --dir (extract to cwd). AFAIK you can't correctly change cwd in runtime, so calling a test method in context of different cwd is not an option. Thus we need an empty scratch area for those. Alternatively we can clean cwd explicitly just before these tests, instead of before each test method. > > Mandy > > -- Michal Vala OpenJDK QE Red Hat Czech From mvala at redhat.com Mon Feb 12 07:10:46 2018 From: mvala at redhat.com (Michal Vala) Date: Mon, 12 Feb 2018 08:10:46 +0100 Subject: RFR JDK-8170114 jimage extract to not an empty directory overwrites content of the directory In-Reply-To: <70485fc9-e394-458d-ba39-8fd3abb23996@oracle.com> References: <139c1eee-f026-da7c-4925-ef2f5c2d9dda@redhat.com> <70485fc9-e394-458d-ba39-8fd3abb23996@oracle.com> Message-ID: <2f9257fb-f7b5-8f5b-8176-a888cfe01ec1@redhat.com> On 02/10/2018 11:25 AM, Alan Bateman wrote: > > > On 10/02/2018 00:04, mandy chung wrote: >> On 2/9/18 7:23 AM, Michal Vala wrote: >>> >>> Patch validates output directory before any jimage extracting happen. I've >>> moved validation to extra private method as it is few lines of code. I've >>> also added proper error message for case when output path is not a directory >>> (JImageTask.java#449). >>> >> >> Thanks for looking at JDK-8170114 and JDK-8170120.? I took a look at >> http://cr.openjdk.java.net/~shade/8170114/webrev.01/ > Yes, thanks for looking at these issues. > > For `jimage info ` issue then jimage correctly fails (with a > non-zero status) but the IOException isn't converted into an error message as it > does with other errors. Yes, it would be good to fix that. > > I think the `jimage extract --dir ` scenario needs > discussion. If is a non-directory file then jimage has to fail, > I don't expect disagreement on that. For the case where it is an existing > directory then the options seem to be: > > 1. Extract into the existing directory (existing JDK 9 and JDK 10 behavior) > 2. Fail if it's not empty (your patch) > 3. Fail if it exists (Mandy's mail, the motivation being to keep it consistent > with jlink) > > I view `jimage extract --dir ` as being similar to `unzip -d ` so I > don't think existing behavior (#1) is incorrect, the only issue is that it > silently overrides files whereas unzip will prompt before overriding (unless you > specify -o). The `jar` tool, and legacy `tar` tool side with `jimage` and are > happy to silently replace existing files. > > What would you think about focusing on the override case instead of disallowing > extracting into an existing non-empty directory? I realize this is more work as > it means deciding on whether to prompt, warn or fail. It also means thinking > about the equivalent of unzip -o to allowing existing files be replaced. Unzip prompts user for individual files and I'm not sure whether it's a good option here. Maybe prompt user at the beginning that directory is not empty and there is a risk that files there might be overwritten continue y/n? -- Michal Vala OpenJDK QE Red Hat Czech From org.openjdk at io7m.com Mon Feb 12 11:44:07 2018 From: org.openjdk at io7m.com (Mark Raynsford) Date: Mon, 12 Feb 2018 11:44:07 +0000 Subject: Signing jlink code for macOS on other platforms Message-ID: <20180212114407.2d39e442@copperhead.int.arc7.info> Hello! As a long time Java developer, I've only ever had to deal with signing jar files. I can obviously sign jar files once on whatever platform I choose to use to build the code, and then distribute the jars to all platforms. Build once, run everywhere, etc. However, now that jlink exists, as a developer I have to deal with signing platform-specific executables. For example, if I distribute a macOS application produced with jlink, that executable will produce a large warning message: http://ataxia.io7m.com/2018/02/12/warning.png Now obviously in the past, the system JRE was signed and so I'd give my users a jar file, they'd run the jar file using the signed JRE, and everything would work. With jlink, it's now my responsibility to sign the executables I produce. The code signing tools for macOS are evidently not available for any platform other than macOS, meaning that I now can't just build the code for all platforms on Linux if I want to use jlink (even though jlink is capable of producing embedded JREs for all of the platforms I want to support); at least part of the build would have to take place on macOS to sign the final result. This is pretty awful! Are there any plans to implement anything that's capable of signing macOS binaries and resources in a platform-independent way so that jlink-produced distributions can work without warnings? Is that even a reasonable thing to request? I've no idea how "private" Apple keep their signing implementation. -- Mark Raynsford | http://www.io7m.com From nipa at codefx.org Mon Feb 12 14:30:16 2018 From: nipa at codefx.org (Nicolai Parlog) Date: Mon, 12 Feb 2018 15:30:16 +0100 Subject: Loading resource bundles across module boundaries In-Reply-To: <7c80c1a8-8b9b-9b52-bd6f-0956d5cbde31@oracle.com> References: <3f2810c8-be9a-5792-3666-78e76a2462ec@codefx.org> <7c80c1a8-8b9b-9b52-bd6f-0956d5cbde31@oracle.com> Message-ID: No matter what I do, there's always one document I didn't look at. :/ As usual, thank you very much! On 11.02.2018 21:48, Alan Bateman wrote: > > > On 11/02/2018 15:31, Nicolai Parlog wrote: >> : >> I interpreted this to mean that, without registering services, named >> modules can only load bundles from themselves. But in my experiments I >> could also load resource bundles from other modules as long as the >> package containing them was open. >> >> Did I make a mistake? Did I misinterpret the Javadoc? Is that behavior >> buggy? >> > The behavior is correct but isn't clearly covered in the Java SE 9 > javadoc. Mandy has improved the javadoc for Java SE 10 [1] so it's much > clearer and covers all the scenarios. > > -Alan > > [1] > https://download.java.net/java/jdk10/docs/api/java/util/ResourceBundle.html > -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From nipa at codefx.org Mon Feb 12 14:52:12 2018 From: nipa at codefx.org (Nicolai Parlog) Date: Mon, 12 Feb 2018 15:52:12 +0100 Subject: Accessing dependency version information Message-ID: <62ebc746-9a1c-39fc-56e8-902e73518c29@codefx.org> Hi! I think recording module version information is a really underappreciated feature in Java 9+. The module's own version shows up in many places, which I like. I think it could be added to `java --show-module-resolution`, too. It is much harder to access the versions of the dependencies against which a module was compiled. I thought I'd like it when it showed up in `jar --describe-module`, but I can see why "requires org.lib at 1.2" is too easy to misinterpret. Maybe another way could be found to make this information available on the command line (i.e. without having to use `ModuleDeclaration`). so long ... Nicolai -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From mark.reinhold at oracle.com Mon Feb 12 17:39:00 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 12 Feb 2018 09:39:00 -0800 Subject: RFR JDK-8170114 jimage extract to not an empty directory overwrites content of the directory In-Reply-To: <2f9257fb-f7b5-8f5b-8176-a888cfe01ec1@redhat.com> References: <139c1eee-f026-da7c-4925-ef2f5c2d9dda@redhat.com> <70485fc9-e394-458d-ba39-8fd3abb23996@oracle.com> <2f9257fb-f7b5-8f5b-8176-a888cfe01ec1@redhat.com> Message-ID: <20180212093900.282542632@eggemoggin.niobe.net> 2018/2/11 23:10:46 -0800, Michal Vala : > On 02/10/2018 11:25 AM, Alan Bateman wrote: >> ... >> >> I think the `jimage extract --dir ` scenario needs >> discussion. If is a non-directory file then jimage has to fail, >> I don't expect disagreement on that. For the case where it is an existing >> directory then the options seem to be: >> >> 1. Extract into the existing directory (existing JDK 9 and JDK 10 behavior) >> 2. Fail if it's not empty (your patch) >> 3. Fail if it exists (Mandy's mail, the motivation being to keep it consistent >> with jlink) >> >> I view `jimage extract --dir ` as being similar to `unzip -d ` so I >> don't think existing behavior (#1) is incorrect, the only issue is that it >> silently overrides files whereas unzip will prompt before overriding (unless you >> specify -o). The `jar` tool, and legacy `tar` tool side with `jimage` and are >> happy to silently replace existing files. >> >> What would you think about focusing on the override case instead of disallowing >> extracting into an existing non-empty directory? I realize this is more work as >> it means deciding on whether to prompt, warn or fail. It also means thinking >> about the equivalent of unzip -o to allowing existing files be replaced. > > Unzip prompts user for individual files and I'm not sure whether it's a good > option here. Maybe prompt user at the beginning that directory is not empty and > there is a risk that files there might be overwritten continue y/n? CLI tools that prompt the user are difficult to use in scripts, so I advise against that. jimage is a diagnostic tool meant for rare and specialized use. I think its current behavior (extract into an existing directory) is fine, and I can imagine use cases where that might actually be desired. - Mark From mark.reinhold at oracle.com Mon Feb 12 17:42:25 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 12 Feb 2018 09:42:25 -0800 Subject: Signing jlink code for macOS on other platforms In-Reply-To: <20180212114407.2d39e442@copperhead.int.arc7.info> References: <20180212114407.2d39e442@copperhead.int.arc7.info> Message-ID: <20180212094225.754578781@eggemoggin.niobe.net> 2018/2/12 3:44:07 -0800, Mark Raynsford : > ... > > Are there any plans to implement anything that's capable of signing > macOS binaries and resources in a platform-independent way so that > jlink-produced distributions can work without warnings? No. > Is that even a > reasonable thing to request? I've no idea how "private" Apple keep > their signing implementation. It's certainly reasonable, but as you suggest it would require an implementation of Apple's signing algorithm that runs on non-macOS systems. I have no idea if such a thing exists or is even possible. - Mark From Rony.Flatscher at wu.ac.at Mon Feb 12 19:59:40 2018 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Mon, 12 Feb 2018 20:59:40 +0100 Subject: Strange observation: MethodHandle.invokeWithArguments() would not work, whereas Method.invoke() would with the very same arguments Message-ID: In the process of adapting pure reflective code (a Rexx-Java bridge) to use MethodHandles on Java 9 instead, everything seems to be working out so far. In principle all invocations on the Java side are carried out by first using java.lang.reflect (Field, Method, Constructor) using the supplied arguments (if the arguments can be coerced to the respective parameterTypes it gets selected for invocation)? and if a candidate is found an appropriate MethodHandle gets created, which then gets used to invoke the operation supplying the coerced arguments, if any. Over the weekend I finalized the basic changes and started to test against a set of sample/demo applications. --- While testing a rather complex one (an adaption of the JavaFX address book example enhanced with a BarChart, [1]), that exhibits a very strange behavior: when setting the values for the CategoryAxis supplying an ObservableList of the month names in the current Locale, using a MethodHandle and invoking it with invokeWithArguments() would yield (debug output): // // // RexxReflectJava9.processMethod(), ARRIVED: -> [INVOKE], tmpMethod=[public final void javafx.scene.chart.CategoryAxis.setCategories(javafx.collections.ObservableList)]: method=[SETCATEGORIES] in object=[rru.rexxArgs[1]="javafx.scene.chart.CategoryAxis at 83278e1"/rru.bean="CategoryAxis[id=xAxis, styleClass=axis]"] // // // RexxReflectJava9.processMethod(), coercedArgs=[[[Ljava.lang.String;@57cfe770]].getClass().toString()=class [Ljava.lang.Object;, ??? ??? ?parameterTypes=[interface javafx.collections.ObservableList].getClass().toString()=class [Ljava.lang.Class;:, ??? ??? ?rru.funcArgs=[[[Ljava.lang.String;@57cfe770]].getClass().toString()=class [Ljava.lang.Object; // // :( RexxReflectJava9.processMethod(), MethodType for Method [public final void javafx.scene.chart.CategoryAxis.setCategories(javafx.collections.ObservableList)]: "(ObservableList)void" // // :( RexxReflectJava9.processMethod(): INSTANCE, mh.bindTo("CategoryAxis[id=xAxis, styleClass=axis]/class javafx.scene.chart.CategoryAxis").invokeWithArguments(...) // :) :) RexxReflectJava9.processMethod(), MethodHandle "MethodHandle(CategoryAxis,ObservableList)void" invocation caused a Throwable: java.lang.ClassCastException: java.base/[Ljava.lang.String; cannot be cast to java.base/java.lang.String The supplied ObservableList argument represents the? month names and was created with the help of "javafx.collections.FXCollections.observableList()" and then using its "addAll(monthNames)" method to add the String array values returned by DateFormatSymbols.getMonths() to the list. The supplied argument array "rru.funcArgs" will be coerced according to the reflected "parameterTypes" array yielding the "coercedArgs" array; using java.util.Arrays.deepToString() gives: // // // RexxReflectJava9.processMethod(), coercedArgs=[[[Ljava.lang.String;@57cfe770]].getClass().toString()=class [Ljava.lang.Object;, ??? ??? ?parameterTypes=[interface javafx.collections.ObservableList].getClass().toString()=class [Ljava.lang.Class;:, ??? ??? ?rru.funcArgs=[[[Ljava.lang.String;@57cfe770]].getClass().toString()=class [Ljava.lang.Object; --- The story is much longer but after quite long debugging sessions, I turned on reflective invoke via tmpMethod instead of invoking the corresponding MethodHandle, which (surprisingly) works. Then, in the next step doing the same invocation via the corresponding MethodHandle immediately after the reflective invocation, allows that invocation to execute successfully as well! Please note, the supplied coerced argument is in both cases the same! Coercion occurs according to the "parameterTypes" returned by java.lang.reflect.Method which also is used for creating the MethodType in order to use a publicLookup.findVirtual(...). Or with other words: the coerced argument will be identical for both invocation types! Another strange observation in the success case is as follows: when using reflective invocation by default (and then only invoking the MethodHandle in the special case that the method "setCategories" is to be executed) the coerced argument supplied to java.util.Arrays.deepToString() will list the monthnames: // // // RexxReflectJava9.processMethod(), ARRIVED: -> [INVOKE], tmpMethod=[public final void javafx.scene.chart.CategoryAxis.setCategories(javafx.collections.ObservableList)]: method=[SETCATEGORIES] in object=[rru.rexxArgs[1]="javafx.scene.chart.CategoryAxis at 2d809949"/rru.bean="CategoryAxis[id=xAxis, styleClass=axis]"] // // // RexxReflectJava9.processMethod(), coercedArgs=[[January, February, March, April, May, June, July, August, September, October, November, December, ]].getClass().toString()=class [Ljava.lang.Object;, ??? ??? ?parameterTypes=[interface javafx.collections.ObservableList].getClass().toString()=class [Ljava.lang.Class;:, ??? ??? ?rru.funcArgs=[[January, February, March, April, May, June, July, August, September, October, November, December, ]].getClass().toString()=class [Ljava.lang.Object; // // // RexxReflectJava9.processMethod(), bean=[CategoryAxis[id=xAxis, styleClass=axis]], methodName=[SETCATEGORIES], coercedArgs=[[January, February, March, April, May, June, July, August, September, October, November, December, ]] // // :( RexxReflectJava9.processMethod(), MethodType for Method [public final void javafx.scene.chart.CategoryAxis.setCategories(javafx.collections.ObservableList)]: "(ObservableList)void" // // :( RexxReflectJava9.processMethod(): INSTANCE, mh.bindTo("CategoryAxis[id=xAxis, styleClass=axis]/class javafx.scene.chart.CategoryAxis").invokeWithArguments(...) ... add2cachedFieldsOrMethods(): rru.memberName=[SETCATEGORIES] -> rru.keyMemberName=[SETCATEGORIES], rru.invocationType=[INVOKE], cfm=[CachedFieldOrMethod[mhk=METHOD,mh=MethodHandle(CategoryAxis,ObservableList)void,parameterTypes=[interface javafx.collections.ObservableList]]] I double checked that the only difference is in using java.lang.reflect.Method.invoke(...) which makes the Throwable on the method handle invocation go away (and the monthnames to be shown by Arrays.deepToString()). Here is the excerpt of the code section in question that allows the MethodHandle mh to be invoked successfully with the same coerced argument: Class parameterTypes[] = tmpMethod.getParameterTypes(); ??????????????? rru.result=tmpMethod.invoke(rru.bean,coercedArgs);????? // java.lang.reflect.Method ... cut ... ??????????? Class returnType=tmpMethod.getReturnType(); ??????????? MethodType mt = MethodType.methodType(returnType, parameterTypes); ... cut ... ?????????? // access via MethodHandle with the rights of rru.firstExportedClz ??????????????????????? mh=thisLookup.findVirtual(rru.firstExportedClz, methodName, mt); ??????????????????????? // mh=thisLookup.unreflect(tmpMethod);? // same behaviour ??????????????? rru.result=mh.bindTo(rru.bean).invokeWithArguments(coercedArgs); // bind to bean, invoke method Just commenting out the reflective invocation in line 2 above ("rru.result=tmpMethod.invoke(rru.bean,coercedArgs); ") will cause the MethodHandle invocation to fail with the reported Throwable! ---? Also it seems that java.util.Arrays.deepToString(...) is affected by this, if looking at the String value it produces in both cases (different number of enclosing square brackets: the failing version has another pair of enclosing square brackets). Here the debug code for creating the above outputs ("coercedArgs" will be returned by a coerce method and will be null, if the "rru.funcArgs" arguments from Rexx could not be coerced according to the "parameterTypes"): String tmpStrCoercedArgs= (coercedArgs==null ? null : Arrays.deepToString(coercedArgs)+".getClass().toString()="+coercedArgs.getClass().toString() ); System.err.println("// // // RexxReflectJava9.processMethod(), coercedArgs="+tmpStrCoercedArgs ?????????????????????????????????????????????????????????????? +",\n\t\t parameterTypes="+Arrays.deepToString(parameterTypes)+".getClass().toString()="+parameterTypes.getClass().toString() ?????????????????????????????????????????????????????????????? +":,\n\t\t rru.funcArgs="+Arrays.deepToString(rru.funcArgs)+".getClass().toString()="+rru.funcArgs.getClass().toString() ?????????????????????????????????????????????????????????????? ); --- This strange observation is on Windows 7: F:\work\svn\bsf4oorexx\trunk\bsf4oorexx.dev\source_cc>java -version java version "9.0.1" Java(TM) SE Runtime Environment (build 9.0.1+11) Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode) --- Would anyone have an idea what the reason could be or have any advice? ---rony [1] Slides with the address book sample in question; look for the pictures in the section starting at page: . P.S.: Yes, the debug output could be cleaner (evolved from many permutations and formatting in the past weeks), however this is right from the battle-field and tidying everything up is next on the todo list. From mandy.chung at oracle.com Tue Feb 13 00:44:41 2018 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 12 Feb 2018 16:44:41 -0800 Subject: IllegalAccessException trying to load a ResourceBundle in 9u181 In-Reply-To: References: Message-ID: On 2/12/18 12:36 PM, Vitaly Davidovich wrote: > Hi all, > > I'm not sure if core-libs is the right mailing list for jigsaw/modules > questions these days (rather than jigsaw-dev), so please feel free to > forward this there if it's the more appropriate list. cc'ing? jigsaw-dev > I have the following code carried over from java 8 (actually much earlier > than that, but that's beside the point): > final Resource rb = > ResourceBundle.getBundle("sun.security.util.AuthResources"); Resource bundle follows the same encapsulation rule as described in Module::getResourceAsStream [1] except that a resource bundle is considered as a resource regardless of its format. ResourceBundle.getBundle(String baseName) finds the specified resource bundle from the caller's module.? It will first search the resource bundle local in the caller's module (via Module::getResourceAsStream) and then using the caller's class loader to search for the resource (via ClassLoader::getResourceAsStream).?? Since the caller is unnamed module in your case, for it to access "sun.security.util.AuthResources", java.base/sun.security.util has to be open unconditionally and there is no CLI option to do that. If you call ResourceBundle.getBundle("sun.security.util.AuthResources", Object.class.getModule()) specifying the module of the resource bundle, then you can break the encapsulation by `--add-opens java.base/sun.security.util=ALL-UNNAMED` I'm a bit surprised that you depend on JDK internal resource bundle.? Can you help us understand why you use it? Mandy [1] https://download.java.net/java/jdk10/docs/api/java/util/ResourceBundle.html#getBundle(java.lang.String,java.util.Locale,java.lang.Module) From mvala at redhat.com Tue Feb 13 08:25:59 2018 From: mvala at redhat.com (Michal Vala) Date: Tue, 13 Feb 2018 09:25:59 +0100 Subject: RFR JDK-8170114 jimage extract to not an empty directory overwrites content of the directory In-Reply-To: <20180212093900.282542632@eggemoggin.niobe.net> References: <139c1eee-f026-da7c-4925-ef2f5c2d9dda@redhat.com> <70485fc9-e394-458d-ba39-8fd3abb23996@oracle.com> <2f9257fb-f7b5-8f5b-8176-a888cfe01ec1@redhat.com> <20180212093900.282542632@eggemoggin.niobe.net> Message-ID: <1518510359.6644.6.camel@redhat.com> On Mon, 2018-02-12 at 09:39 -0800, mark.reinhold at oracle.com wrote: > 2018/2/11 23:10:46 -0800, Michal Vala : > > On 02/10/2018 11:25 AM, Alan Bateman wrote: > > > ... > > > > > > I think the `jimage extract --dir ` > > > scenario needs > > > discussion. If is a non-directory file then > > > jimage has to fail, > > > I don't expect disagreement on that. For the case where it is an > > > existing > > > directory then the options seem to be: > > > > > > 1. Extract into the existing directory (existing JDK 9 and JDK 10 > > > behavior) > > > 2. Fail if it's not empty (your patch) > > > 3. Fail if it exists (Mandy's mail, the motivation being to keep > > > it consistent > > > with jlink) > > > > > > I view `jimage extract --dir ` as being similar to `unzip -d > > > ` so I > > > don't think existing behavior (#1) is incorrect, the only issue > > > is that it > > > silently overrides files whereas unzip will prompt before > > > overriding (unless you > > > specify -o). The `jar` tool, and legacy `tar` tool side with > > > `jimage` and are > > > happy to silently replace existing files. > > > > > > What would you think about focusing on the override case instead > > > of disallowing > > > extracting into an existing non-empty directory? I realize this > > > is more work as > > > it means deciding on whether to prompt, warn or fail. It also > > > means thinking > > > about the equivalent of unzip -o to allowing existing files be > > > replaced. > > > > Unzip prompts user for individual files and I'm not sure whether > > it's a good > > option here. Maybe prompt user at the beginning that directory is > > not empty and > > there is a risk that files there might be overwritten continue y/n? > > CLI tools that prompt the user are difficult to use in scripts, > so I advise against that. Usability in scripts is a valid point, but I still think that silently overwriting files is a bad practice. I can imagine better behavior without prompting the user. Like error when non-empty dir and 'force- overwrite' parameter. Or at least print a warning message that some files were overwritten. > > jimage is a diagnostic tool meant for rare and specialized use. > I think its current behavior (extract into an existing directory) > is fine, and I can imagine use cases where that might actually be > desired. > > - Mark -- Michal Vala OpenJDK QE Red Hat Czech From vitalyd at gmail.com Tue Feb 13 13:03:15 2018 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 13 Feb 2018 08:03:15 -0500 Subject: IllegalAccessException trying to load a ResourceBundle in 9u181 In-Reply-To: References: Message-ID: Hi Mandy, Thanks very much for your response. Some comments inline ... On Mon, Feb 12, 2018 at 7:44 PM, mandy chung wrote: > > > On 2/12/18 12:36 PM, Vitaly Davidovich wrote: > > Hi all, > > I'm not sure if core-libs is the right mailing list for jigsaw/modules > questions these days (rather than jigsaw-dev), so please feel free to > forward this there if it's the more appropriate list. > > > cc'ing jigsaw-dev > > I have the following code carried over from java 8 (actually much earlier > than that, but that's beside the point): > final Resource rb = > ResourceBundle.getBundle("sun.security.util.AuthResources"); > > > Resource bundle follows the same encapsulation rule as described in > Module::getResourceAsStream [1] except that a resource bundle is considered > as a resource regardless of its format. > Good to know - thanks. > > ResourceBundle.getBundle(String baseName) finds the specified resource > bundle from the caller's module. It will first search the resource bundle > local in the caller's module (via Module::getResourceAsStream) and then > using the caller's class loader to search for the resource (via > ClassLoader::getResourceAsStream). Since the caller is unnamed module > in your case, for it to access "sun.security.util.AuthResources", > java.base/sun.security.util has to be open unconditionally and there is no > CLI option to do that. > Understood. > > If you call ResourceBundle.getBundle("sun.security.util.AuthResources", > Object.class.getModule()) specifying the module of the resource bundle, > then you can break the encapsulation by `--add-opens > java.base/sun.security.util=ALL-UNNAMED` > So I tried calling getBundle(..., Object.class.getModule()), and that worked - great. Interestingly, I didn't have to add-opens (or add-export for that matter). Is that expected? > > I'm a bit surprised that you depend on JDK internal resource bundle. Can > you help us understand why you use it? > Sigh. Yes, this is an ugly wart in the system, with lots of historical baggage. The (really) short of it is we have a custom javax.security.auth.spi.LoginModule implementation, which loads this ResourceBundle (into a static final field). This is something that's being addressed in parallel, but I'm trying to make some progress with migrating the codebase to Java 9 in the meantime. I should also mention that the real problem I'm troubleshooting is a NoClassDefFoundError when this custom LoginModule is loaded. After some class load/resolution tracing, it appears to me that the impl is found but fails to initialize properly due to the ResourceBundle static field initialization. That's what started me down a path of trying to minimize the code and seeing what the issue is. It's also worth mentioning that I'm trying to run the real code on the 9u181 JVM but with code compiled on Java 8 (we have a bunch of compile-time issues to resolve so wanted to see if we can at least make progress on running on a 9 JVM). I would like to try patching this custom login module to use the new getBundle() overload that takes a Module, but I guess I'll need to compile it with a java 9 javac. So yeah, it's ugly unfortunately. Anyway, thanks for the help - I will try a few more things on my end. If you have any suggestions to deal with this frankenstein setup I described above, I'm all ears. > > Mandy > [1] https://download.java.net/java/jdk10/docs/api/java/util/ > ResourceBundle.html#getBundle(java.lang.String,java.util. > Locale,java.lang.Module) > From Alan.Bateman at oracle.com Tue Feb 13 13:57:08 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 13 Feb 2018 13:57:08 +0000 Subject: IllegalAccessException trying to load a ResourceBundle in 9u181 In-Reply-To: References: Message-ID: <46c81f70-6cb5-bad1-ccd3-c98201324c5b@oracle.com> On 13/02/2018 13:03, Vitaly Davidovich wrote: > : > So I tried calling getBundle(..., Object.class.getModule()), and that > worked - great. Interestingly, I didn't have to add-opens (or add-export > for that matter). Is that expected? > It works because the sun.security.util.AuthResources resource bundle for the default locale is in java.base. You'll get MissingResourceException once java.base is fully encapsulated (testing with --illegal-access=deny to try it). -Alan From vitalyd at gmail.com Tue Feb 13 14:05:35 2018 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 13 Feb 2018 09:05:35 -0500 Subject: IllegalAccessException trying to load a ResourceBundle in 9u181 In-Reply-To: <46c81f70-6cb5-bad1-ccd3-c98201324c5b@oracle.com> References: <46c81f70-6cb5-bad1-ccd3-c98201324c5b@oracle.com> Message-ID: On Tue, Feb 13, 2018 at 8:57 AM, Alan Bateman wrote: > > > On 13/02/2018 13:03, Vitaly Davidovich wrote: > >> : >> So I tried calling getBundle(..., Object.class.getModule()), and that >> worked - great. Interestingly, I didn't have to add-opens (or add-export >> for that matter). Is that expected? >> >> It works because the sun.security.util.AuthResources resource bundle for > the default locale is in java.base. You'll get MissingResourceException > once java.base is fully encapsulated (testing with --illegal-access=deny to > try it). Right, thanks Alan. While we're on the subject, when do you expect java.base to be fully encapsulated? > > > -Alan > From Alan.Bateman at oracle.com Tue Feb 13 14:10:28 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 13 Feb 2018 14:10:28 +0000 Subject: IllegalAccessException trying to load a ResourceBundle in 9u181 In-Reply-To: References: <46c81f70-6cb5-bad1-ccd3-c98201324c5b@oracle.com> Message-ID: <62424ae0-7d1e-ffd6-44f5-567a20fba788@oracle.com> On 13/02/2018 14:05, Vitaly Davidovich wrote: > > Right, thanks Alan.? While we're on the subject, when do you expect > java.base to be fully encapsulated? > TBD. From mvala at redhat.com Fri Feb 16 13:03:32 2018 From: mvala at redhat.com (Michal Vala) Date: Fri, 16 Feb 2018 14:03:32 +0100 Subject: JDK-8170120 jimage IOException solution? Message-ID: <1207832f-9822-8d62-6570-072107bf27fe@redhat.com> Hi, I'm working on JDK-8170120[1]. I have 2 working solutions, but I'm not happy with neither one. That IOException is thrown from jdk.internal.jimage.BasicImageReader, which is in java.base module. Jimage is implemented in jdk.jlink module (jdk.tools.jimage.JImageTask). One solution is new exception NotValidJimageException which can be thrown from BasicImageReader and catch and handled at JImageTask. Then it's easy to return proper error message to the output. Issue is that this new exception has to be public in java.base so de-facto defining new jdk core api, which of course I don't want to. Next option is leave there IOException, but give it some known message and then handle this message in JImageTask. This work also well, but "parsing" some message from exception is a bit clumsy. Opinions or other ideas? [1] - https://bugs.openjdk.java.net/browse/JDK-8170120 -- Michal Vala OpenJDK QE Red Hat Czech From Alan.Bateman at oracle.com Fri Feb 16 13:17:18 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Feb 2018 13:17:18 +0000 Subject: JDK-8170120 jimage IOException solution? In-Reply-To: <1207832f-9822-8d62-6570-072107bf27fe@redhat.com> References: <1207832f-9822-8d62-6570-072107bf27fe@redhat.com> Message-ID: <782152e3-d0da-93a5-75a5-d69b4b5fe8ab@oracle.com> On 16/02/2018 13:03, Michal Vala wrote: > Hi, > > I'm working on JDK-8170120[1]. I have 2 working solutions, but I'm not > happy with neither one. > > That IOException is thrown from jdk.internal.jimage.BasicImageReader, > which is in java.base module. Jimage is implemented in jdk.jlink > module (jdk.tools.jimage.JImageTask). > > One solution is new exception NotValidJimageException which can be > thrown from BasicImageReader and catch and handled at JImageTask. Then > it's easy to return proper error message to the output. > Issue is that this new exception has to be public in java.base so > de-facto defining new jdk core api, which of course I don't want to. > > Next option is leave there IOException, but give it some known message > and then handle this message in JImageTask. > This work also well, but "parsing" some message from exception is a > bit clumsy. Why can't you just catch the IOException and adds the exception message to the error message that jimage prints? -Alan From mvala at redhat.com Fri Feb 16 13:35:22 2018 From: mvala at redhat.com (Michal Vala) Date: Fri, 16 Feb 2018 14:35:22 +0100 Subject: JDK-8170120 jimage IOException solution? In-Reply-To: <782152e3-d0da-93a5-75a5-d69b4b5fe8ab@oracle.com> References: <1207832f-9822-8d62-6570-072107bf27fe@redhat.com> <782152e3-d0da-93a5-75a5-d69b4b5fe8ab@oracle.com> Message-ID: On 02/16/2018 02:17 PM, Alan Bateman wrote: > On 16/02/2018 13:03, Michal Vala wrote: >> Hi, >> >> I'm working on JDK-8170120[1]. I have 2 working solutions, but I'm not happy >> with neither one. >> >> That IOException is thrown from jdk.internal.jimage.BasicImageReader, which is >> in java.base module. Jimage is implemented in jdk.jlink module >> (jdk.tools.jimage.JImageTask). >> >> One solution is new exception NotValidJimageException which can be thrown from >> BasicImageReader and catch and handled at JImageTask. Then it's easy to return >> proper error message to the output. >> Issue is that this new exception has to be public in java.base so de-facto >> defining new jdk core api, which of course I don't want to. >> >> Next option is leave there IOException, but give it some known message and >> then handle this message in JImageTask. >> This work also well, but "parsing" some message from exception is a bit clumsy. > Why can't you just catch the IOException and adds the exception message to the > error message that jimage prints? Sure I can do that. However, all output messages are defined at jimage.properties (jdk.jlink module) file and this won't be possible for this case. I can't tell whether IOExcaption is caused by wrong jimage file or something else so all I can do is really just print an exception message. It also affects behavior of other cases that throws IOException (not sure if bad or not) that are now catch with Exception and return EXIT_ABNORMAL error code. So it sounds like another 'wrong' solution to me. Question is what solution is least wrong and what is desired behavior. I wanted to fix that one specific case with minimal side-effects. -- Michal Vala OpenJDK QE Red Hat Czech From Alan.Bateman at oracle.com Fri Feb 16 13:45:49 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Feb 2018 13:45:49 +0000 Subject: JDK-8170120 jimage IOException solution? In-Reply-To: References: <1207832f-9822-8d62-6570-072107bf27fe@redhat.com> <782152e3-d0da-93a5-75a5-d69b4b5fe8ab@oracle.com> Message-ID: <36fba984-c2e0-49fd-d4b2-35a5f10616cd@oracle.com> On 16/02/2018 13:35, Michal Vala wrote: > : > > Sure I can do that. However, all output messages are defined at > jimage.properties (jdk.jlink module) file and this won't be possible > for this case. I can't tell whether IOExcaption is caused by wrong > jimage file or something else so all I can do is really just print an > exception message. The jimage tool is for troubleshooting purposes, it's not a tool that we expect many developers to every use directly. It should be okay if the resource is something like "Unable to open {0}: {1}" where {0} is the file path specified to the tool, and {1} is the exception message. -Alan From mvala at redhat.com Fri Feb 16 14:39:31 2018 From: mvala at redhat.com (Michal Vala) Date: Fri, 16 Feb 2018 15:39:31 +0100 Subject: JDK-8170120 jimage IOException solution? In-Reply-To: <36fba984-c2e0-49fd-d4b2-35a5f10616cd@oracle.com> References: <1207832f-9822-8d62-6570-072107bf27fe@redhat.com> <782152e3-d0da-93a5-75a5-d69b4b5fe8ab@oracle.com> <36fba984-c2e0-49fd-d4b2-35a5f10616cd@oracle.com> Message-ID: <8d239562-c586-97b1-8a85-bd55ca54da46@redhat.com> On 02/16/2018 02:45 PM, Alan Bateman wrote: > On 16/02/2018 13:35, Michal Vala wrote: >> : >> >> Sure I can do that. However, all output messages are defined at >> jimage.properties (jdk.jlink module) file and this won't be possible for this >> case. I can't tell whether IOExcaption is caused by wrong jimage file or >> something else so all I can do is really just print an exception message. > The jimage tool is for troubleshooting purposes, it's not a tool that we expect > many developers to every use directly. It should be okay if the resource is > something like "Unable to open {0}: {1}" where {0} is the file path specified to > the tool, and {1} is the exception message. That sounds reasonable. Here's the webrev: http://cr.openjdk.java.net/~shade/8170120/webrev.01/ It fixes JImageVerifyTest so I've removed it from ProblemList. note: JImageExtractTest still failing on not-empty-dir(JDK-8170114) and JImageListTest fails on simplest list test. I'll take a look at it later. -- Michal Vala OpenJDK QE Red Hat Czech From Alan.Bateman at oracle.com Sat Feb 17 07:17:41 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 17 Feb 2018 07:17:41 +0000 Subject: JDK-8170120 jimage IOException solution? In-Reply-To: <8d239562-c586-97b1-8a85-bd55ca54da46@redhat.com> References: <1207832f-9822-8d62-6570-072107bf27fe@redhat.com> <782152e3-d0da-93a5-75a5-d69b4b5fe8ab@oracle.com> <36fba984-c2e0-49fd-d4b2-35a5f10616cd@oracle.com> <8d239562-c586-97b1-8a85-bd55ca54da46@redhat.com> Message-ID: <8de17589-46cb-b34c-4bbd-292f5d651985@oracle.com> On 16/02/2018 14:39, Michal Vala wrote: > : > > That sounds reasonable. Here's the webrev: > http://cr.openjdk.java.net/~shade/8170120/webrev.01/ > > It fixes JImageVerifyTest so I've removed it from ProblemList. > > > note: JImageExtractTest still failing on not-empty-dir(JDK-8170114) > and JImageListTest fails on simplest list test. I'll take a look at it > later. > The changes look good, I just wonder if it would be better to specify {0} as file rather than file.getName(). Just thinking about a script running this tool failing because the file path is wrong, I think it could be useful to have it in error. -Alan From mvala at redhat.com Mon Feb 19 12:09:01 2018 From: mvala at redhat.com (Michal Vala) Date: Mon, 19 Feb 2018 13:09:01 +0100 Subject: JDK-8170120 jimage IOException solution? In-Reply-To: <8de17589-46cb-b34c-4bbd-292f5d651985@oracle.com> References: <1207832f-9822-8d62-6570-072107bf27fe@redhat.com> <782152e3-d0da-93a5-75a5-d69b4b5fe8ab@oracle.com> <36fba984-c2e0-49fd-d4b2-35a5f10616cd@oracle.com> <8d239562-c586-97b1-8a85-bd55ca54da46@redhat.com> <8de17589-46cb-b34c-4bbd-292f5d651985@oracle.com> Message-ID: On 02/17/2018 08:17 AM, Alan Bateman wrote: > On 16/02/2018 14:39, Michal Vala wrote: >> : >> >> That sounds reasonable. Here's the webrev: >> http://cr.openjdk.java.net/~shade/8170120/webrev.01/ >> >> It fixes JImageVerifyTest so I've removed it from ProblemList. >> >> >> note: JImageExtractTest still failing on not-empty-dir(JDK-8170114) and >> JImageListTest fails on simplest list test. I'll take a look at it later. >> > The changes look good, I just wonder if it would be better to specify {0} as > file rather than file.getName(). Just thinking about a script running this tool > failing because the file path is wrong, I think it could be useful to have it in > error. Yes, true. Attached. > > -Alan > -- Michal Vala OpenJDK QE Red Hat Czech -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk.patch Type: text/x-patch Size: 1497 bytes Desc: not available URL: From Alan.Bateman at oracle.com Mon Feb 19 13:07:02 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Feb 2018 13:07:02 +0000 Subject: JDK-8170120 jimage IOException solution? In-Reply-To: References: <1207832f-9822-8d62-6570-072107bf27fe@redhat.com> <782152e3-d0da-93a5-75a5-d69b4b5fe8ab@oracle.com> <36fba984-c2e0-49fd-d4b2-35a5f10616cd@oracle.com> <8d239562-c586-97b1-8a85-bd55ca54da46@redhat.com> <8de17589-46cb-b34c-4bbd-292f5d651985@oracle.com> Message-ID: <2670213c-8bf6-f530-6703-c7d0fb9be272@oracle.com> On 19/02/2018 12:09, Michal Vala wrote: > > > Yes, true. Attached. This looks good except the "does not exist" case which needs this change: -??????????????? throw TASK_HELPER.newBadArgs("err.not.a.jimage", file.getName()); +??????????????? throw TASK_HELPER.newBadArgs("err.not.a.jimage", file); If you agree then I will include it in your patch and push it. -Alan From mvala at redhat.com Mon Feb 19 13:12:33 2018 From: mvala at redhat.com (Michal Vala) Date: Mon, 19 Feb 2018 14:12:33 +0100 Subject: JDK-8170120 jimage IOException solution? In-Reply-To: <2670213c-8bf6-f530-6703-c7d0fb9be272@oracle.com> References: <1207832f-9822-8d62-6570-072107bf27fe@redhat.com> <782152e3-d0da-93a5-75a5-d69b4b5fe8ab@oracle.com> <36fba984-c2e0-49fd-d4b2-35a5f10616cd@oracle.com> <8d239562-c586-97b1-8a85-bd55ca54da46@redhat.com> <8de17589-46cb-b34c-4bbd-292f5d651985@oracle.com> <2670213c-8bf6-f530-6703-c7d0fb9be272@oracle.com> Message-ID: <4b3914a5-de48-16a1-d7cd-a239ff105f80@redhat.com> On 02/19/2018 02:07 PM, Alan Bateman wrote: > On 19/02/2018 12:09, Michal Vala wrote: >> >> >> Yes, true. Attached. > This looks good except the "does not exist" case which needs this change: > > -??????????????? throw TASK_HELPER.newBadArgs("err.not.a.jimage", file.getName()); > +??????????????? throw TASK_HELPER.newBadArgs("err.not.a.jimage", file); > > If you agree then I will include it in your patch and push it. yes please. thanks -- Michal Vala OpenJDK QE Red Hat Czech From mvala at redhat.com Mon Feb 19 14:02:20 2018 From: mvala at redhat.com (Michal Vala) Date: Mon, 19 Feb 2018 15:02:20 +0100 Subject: RFR JDK-8170114 jimage extract to not an empty directory overwrites content of the directory In-Reply-To: <139c1eee-f026-da7c-4925-ef2f5c2d9dda@redhat.com> References: <139c1eee-f026-da7c-4925-ef2f5c2d9dda@redhat.com> Message-ID: Hi, On 02/09/2018 04:23 PM, Michal Vala wrote: > Hi, > > sending fix for jimage bug JDK-8170114[1]. as this was resolved with current behavior is correct[1], I've updated test case according to this behavior. Patch attached. This also greens JImageExtractTest so I've removed it from ProblemList. [1] - https://bugs.openjdk.java.net/browse/JDK-8170114?focusedCommentId=14157816&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14157816 -- Michal Vala OpenJDK QE Red Hat Czech -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk.patch Type: text/x-patch Size: 1238 bytes Desc: not available URL: From mvala at redhat.com Mon Feb 19 14:51:53 2018 From: mvala at redhat.com (Michal Vala) Date: Mon, 19 Feb 2018 15:51:53 +0100 Subject: RFR - JImageListTest test fix Message-ID: Hi, sending patch fixing JImageListTest failing tests. It was in ProblemList and this fix greens the test case, so the patch also removes it from the list. It will probably need new bug id and I will need a sponsor for this. Fix itself is simple. There was incorrect assert for list of images contains java.base image as it was testing index of "java.base" > 0 and it's usually at first place, thus index 0. I've changed it to List#contains. Thanks! -- Michal Vala OpenJDK QE Red Hat Czech -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk.patch Type: text/x-patch Size: 1746 bytes Desc: not available URL: From sundararajan.athijegannathan at oracle.com Mon Feb 19 16:12:25 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 19 Feb 2018 21:42:25 +0530 Subject: RFR 8194922: jlink --exclude-resources should never exclude module-info.class Message-ID: <5A8AF769.2040205@oracle.com> Please review. Webrev: http://cr.openjdk.java.net/~sundar/8194922/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8194922 Thanks -Sundar From Alan.Bateman at oracle.com Mon Feb 19 16:22:56 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Feb 2018 16:22:56 +0000 Subject: RFR 8194922: jlink --exclude-resources should never exclude module-info.class In-Reply-To: <5A8AF769.2040205@oracle.com> References: <5A8AF769.2040205@oracle.com> Message-ID: <053572dc-52b8-174c-ed3a-5cc02bd1fe77@oracle.com> On 19/02/2018 16:12, Sundararajan Athijegannathan wrote: > Please review. > > Webrev: http://cr.openjdk.java.net/~sundar/8194922/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8194922 I assume it should be testing the resource name with equals rather than endsWith. I also wonder if jlink should fail for this case as it means the jlink user has specified the wrong path to --exclude-resources. JDK_8194922_Test.java needs a better name to be consistent with the tests in this area. -Alan From Alan.Bateman at oracle.com Mon Feb 19 16:33:56 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Feb 2018 16:33:56 +0000 Subject: RFR - JImageListTest test fix In-Reply-To: References: Message-ID: <6a1ac971-9146-764b-d9d3-f50afa6fad9b@oracle.com> On 19/02/2018 14:51, Michal Vala wrote: > Hi, > > sending patch fixing JImageListTest failing tests. It was in > ProblemList and this fix greens the test case, so the patch also > removes it from the list. > It will probably need new bug id and I will need a sponsor for this. > > Fix itself is simple. There was incorrect assert for list of images > contains java.base image as it was testing index of "java.base" > 0 > and it's usually at first place, thus index 0. I've changed it to > List#contains. This looks okay to me. -Alan From Alan.Bateman at oracle.com Mon Feb 19 19:00:07 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Feb 2018 19:00:07 +0000 Subject: RFR JDK-8170114 jimage extract to not an empty directory overwrites content of the directory In-Reply-To: References: <139c1eee-f026-da7c-4925-ef2f5c2d9dda@redhat.com> Message-ID: <6cff96ed-c2b6-6792-8310-6f8cb5f3eb62@oracle.com> On 19/02/2018 14:02, Michal Vala wrote: > Hi, > > On 02/09/2018 04:23 PM, Michal Vala wrote: >> Hi, >> >> sending fix for jimage bug JDK-8170114[1]. > > as this was resolved with current behavior is correct[1], I've updated > test case according to this behavior. > Patch attached. This also greens JImageExtractTest so I've removed it > from ProblemList. This looks okay to me. I've created JDK-8198380 to track/sponsor this. -Alan From sundararajan.athijegannathan at oracle.com Tue Feb 20 08:08:49 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 20 Feb 2018 13:38:49 +0530 Subject: RFR 8194922: jlink --exclude-resources should never exclude module-info.class In-Reply-To: <053572dc-52b8-174c-ed3a-5cc02bd1fe77@oracle.com> References: <5A8AF769.2040205@oracle.com> <053572dc-52b8-174c-ed3a-5cc02bd1fe77@oracle.com> Message-ID: <5A8BD791.7000004@oracle.com> Updated: http://cr.openjdk.java.net/~sundar/8194922/webrev.01/ * replaced endsWith with equals on $MODULE/module-info.class * jlink shows warning when module-info.class is not included (but implied to be excluded by --exclude-resources pattern) * Renamed the test. Thanks, -Sundar On 19/02/18, 9:52 PM, Alan Bateman wrote: > On 19/02/2018 16:12, Sundararajan Athijegannathan wrote: >> Please review. >> >> Webrev: http://cr.openjdk.java.net/~sundar/8194922/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8194922 > I assume it should be testing the resource name with equals rather > than endsWith. I also wonder if jlink should fail for this case as it > means the jlink user has specified the wrong path to --exclude-resources. > > JDK_8194922_Test.java needs a better name to be consistent with the > tests in this area. > > -Alan From Alan.Bateman at oracle.com Tue Feb 20 09:24:52 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 20 Feb 2018 09:24:52 +0000 Subject: RFR 8194922: jlink --exclude-resources should never exclude module-info.class In-Reply-To: <5A8BD791.7000004@oracle.com> References: <5A8AF769.2040205@oracle.com> <053572dc-52b8-174c-ed3a-5cc02bd1fe77@oracle.com> <5A8BD791.7000004@oracle.com> Message-ID: On 20/02/2018 08:08, Sundararajan Athijegannathan wrote: > > Updated: http://cr.openjdk.java.net/~sundar/8194922/webrev.01/ > > * replaced endsWith with equals on $MODULE/module-info.class > * jlink shows warning when module-info.class is not included (but > implied to be excluded by --exclude-resources pattern) > * Renamed the test. Thinking about more, it might be better for this to be an error rather than a warning so the jlink user fixes the filter. The test changes look good. -Alan From Alan.Bateman at oracle.com Tue Feb 20 09:47:09 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 20 Feb 2018 09:47:09 +0000 Subject: RFR - JImageListTest test fix In-Reply-To: References: Message-ID: <04e4ed19-2e35-c7bf-45ef-1c67b39773d9@oracle.com> On 19/02/2018 14:51, Michal Vala wrote: > Hi, > > sending patch fixing JImageListTest failing tests. It was in > ProblemList and this fix greens the test case, so the patch also > removes it from the list. These tests are failing on Windows now. Nothing to do with your changes, it seems the original tests added via JDK-8167240 weren't run enough to shake out issues with the tests. So we need to re-add them to the exclude list, Sundar has already reviewed. -Alan diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -464,6 +464,9 @@ ?tools/launcher/FXLauncherTest.java 8068049 linux-all,macosx-all +tools/jimage/JImageExtractTest.java 8198405 windows-all +tools/jimage/JImageListTest.java 8198405 windows-all + ?############################################################################ From sundararajan.athijegannathan at oracle.com Tue Feb 20 09:50:49 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 20 Feb 2018 15:20:49 +0530 Subject: RFR 8194922: jlink --exclude-resources should never exclude module-info.class In-Reply-To: References: <5A8AF769.2040205@oracle.com> <053572dc-52b8-174c-ed3a-5cc02bd1fe77@oracle.com> <5A8BD791.7000004@oracle.com> Message-ID: <5A8BEF79.1090908@oracle.com> Throwing exception now -> http://cr.openjdk.java.net/~sundar/8194922/webrev.02/ Thanks -Sundar On 20/02/18, 2:54 PM, Alan Bateman wrote: > On 20/02/2018 08:08, Sundararajan Athijegannathan wrote: >> >> Updated: http://cr.openjdk.java.net/~sundar/8194922/webrev.01/ >> >> * replaced endsWith with equals on $MODULE/module-info.class >> * jlink shows warning when module-info.class is not included (but >> implied to be excluded by --exclude-resources pattern) >> * Renamed the test. > Thinking about more, it might be better for this to be an error rather > than a warning so the jlink user fixes the filter. The test changes > look good. > > -Alan From Alan.Bateman at oracle.com Tue Feb 20 09:51:43 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 20 Feb 2018 09:51:43 +0000 Subject: RFR 8194922: jlink --exclude-resources should never exclude module-info.class In-Reply-To: <5A8BEF79.1090908@oracle.com> References: <5A8AF769.2040205@oracle.com> <053572dc-52b8-174c-ed3a-5cc02bd1fe77@oracle.com> <5A8BD791.7000004@oracle.com> <5A8BEF79.1090908@oracle.com> Message-ID: On 20/02/2018 09:50, Sundararajan Athijegannathan wrote: > Throwing exception now -> > http://cr.openjdk.java.net/~sundar/8194922/webrev.02/ This looks good to me. -Alan From mvala at redhat.com Tue Feb 20 11:34:16 2018 From: mvala at redhat.com (Michal Vala) Date: Tue, 20 Feb 2018 12:34:16 +0100 Subject: RFR - JImageListTest test fix In-Reply-To: <04e4ed19-2e35-c7bf-45ef-1c67b39773d9@oracle.com> References: <04e4ed19-2e35-c7bf-45ef-1c67b39773d9@oracle.com> Message-ID: On 02/20/2018 10:47 AM, Alan Bateman wrote: > > > On 19/02/2018 14:51, Michal Vala wrote: >> Hi, >> >> sending patch fixing JImageListTest failing tests. It was in ProblemList and >> this fix greens the test case, so the patch also removes it from the list. > These tests are failing on Windows now. Nothing to do with your changes, it > seems the original tests added via JDK-8167240 weren't run enough to shake out > issues with the tests. So we need to re-add them to the exclude list, Sundar has > already reviewed. ok, I can take a look at them > > -Alan > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -464,6 +464,9 @@ > > ?tools/launcher/FXLauncherTest.java 8068049 linux-all,macosx-all > > +tools/jimage/JImageExtractTest.java 8198405 windows-all > +tools/jimage/JImageListTest.java 8198405 windows-all > + > ?############################################################################ > > -- Michal Vala OpenJDK QE Red Hat Czech From mandy.chung at oracle.com Tue Feb 20 18:33:51 2018 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 20 Feb 2018 10:33:51 -0800 Subject: RFR 8194922: jlink --exclude-resources should never exclude module-info.class In-Reply-To: <5A8BEF79.1090908@oracle.com> References: <5A8AF769.2040205@oracle.com> <053572dc-52b8-174c-ed3a-5cc02bd1fe77@oracle.com> <5A8BD791.7000004@oracle.com> <5A8BEF79.1090908@oracle.com> Message-ID: <5a913468-d0f0-98a7-cccc-d1a467a8357c@oracle.com> Looks good.? I agree that this should be an error when excluding module declaration. Mandy On 2/20/18 1:50 AM, Sundararajan Athijegannathan wrote: > Throwing exception now -> > http://cr.openjdk.java.net/~sundar/8194922/webrev.02/ > > Thanks > -Sundar > > On 20/02/18, 2:54 PM, Alan Bateman wrote: >> On 20/02/2018 08:08, Sundararajan Athijegannathan wrote: >>> >>> Updated: http://cr.openjdk.java.net/~sundar/8194922/webrev.01/ >>> >>> * replaced endsWith with equals on $MODULE/module-info.class >>> * jlink shows warning when module-info.class is not included (but >>> implied to be excluded by --exclude-resources pattern) >>> * Renamed the test. >> Thinking about more, it might be better for this to be an error >> rather than a warning so the jlink user fixes the filter. The test >> changes look good. >> >> -Alan From mvala at redhat.com Wed Feb 21 12:23:55 2018 From: mvala at redhat.com (Michal Vala) Date: Wed, 21 Feb 2018 13:23:55 +0100 Subject: JDK-8198405 - JImageExtractTest.java & JImageListTest.java failed in Windows Message-ID: <3b962811-4edc-6b88-3fab-33c0c0bd7925@redhat.com> Hi, I'm trying to investigate failure of JImageExtractTest on Windows. Failing method is testExtractToReadOnlyDir, issue is simple. It is trying to extract jimage to read-only directory and it must fail. AFAIK it is not possible to create read-only directory. I tried set rights programaticaly from java, manually from windows explorer and windows cmd. Without any success. It effectively just deny access from explorer and cmd. Is there any Windows expert who can confirm this or suggest solution? Only solution I've found is to write something to some mounted ISO image, which is not an option here. In case this will be confirmed I suggest to skip this single test on Windows. -- Michal Vala OpenJDK QE Red Hat Czech From Alan.Bateman at oracle.com Wed Feb 21 13:44:51 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 21 Feb 2018 13:44:51 +0000 Subject: JDK-8198405 - JImageExtractTest.java & JImageListTest.java failed in Windows In-Reply-To: <3b962811-4edc-6b88-3fab-33c0c0bd7925@redhat.com> References: <3b962811-4edc-6b88-3fab-33c0c0bd7925@redhat.com> Message-ID: On 21/02/2018 12:23, Michal Vala wrote: > Hi, > > I'm trying to investigate failure of JImageExtractTest on Windows. > Failing method is testExtractToReadOnlyDir, issue is simple. It is > trying to extract jimage to read-only directory and it must fail. > AFAIK it is not possible to create read-only directory. I tried set > rights programaticaly from java, manually from windows explorer and > windows cmd. Without any success. It effectively just deny access from > explorer and cmd. > > Is there any Windows expert who can confirm this or suggest solution? > Only solution I've found is to write something to some mounted ISO > image, which is not an option here. > > In case this will be confirmed I suggest to skip this single test on > Windows. I don't have time to detail this just now but you can specify a DACL (as a FileAttribute>) to Files.createDirectory so that the directory is created with an initial DACL that denies access. Alternatively, you can change the DACL of an existing directory. Yes, a bit complicated to setup. I don't think it would be too much of a surprise for this sub-test to only execute on platforms that support POSIX file permissions (I think some of the tests check this already). -Alan From mvala at redhat.com Wed Feb 21 13:59:58 2018 From: mvala at redhat.com (Michal Vala) Date: Wed, 21 Feb 2018 14:59:58 +0100 Subject: JDK-8198405 - JImageExtractTest.java & JImageListTest.java failed in Windows In-Reply-To: References: <3b962811-4edc-6b88-3fab-33c0c0bd7925@redhat.com> Message-ID: On 02/21/2018 02:44 PM, Alan Bateman wrote: > On 21/02/2018 12:23, Michal Vala wrote: >> Hi, >> >> I'm trying to investigate failure of JImageExtractTest on Windows. >> Failing method is testExtractToReadOnlyDir, issue is simple. It is trying to >> extract jimage to read-only directory and it must fail. AFAIK it is not >> possible to create read-only directory. I tried set rights programaticaly from >> java, manually from windows explorer and windows cmd. Without any success. It >> effectively just deny access from explorer and cmd. >> >> Is there any Windows expert who can confirm this or suggest solution? Only >> solution I've found is to write something to some mounted ISO image, which is >> not an option here. >> >> In case this will be confirmed I suggest to skip this single test on Windows. > I don't have time to detail this just now but you can specify a DACL (as a > FileAttribute>) to Files.createDirectory so that the directory is > created with an initial DACL that denies access. Alternatively, you can change > the DACL of an existing directory. Yes, a bit complicated to setup. I don't > think it would be too much of a surprise for this sub-test to only execute on > platforms that support POSIX file permissions (I think some of the tests check > this already). Yes, I've tried this, but I'm still able to create a file in that directory. It prevents just from accessing the directory from explorer or cmd. However, I can freely access it from cygwin or java. -- Michal Vala OpenJDK QE Red Hat Czech From org.openjdk at io7m.com Fri Feb 23 19:18:05 2018 From: org.openjdk at io7m.com (Mark Raynsford) Date: Fri, 23 Feb 2018 19:18:05 +0000 Subject: Finding module-info.class without loading a jar Message-ID: <20180223191805.17db5cb0@copperhead.int.arc7.info> Hello. I'm analyzing the contents of jar files and basically need to answer the question "is this jar file modularized?". To do this, I search for a module-info.class file in the root of the jar file (and parse it with ASM), or I look for an Automatic-Module-Name entry in the jar manifest if there doesn't appear to be a module descriptor available. Unfortunately, some projects don't put the module-info.class file in the root of the jar. Some of them place them in META-INF/versions/9/module-info.class, for example. I could search every possible subdirectory in the jar for something that looks like a module-info.class, but I'd prefer not to have to. Is there a standard method in the JDK that can find the module descriptor class file for me based on the rules the JVM uses to find the descriptor upon loading a jar? -- Mark Raynsford | http://www.io7m.com From Alan.Bateman at oracle.com Sat Feb 24 07:53:16 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 24 Feb 2018 07:53:16 +0000 Subject: Finding module-info.class without loading a jar In-Reply-To: <20180223191805.17db5cb0@copperhead.int.arc7.info> References: <20180223191805.17db5cb0@copperhead.int.arc7.info> Message-ID: <812faf3e-f425-a3c6-148d-c40e5be529ea@oracle.com> On 23/02/2018 19:18, Mark Raynsford wrote: > Hello. > > I'm analyzing the contents of jar files and basically need to answer > the question "is this jar file modularized?". To do this, I search for > a module-info.class file in the root of the jar file (and parse it with > ASM), or I look for an Automatic-Module-Name entry in the jar manifest > if there doesn't appear to be a module descriptor available. > > Unfortunately, some projects don't put the module-info.class file in > the root of the jar. Some of them place them in > META-INF/versions/9/module-info.class, for example. I could search > every possible subdirectory in the jar for something that looks like a > module-info.class, but I'd prefer not to have to. Is there a standard > method in the JDK that can find the module descriptor class file for me > based on the rules the JVM uses to find the descriptor upon loading a > jar? > The JarFile API does this for you. Are you sure you've used the constructor that specifies the runtime version? Once you do that then getJarEntry("module-info.class") will locate the module-info.class in the versioned section. Use JarEntry::getRealName to satisfy yourself that it always locates the right one (say where you have a module-info.class in the top-level directory and one each in META-INF/versions/9 and META-INF/versions/10). ModuleDescriptor.read is an easy way to parse the module-info.class in case you need it. -Alan From org.openjdk at io7m.com Sat Feb 24 12:33:25 2018 From: org.openjdk at io7m.com (Mark Raynsford) Date: Sat, 24 Feb 2018 12:33:25 +0000 Subject: Finding module-info.class without loading a jar In-Reply-To: <812faf3e-f425-a3c6-148d-c40e5be529ea@oracle.com> References: <20180223191805.17db5cb0@copperhead.int.arc7.info> <812faf3e-f425-a3c6-148d-c40e5be529ea@oracle.com> Message-ID: <20180224123325.0bd96408@copperhead.int.arc7.info> On 2018-02-24T07:53:16 +0000 Alan Bateman wrote: > > The JarFile API does this for you. Are you sure you've used the > constructor that specifies the runtime version? Once you do that then > getJarEntry("module-info.class") will locate the module-info.class in > the versioned section. Use JarEntry::getRealName to satisfy yourself > that it always locates the right one (say where you have a > module-info.class in the top-level directory and one each in > META-INF/versions/9 and META-INF/versions/10). Ah, thank you. I had completely overlooked this constructor. > ModuleDescriptor.read is an easy way to parse the module-info.class in > case you need it. Yes, I'm planning to move to this from ASM. -- Mark Raynsford | http://www.io7m.com From forax at univ-mlv.fr Sat Feb 24 14:53:01 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 24 Feb 2018 14:53:01 +0000 Subject: Finding module-info.class without loading a jar In-Reply-To: <20180224123325.0bd96408@copperhead.int.arc7.info> References: <20180223191805.17db5cb0@copperhead.int.arc7.info> <812faf3e-f425-a3c6-148d-c40e5be529ea@oracle.com> <20180224123325.0bd96408@copperhead.int.arc7.info> Message-ID: On February 24, 2018 12:33:25 PM UTC, Mark Raynsford wrote: >On 2018-02-24T07:53:16 +0000 >Alan Bateman wrote: >> >> The JarFile API does this for you. Are you sure you've used the >> constructor that specifies the runtime version? Once you do that then > >> getJarEntry("module-info.class") will locate the module-info.class in > >> the versioned section. Use JarEntry::getRealName to satisfy yourself >> that it always locates the right one (say where you have a >> module-info.class in the top-level directory and one each in >> META-INF/versions/9 and META-INF/versions/10). > >Ah, thank you. I had completely overlooked this constructor. > >> ModuleDescriptor.read is an easy way to parse the module-info.class >in >> case you need it. > >Yes, I'm planning to move to this from ASM. The main difference between the ModuleDescriptor and the ModuleVisitor of ASM is that you can read the annotations with the ModuleVisitor. So it may not worth having ASM as dependency. Remi -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From org.openjdk at io7m.com Mon Feb 26 18:24:12 2018 From: org.openjdk at io7m.com (Mark Raynsford) Date: Mon, 26 Feb 2018 18:24:12 +0000 Subject: Signing jlink code for macOS on other platforms In-Reply-To: <20180212114407.2d39e442@copperhead.int.arc7.info> References: <20180212114407.2d39e442@copperhead.int.arc7.info> Message-ID: <20180226182412.2e3be8ba@copperhead.int.arc7.info> On 2018-02-12T11:44:07 +0000 Mark Raynsford wrote: > Hello! > > As a long time Java developer, I've only ever had to deal with signing > jar files. I can obviously sign jar files once on whatever platform I > choose to use to build the code, and then distribute the jars to all > platforms. Build once, run everywhere, etc. > > However, now that jlink exists, as a developer I have to deal with > signing platform-specific executables. For example, if I distribute a > macOS application produced with jlink, that executable will produce a > large warning message: Seeing as I've had no response, is it safe to assume that this subject isn't permitted here? I was hoping there'd be some discussion of platform-independent ways to produce correctly-signed jlink distributions... Right now, just using jlink at all means you (probably) have to go back to building code on each individual platform in order to get access to proprietary platform-specific signing tools. This kind of reduces the utility of being able to specify another platform's JVM with --module-path, because the resulting distribution won't really be usable thanks to the erosion of the ability to run unsigned binaries on some platforms. -- Mark Raynsford | http://www.io7m.com From amy.lu at oracle.com Wed Feb 28 08:53:33 2018 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 28 Feb 2018 16:53:33 +0800 Subject: [JDK 11] Problem list tools/jimage/JImageExtractTest.java for macosx-all Message-ID: <7e1205c3-c185-a854-7983-e88befd63bd1@oracle.com> Please review the patch to problem list tools/jimage/JImageExtractTest.java for macosx-all. This test fails frequently (observed at Mac) and should be problem listed before?JDK-8198819?fixed. bug: https://bugs.openjdk.java.net/browse/JDK-8198820 webrev: http://cr.openjdk.java.net/~amlu/8198820/webrev.00/ Thanks, Amy --- old/test/jdk/ProblemList.txt 2018-02-28 16:48:06.000000000 +0800 +++ new/test/jdk/ProblemList.txt 2018-02-28 16:48:06.000000000 +0800 @@ -467,7 +467,7 @@ tools/launcher/FXLauncherTest.java 8068049 linux-all,macosx-all -tools/jimage/JImageExtractTest.java 8198405 windows-all +tools/jimage/JImageExtractTest.java 8198405,8198819 windows-all,macosx-all tools/jimage/JImageListTest.java 8198405 windows-all ############################################################################ From Alan.Bateman at oracle.com Wed Feb 28 10:23:39 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Feb 2018 10:23:39 +0000 Subject: [JDK 11] Problem list tools/jimage/JImageExtractTest.java for macosx-all In-Reply-To: <7e1205c3-c185-a854-7983-e88befd63bd1@oracle.com> References: <7e1205c3-c185-a854-7983-e88befd63bd1@oracle.com> Message-ID: <299dc67c-c0c7-38d6-3728-9d82ff509fc1@oracle.com> On 28/02/2018 08:53, Amy Lu wrote: > Please review the patch to problem list > tools/jimage/JImageExtractTest.java for macosx-all. > > This test fails frequently (observed at Mac) and should be problem > listed before?JDK-8198819?fixed. > > bug: https://bugs.openjdk.java.net/browse/JDK-8198820 > webrev: http://cr.openjdk.java.net/~amlu/8198820/webrev.00/ This looks okay, also no objection to excluding it on all platforms as it is seems to fail periodically on Solaris too. -Alan From amy.lu at oracle.com Wed Feb 28 11:29:58 2018 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 28 Feb 2018 19:29:58 +0800 Subject: [JDK 11] Problem list tools/jimage/JImageExtractTest.java for macosx-all In-Reply-To: <299dc67c-c0c7-38d6-3728-9d82ff509fc1@oracle.com> References: <7e1205c3-c185-a854-7983-e88befd63bd1@oracle.com> <299dc67c-c0c7-38d6-3728-9d82ff509fc1@oracle.com> Message-ID: <366fbae0-4dd7-b15b-6717-c0aa6e93dc11@oracle.com> On 28/02/2018 6:23 PM, Alan Bateman wrote: > > > On 28/02/2018 08:53, Amy Lu wrote: >> Please review the patch to problem list >> tools/jimage/JImageExtractTest.java for macosx-all. >> >> This test fails frequently (observed at Mac) and should be problem >> listed before?JDK-8198819?fixed. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8198820 >> webrev: http://cr.openjdk.java.net/~amlu/8198820/webrev.00/ > This looks okay, also no objection to excluding it on all platforms as > it is seems to fail periodically on Solaris too. Thank you Alan! Changed to problem list for generic-all and pushed. Thanks, Amy > > -Alan