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: <CAPs61523y_sRYiiPhzir3XXMQDKjdceUKP2kDc9TeQaSF48otg@mail.gmail.com>

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: <CAPs61523y_sRYiiPhzir3XXMQDKjdceUKP2kDc9TeQaSF48otg@mail.gmail.com>
References: <CAPs61523y_sRYiiPhzir3XXMQDKjdceUKP2kDc9TeQaSF48otg@mail.gmail.com>
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" <kasperni at gmail.com>
> ?: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> 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: <CAPs61523y_sRYiiPhzir3XXMQDKjdceUKP2kDc9TeQaSF48otg@mail.gmail.com>
 <640682346.1462936.1578484323663.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAPs6150UZqS5Y+pnD=GzySM6+=bVMvjU=KCBgtttrzg-pzeiaA@mail.gmail.com>

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 <forax at univ-mlv.fr> 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" <kasperni at gmail.com>
> > ?: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> > 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: <CAPs6150UZqS5Y+pnD=GzySM6+=bVMvjU=KCBgtttrzg-pzeiaA@mail.gmail.com>
References: <CAPs61523y_sRYiiPhzir3XXMQDKjdceUKP2kDc9TeQaSF48otg@mail.gmail.com>
 <640682346.1462936.1578484323663.JavaMail.zimbra@u-pem.fr>
 <CAPs6150UZqS5Y+pnD=GzySM6+=bVMvjU=KCBgtttrzg-pzeiaA@mail.gmail.com>
Message-ID: <c0588998-a25f-e2d3-c709-1cdce774bc79@oracle.com>

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 <forax at univ-mlv.fr> 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" <kasperni at gmail.com>
>>> ?: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
>>> 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: <c0588998-a25f-e2d3-c709-1cdce774bc79@oracle.com>
References: <CAPs61523y_sRYiiPhzir3XXMQDKjdceUKP2kDc9TeQaSF48otg@mail.gmail.com>
 <640682346.1462936.1578484323663.JavaMail.zimbra@u-pem.fr>
 <CAPs6150UZqS5Y+pnD=GzySM6+=bVMvjU=KCBgtttrzg-pzeiaA@mail.gmail.com>
 <c0588998-a25f-e2d3-c709-1cdce774bc79@oracle.com>
Message-ID: <CAPs6153L5XvZrM+_AAq3kc1GTpLMV=Q64pJjc3=JVOCBKSj5ZA@mail.gmail.com>

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 <mandy.chung at oracle.com> 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: <fab40629-6707-b701-242b-2c0e4286f51e@oracle.com>

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: <eba3c48e-344a-777c-8abd-180eb20720e1@oracle.com>

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: <fab40629-6707-b701-242b-2c0e4286f51e@oracle.com>
References: <fab40629-6707-b701-242b-2c0e4286f51e@oracle.com>
Message-ID: <b39ba6d8-eb11-1a83-288b-ca500887faf1@oracle.com>

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: <eba3c48e-344a-777c-8abd-180eb20720e1@oracle.com>
References: <eba3c48e-344a-777c-8abd-180eb20720e1@oracle.com>
Message-ID: <c3a147f0-eba6-6e0a-84e5-f6fc186a71a0@oracle.com>

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: <CAJi8+g5SfSAyV9rDzziu=epv6r6hF7wRffn+Ar37CgkqPdczsw@mail.gmail.com>

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: <ad7d3204-c3d7-9378-9a8e-6463a828e1e8@oracle.com>

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: <e92f2351-a76d-d690-1193-c8d52f1fd6b1@oracle.com>

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: <e92f2351-a76d-d690-1193-c8d52f1fd6b1@oracle.com>
References: <95cb8da2-be51-1879-bd6e-ba8fbe803255@oracle.com>
 <e92f2351-a76d-d690-1193-c8d52f1fd6b1@oracle.com>
Message-ID: <a3d60abd-bfe0-6a15-d056-1bf9f3769b21@oracle.com>



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: <ad7d3204-c3d7-9378-9a8e-6463a828e1e8@oracle.com>
References: <8365cb46-a88f-0642-94a8-7e3acdd09770@oracle.com>
 <71aa064c-cb35-5c98-3400-b7fc1225313e@oracle.com>
 <ad7d3204-c3d7-9378-9a8e-6463a828e1e8@oracle.com>
Message-ID: <be8898da-7607-6058-2dac-bd48561b36dd@oracle.com>

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: <dddb1a1f-0279-7e48-0a9b-a2a48753ac40@oracle.com>

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: <dddb1a1f-0279-7e48-0a9b-a2a48753ac40@oracle.com>
References: <dddb1a1f-0279-7e48-0a9b-a2a48753ac40@oracle.com>
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
>