From kasperni at gmail.com Wed Jan 8 11:14:30 2020 From: kasperni at gmail.com (Kasper Nielsen) Date: Wed, 8 Jan 2020 11:14:30 +0000 Subject: Lookup objects and setAccessible Message-ID: Hi, I'm trying to bridge some old code using java.lang.reflect and some new code that uses Lookup objects. And I'm wondering if there is some way to make a member accessible using a Lookup object? Or if open packages/modules via module-info.java + member.setAccessible(true) is the only way? Thanks Kasper From forax at univ-mlv.fr Wed Jan 8 11:52:03 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 8 Jan 2020 12:52:03 +0100 (CET) Subject: Lookup objects and setAccessible In-Reply-To: References: Message-ID: <640682346.1462936.1578484323663.JavaMail.zimbra@u-pem.fr> see https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/invoke/MethodHandles.html#privateLookupIn(java.lang.Class,java.lang.invoke.MethodHandles.Lookup) R?mi ----- Mail original ----- > De: "Kasper Nielsen" > ?: "jigsaw-dev" > Envoy?: Mercredi 8 Janvier 2020 12:14:30 > Objet: Lookup objects and setAccessible > Hi, > > I'm trying to bridge some old code using java.lang.reflect and some new code > that uses Lookup objects. And I'm wondering if there is some way to make > a member accessible using a Lookup object? Or if open packages/modules via > module-info.java + member.setAccessible(true) is the only way? > > Thanks > Kasper From kasperni at gmail.com Wed Jan 8 13:49:25 2020 From: kasperni at gmail.com (Kasper Nielsen) Date: Wed, 8 Jan 2020 13:49:25 +0000 Subject: Lookup objects and setAccessible In-Reply-To: <640682346.1462936.1578484323663.JavaMail.zimbra@u-pem.fr> References: <640682346.1462936.1578484323663.JavaMail.zimbra@u-pem.fr> Message-ID: Sorry, I could have been a bit more specific. I meant something like Method.setAccessible(Lookup, true) I want to base an API on lookup objects. But I want to still support some use cases where people rely on java.lang.reflect.Field|Constructor|Method. Specifically, being able to create an Executable that can be instantiated/invoked. So I'm looking for a way to make members (Field|Constructor|Method) accessible in some way using a Lookup object. Obviously, this would not be a problem if my API relied on open packages/modules via module-info.java and member.setAccessible(true) instead of using Lookup objects. /Kasper On Wed, 8 Jan 2020 at 12:11, Remi Forax wrote: > > see https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/invoke/MethodHandles.html#privateLookupIn(java.lang.Class,java.lang.invoke.MethodHandles.Lookup) > > R?mi > > ----- Mail original ----- > > De: "Kasper Nielsen" > > ?: "jigsaw-dev" > > Envoy?: Mercredi 8 Janvier 2020 12:14:30 > > Objet: Lookup objects and setAccessible > > > Hi, > > > > I'm trying to bridge some old code using java.lang.reflect and some new code > > that uses Lookup objects. And I'm wondering if there is some way to make > > a member accessible using a Lookup object? Or if open packages/modules via > > module-info.java + member.setAccessible(true) is the only way? > > > > Thanks > > Kasper From mandy.chung at oracle.com Wed Jan 8 19:25:32 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 8 Jan 2020 11:25:32 -0800 Subject: Lookup objects and setAccessible In-Reply-To: References: <640682346.1462936.1578484323663.JavaMail.zimbra@u-pem.fr> Message-ID: Have you looked at Lookup::revealDirect and MethodHandleInfo::reflectAs? Mandy On 1/8/20 5:49 AM, Kasper Nielsen wrote: > Sorry, I could have been a bit more specific. I meant something like > Method.setAccessible(Lookup, true) > > I want to base an API on lookup objects. But I want to still support some use > cases where people rely on java.lang.reflect.Field|Constructor|Method. > Specifically, being able to create an Executable that can be > instantiated/invoked. So I'm looking for a way to make members > (Field|Constructor|Method) accessible in some way using a Lookup object. > > Obviously, this would not be a problem if my API relied on open > packages/modules via module-info.java and member.setAccessible(true) > instead of using Lookup objects. > > /Kasper > > On Wed, 8 Jan 2020 at 12:11, Remi Forax wrote: >> see https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/invoke/MethodHandles.html#privateLookupIn(java.lang.Class,java.lang.invoke.MethodHandles.Lookup) >> >> R?mi >> >> ----- Mail original ----- >>> De: "Kasper Nielsen" >>> ?: "jigsaw-dev" >>> Envoy?: Mercredi 8 Janvier 2020 12:14:30 >>> Objet: Lookup objects and setAccessible >>> Hi, >>> >>> I'm trying to bridge some old code using java.lang.reflect and some new code >>> that uses Lookup objects. And I'm wondering if there is some way to make >>> a member accessible using a Lookup object? Or if open packages/modules via >>> module-info.java + member.setAccessible(true) is the only way? >>> >>> Thanks >>> Kasper From kasperni at gmail.com Wed Jan 8 19:43:06 2020 From: kasperni at gmail.com (Kasper Nielsen) Date: Wed, 8 Jan 2020 19:43:06 +0000 Subject: Lookup objects and setAccessible In-Reply-To: References: <640682346.1462936.1578484323663.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Mandy, Yes, but they create a member which is not accessible. As far as I can see, all places where AccessibleObject.override is ever set there is a check of the current caller with Reflection.getCallerClass(). /Kasper On Wed, 8 Jan 2020 at 19:25, Mandy Chung wrote: > > Have you looked at Lookup::revealDirect and MethodHandleInfo::reflectAs? > > Mandy > From mandy.chung at oracle.com Thu Jan 9 02:28:27 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 8 Jan 2020 18:28:27 -0800 Subject: (14) RFR JDK-8229396: jdeps ignores multi-release when generate-module-info used on command line Message-ID: <95cb8da2-be51-1879-bd6e-ba8fbe803255@oracle.com> Webrev: http://cr.openjdk.java.net/~mchung/jdk14/8229396/webrev.00/index.html This fixes jdeps --generate-module-info option to read a multi-release JAR with the version specified at --multi-release option.? Also it enhances jdeps to report missing dependences as other options such as --list-deps. Thanks Mandy From mandy.chung at oracle.com Thu Jan 9 03:42:51 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 8 Jan 2020 19:42:51 -0800 Subject: (14) RFR JDK-8225773: jdeps --check produces NPE if there are missing module dependences Message-ID: Webrev: ?? http://cr.openjdk.java.net/~mchung/jdk14/8225773/webrev.00/ jdeps --check throws NPE when the module descriptor has missing dependences.? This patch fixes jdeps --check option to report a module with missing dependences as other jdeps options. This patch applies on the top of the patch for JDK-8229396 [1]. Thanks Mandy [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2020-January/014342.html From sundararajan.athijegannathan at oracle.com Thu Jan 9 09:34:26 2020 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 9 Jan 2020 15:04:26 +0530 Subject: RFR 8225561: jlink --help doesn't state that ALL-MODULE-PATH is accepted for --add-modules Message-ID: Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8225561 Webrev: http://cr.openjdk.java.net/~sundar/8225561/webrev.00/ Thanks -Sundar From Alan.Bateman at oracle.com Thu Jan 9 11:27:18 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 9 Jan 2020 11:27:18 +0000 Subject: (14) RFR JDK-8225773: jdeps --check produces NPE if there are missing module dependences In-Reply-To: References: Message-ID: On 09/01/2020 03:42, Mandy Chung wrote: > Webrev: > ?? http://cr.openjdk.java.net/~mchung/jdk14/8225773/webrev.00/ > > jdeps --check throws NPE when the module descriptor has missing > dependences.? This patch fixes jdeps --check option to report a module > with missing dependences as other jdeps options. > > This patch applies on the top of the patch for JDK-8229396 [1]. JDK-8229396 will take a bit time to review but the change for JDK-8225773 looks fine. -Alan From Alan.Bateman at oracle.com Thu Jan 9 11:30:03 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 9 Jan 2020 11:30:03 +0000 Subject: RFR 8225561: jlink --help doesn't state that ALL-MODULE-PATH is accepted for --add-modules In-Reply-To: References: Message-ID: On 09/01/2020 09:34, sundararajan.athijegannathan at oracle.com wrote: > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8225561 > > Webrev: http://cr.openjdk.java.net/~sundar/8225561/webrev.00/ The usage message doesn't attempt to explain what ALL-MODULE-PATH means but it is consistent with the usage message of the java launcher so I think it's okay (rather than trying to defining it to mean all observable modules on the module path - the java launcher usage message should lead on the description rather than jlink). -Alan. From sundararajan.athijegannathan at oracle.com Fri Jan 10 06:03:25 2020 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 10 Jan 2020 11:33:25 +0530 Subject: RFR 8222098: tools/jlink/plugins/IncludeLocalesPluginTest.java time out Message-ID: <8365cb46-a88f-0642-94a8-7e3acdd09770@oracle.com> Please review. Not really a fix - but increasing the default timeout for the test. Bug: https://bugs.openjdk.java.net/browse/JDK-8222098 Webrev: http://cr.openjdk.java.net/~sundar/8222098/webrev.00/ Thanks, -Sundar From sormuras at gmail.com Fri Jan 10 10:52:24 2020 From: sormuras at gmail.com (Christian Stein) Date: Fri, 10 Jan 2020 11:52:24 +0100 Subject: javac/jdeps and requires with version Message-ID: Hi, given an empty module declaration: module foo{} Compile it with javac using various valid "--release r" variants yields different module descriptors in addition to the generated class file version. For JDK N, javac seems to include the version of a required module only if you omit the release option or if you pass r = N. For example, when having JDK 13.0.1 installed, the String representation of module foo is: module { name: foo, [mandated java.base (@13.0.1)] } For every r value with 9 <= r < N it only reads: module { name: foo, [mandated java.base] } What is the reason for this behaviour regarding compiled version of requires directives? Find the log of a MVE [1] at [2]. Additionally, I checked the following tools: - "jdeps" also emits the version of "java.base" - "jar --describe-module" does not emit the version of "java.base" - "javap" does not emit the version of "java.base" A side(?) effect of this can also be seen at [3], which shows the result of running jdeps --check org.junit.platform.engine. The only difference of the actual and the suggested module descriptor are the versions attached to the requires elements. Cheers, Christian [1]: https://github.com/sormuras/sandbox/tree/master/java-compiled-versions [2]: https://github.com/sormuras/sandbox/runs/383114037 [3]: https://github.com/junit-team/junit5/issues/2063#issuecomment-567015570 From sundararajan.athijegannathan at oracle.com Fri Jan 10 13:07:13 2020 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 10 Jan 2020 18:37:13 +0530 Subject: RFR 8222098: tools/jlink/plugins/IncludeLocalesPluginTest.java time out In-Reply-To: <8365cb46-a88f-0642-94a8-7e3acdd09770@oracle.com> References: <8365cb46-a88f-0642-94a8-7e3acdd09770@oracle.com> Message-ID: <71aa064c-cb35-5c98-3400-b7fc1225313e@oracle.com> Adding core-libs-dev. -Sundar On 10/01/20 11:33 am, sundararajan.athijegannathan at oracle.com wrote: > Please review. > > Not really a fix - but increasing the default timeout for the test. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222098 > > Webrev: http://cr.openjdk.java.net/~sundar/8222098/webrev.00/ > > Thanks, > > -Sundar > From james.laskey at oracle.com Fri Jan 10 13:32:45 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Fri, 10 Jan 2020 09:32:45 -0400 Subject: RFR 8222098: tools/jlink/plugins/IncludeLocalesPluginTest.java time out In-Reply-To: <8365cb46-a88f-0642-94a8-7e3acdd09770@oracle.com> References: <8365cb46-a88f-0642-94a8-7e3acdd09770@oracle.com> Message-ID: <0044B474-C75D-4D4F-937E-42EDBF213FC6@oracle.com> +1 > On Jan 10, 2020, at 2:03 AM, sundararajan.athijegannathan at oracle.com wrote: > > Please review. > > Not really a fix - but increasing the default timeout for the test. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222098 > > Webrev: http://cr.openjdk.java.net/~sundar/8222098/webrev.00/ > > Thanks, > > -Sundar > From naoto.sato at oracle.com Fri Jan 10 13:50:16 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 10 Jan 2020 05:50:16 -0800 Subject: RFR 8222098: tools/jlink/plugins/IncludeLocalesPluginTest.java time out In-Reply-To: <71aa064c-cb35-5c98-3400-b7fc1225313e@oracle.com> References: <8365cb46-a88f-0642-94a8-7e3acdd09770@oracle.com> <71aa064c-cb35-5c98-3400-b7fc1225313e@oracle.com> Message-ID: Hi Sundar, You might want to add the bug id in the regression test, and change the copyright year to 2020. Otherwise, looks good. Naoto On 1/10/20 5:07 AM, sundararajan.athijegannathan at oracle.com wrote: > Adding core-libs-dev. > > -Sundar > > On 10/01/20 11:33 am, sundararajan.athijegannathan at oracle.com wrote: >> Please review. >> >> Not really a fix - but increasing the default timeout for the test. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8222098 >> >> Webrev: http://cr.openjdk.java.net/~sundar/8222098/webrev.00/ >> >> Thanks, >> >> -Sundar >> From Alan.Bateman at oracle.com Fri Jan 10 15:09:58 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Jan 2020 15:09:58 +0000 Subject: (14) RFR JDK-8229396: jdeps ignores multi-release when generate-module-info used on command line In-Reply-To: <95cb8da2-be51-1879-bd6e-ba8fbe803255@oracle.com> References: <95cb8da2-be51-1879-bd6e-ba8fbe803255@oracle.com> Message-ID: On 09/01/2020 02:28, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk14/8229396/webrev.00/index.html > > This fixes jdeps --generate-module-info option to read > a multi-release JAR with the version specified at --multi-release > option.? Also it enhances jdeps to report missing dependences as > other options such as --list-deps. I think this looks okay but one thing to check is "dependencies" vs "dependences" in the error messages. I know I've got that wrong several times so I might not be the best person to check that point. -Alan. From mandy.chung at oracle.com Fri Jan 10 17:39:44 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 10 Jan 2020 09:39:44 -0800 Subject: (14) RFR JDK-8229396: jdeps ignores multi-release when generate-module-info used on command line In-Reply-To: References: <95cb8da2-be51-1879-bd6e-ba8fbe803255@oracle.com> Message-ID: On 1/10/20 7:09 AM, Alan Bateman wrote: > On 09/01/2020 02:28, Mandy Chung wrote: >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk14/8229396/webrev.00/index.html >> >> This fixes jdeps --generate-module-info option to read >> a multi-release JAR with the version specified at --multi-release >> option.? Also it enhances jdeps to report missing dependences as >> other options such as --list-deps. > I think this looks okay but one thing to check is "dependencies" vs > "dependences" in the error messages. I know I've got that wrong > several times so I might not be the best person to check that point. Thanks. This patch has these warning/error messages: ? "Missing dependencies from m are ignored" ? "Missing dependencies: classes not found from the module path." Any better/correct message? Or I can fix them in the future. Mandy From sundararajan.athijegannathan at oracle.com Mon Jan 13 02:50:56 2020 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 13 Jan 2020 08:20:56 +0530 Subject: RFR 8222098: tools/jlink/plugins/IncludeLocalesPluginTest.java time out In-Reply-To: References: <8365cb46-a88f-0642-94a8-7e3acdd09770@oracle.com> <71aa064c-cb35-5c98-3400-b7fc1225313e@oracle.com> Message-ID: Hi Naoto, Thanks. I'll make those changes and push. -Sundar On 10/01/20 7:20 pm, naoto.sato at oracle.com wrote: > Hi Sundar, > > You might want to add the bug id in the regression test, and change > the copyright year to 2020. > > Otherwise, looks good. > > Naoto > > On 1/10/20 5:07 AM, sundararajan.athijegannathan at oracle.com wrote: >> Adding core-libs-dev. >> >> -Sundar >> >> On 10/01/20 11:33 am, sundararajan.athijegannathan at oracle.com wrote: >>> Please review. >>> >>> Not really a fix - but increasing the default timeout for the test. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222098 >>> >>> Webrev: http://cr.openjdk.java.net/~sundar/8222098/webrev.00/ >>> >>> Thanks, >>> >>> -Sundar >>> From sundararajan.athijegannathan at oracle.com Mon Jan 13 14:25:04 2020 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 13 Jan 2020 19:55:04 +0530 Subject: RFR 8222100: tools/jimage/JImageTest.java time out Message-ID: Bumping the default timeout (other tests in the same dir have similar timeout settings). Bug: https://bugs.openjdk.java.net/browse/JDK-8222100 Webrev: http://cr.openjdk.java.net/~sundar/8222100/webrev.00/ Thanks, -Sundar From james.laskey at oracle.com Mon Jan 13 14:29:09 2020 From: james.laskey at oracle.com (James Laskey) Date: Mon, 13 Jan 2020 10:29:09 -0400 Subject: RFR 8222100: tools/jimage/JImageTest.java time out In-Reply-To: References: Message-ID: <2D287495-0C18-41A5-9823-366F17E32736@oracle.com> +1 On the road. > On Jan 13, 2020, at 10:25 AM, sundararajan.athijegannathan at oracle.com wrote: > > ?Bumping the default timeout (other tests in the same dir have similar timeout settings). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222100 > > Webrev: http://cr.openjdk.java.net/~sundar/8222100/webrev.00/ > > Thanks, > > -Sundar >