trySetAccessible​

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

trySetAccessible​

Jochen Theodorou
Hi all,

since the JVM now prints warnings if you call setAccssible there was the
advise to move to trySetAccessible​ to prvent these warnings. Now I am
told those warnings appear here as well.

Now my question would be about what the intended behaviour here is. in
what mode is a trySetAccessible​ supposed to cause the JVM to issue a
warning or other message about a module accessing something?

And if the warnings are the intended behaviour, then what is the way to
avoid this if I cannot just stop trying?

bye Jochen
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: trySetAccessible​

Stephen Felts
I have asked for a mechanism to avoid the warnings multiple times and there is no way to do it.

That's unfortunate because there are multiple projects that have been modified to work with JDK9 and they still produce a warning.

I have resorted to keeping a list of known warnings that are OK (currently at 10).

Here are a few public (non-Oracle) ones:

 

org.python.core.PyJavaClass

com.sun.xml.bind.v2.runtime.reflect.opt.Injector

com.sun.xml.ws.model.Injector

net.sf.cglib.core.ReflectUtils$

 

 

-----Original Message-----
From: Jochen Theodorou [mailto:[hidden email]]
Sent: Sunday, July 9, 2017 7:17 PM
To: [hidden email]
Subject: trySetAccessible​

 

Hi all,

 

since the JVM now prints warnings if you call setAccssible there was the advise to move to trySetAccessible​ to prvent these warnings. Now I am told those warnings appear here as well.

 

Now my question would be about what the intended behaviour here is. in what mode is a trySetAccessible​ supposed to cause the JVM to issue a warning or other message about a module accessing something?

 

And if the warnings are the intended behaviour, then what is the way to avoid this if I cannot just stop trying?

 

bye Jochen

 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: trySetAccessible​

Alan Bateman
In reply to this post by Jochen Theodorou
On 10/07/2017 00:16, Jochen Theodorou wrote:
> Hi all,
>
> since the JVM now prints warnings if you call setAccssible there was
> the advise to move to trySetAccessible​ to prvent these warnings.
The motivation for trySetAccessible is to avoid using exceptions for
control flow. I don't recall any suggestion here to use it as a way to
avoid warnings.

Remember the purpose of the warnings is to make you or your users aware
that the code will behave differently when access to JDK internals, or
other so-called illegal access, is denied.

-Alan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: trySetAccessible​

Alan Bateman
In reply to this post by Stephen Felts
On 10/07/2017 03:28, Stephen Felts wrote:
> :
>
> com.sun.xml.bind.v2.runtime.reflect.opt.Injector
>
> com.sun.xml.ws.model.Injector
>
 From what I can tell, these two aren't using tryAccessible. Instead
they seem to use setAccessible to attempt to get at a non-public
ClassLoader.defineClass method. It succeeds, with a warning, because
java.lang is open. If it were to fail then they catch
InaccessibleObjectException and try the deprecated-for-removal
Unsafe.defineClass. These two seem like good candidates for
Lookup.defineClass.

-Alan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: trySetAccessible​

Uwe Schindler
In reply to this post by Alan Bateman
Hi Alan,

I was trying to fix Groovy to use trySetAccessible() instead of setAccessible() and this did not change any warnings at all: The code can be found here:

https://github.com/apache/groovy/compare/master...uschindler:java9/trySetAccessible

It did not change anything. In fact, the code behaved as it did before - no change at all! Warnings are almost the same (actually worse, because of how I did it using MethodHandles, see bwlow). It also granted full access, like the usual call to setAccessible()!

As Jochen said:

> Now I am told those warnings appear here as well.

I was the one who told it to him indirectly... because I tried to fix it for Groovy with the above code change!

It granted access to internal API as it did before and it also printed the warning - so the new API was identicak to a simple call to setAccessible. Why is the new AI there at all, setAccessible did the same. And an if/then/else vs. a try/catch is not really different! Sorry, I expected trySetAccesible() to behave differently: As this is a *new* API in Java 9, I would have expected that the "big kill switch" does not affect this! So when calling this new API, I would have expected that it would behave as follows:

- It would *not* grant access to internal APIs, as specified in the Java 9 spec and the module system. As the API is new, there s no need for it to respect the "big kill switch" aka "permit-illegal-access".
- It would not print a warning at all!

In fact the new code in the above patch to Groovy was much more confusing, as the warning was suddenly printed by a JDK-internal class - which is a bug IMHO: The JDK printed a warning like this:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.codehaus.groovy.reflection.InjectedInvoker/1364880320 (file:/C:/Users/Uwe%20Schindler/Projects/groovy/target/classes/java/main/) to method java.lang.Object.finalize()
WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.reflection.InjectedInvoker/1364880320
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

This came from the fact, that the internal wrapper of the MethodHandle, which was created by the call to trySetAccessible() using a MethodHandle. I suppose it was used to make the caller-sensitive stuff work correctly. So I was baffled, because the warning was not really helpful anymore! The class mentioned here does not even exist anywhere!!! ☹

Uwe

-----
Uwe Schindler
[hidden email]
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/

> -----Original Message-----
> From: jigsaw-dev [mailto:[hidden email]] On Behalf
> Of Alan Bateman
> Sent: Monday, July 10, 2017 10:07 AM
> To: Jochen Theodorou <[hidden email]>; [hidden email]
> Subject: Re: trySetAccessible​
>
> On 10/07/2017 00:16, Jochen Theodorou wrote:
> > Hi all,
> >
> > since the JVM now prints warnings if you call setAccssible there was
> > the advise to move to trySetAccessible​ to prvent these warnings.
> The motivation for trySetAccessible is to avoid using exceptions for
> control flow. I don't recall any suggestion here to use it as a way to
> avoid warnings.
>
> Remember the purpose of the warnings is to make you or your users aware
> that the code will behave differently when access to JDK internals, or
> other so-called illegal access, is denied.
>
> -Alan

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: trySetAccessible​

Cédric Champeau
I second Uwe's comment here: I was surprised as well, I expected the
semantics of `trySetAccessible` to be: "let me know if I can do this,
respecting the semantics of modules, and if not, return false"

2017-07-10 10:43 GMT+02:00 Uwe Schindler <[hidden email]>:

> Hi Alan,
>
> I was trying to fix Groovy to use trySetAccessible() instead of
> setAccessible() and this did not change any warnings at all: The code can
> be found here:
>
> https://github.com/apache/groovy/compare/master...uschindler:java9/
> trySetAccessible
>
> It did not change anything. In fact, the code behaved as it did before -
> no change at all! Warnings are almost the same (actually worse, because of
> how I did it using MethodHandles, see bwlow). It also granted full access,
> like the usual call to setAccessible()!
>
> As Jochen said:
>
> > Now I am told those warnings appear here as well.
>
> I was the one who told it to him indirectly... because I tried to fix it
> for Groovy with the above code change!
>
> It granted access to internal API as it did before and it also printed the
> warning - so the new API was identicak to a simple call to setAccessible.
> Why is the new AI there at all, setAccessible did the same. And an
> if/then/else vs. a try/catch is not really different! Sorry, I expected
> trySetAccesible() to behave differently: As this is a *new* API in Java 9,
> I would have expected that the "big kill switch" does not affect this! So
> when calling this new API, I would have expected that it would behave as
> follows:
>
> - It would *not* grant access to internal APIs, as specified in the Java 9
> spec and the module system. As the API is new, there s no need for it to
> respect the "big kill switch" aka "permit-illegal-access".
> - It would not print a warning at all!
>
> In fact the new code in the above patch to Groovy was much more confusing,
> as the warning was suddenly printed by a JDK-internal class - which is a
> bug IMHO: The JDK printed a warning like this:
>
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.codehaus.groovy.
> reflection.InjectedInvoker/1364880320 (file:/C:/Users/Uwe%
> 20Schindler/Projects/groovy/target/classes/java/main/) to method
> java.lang.Object.finalize()
> WARNING: Please consider reporting this to the maintainers of
> org.codehaus.groovy.reflection.InjectedInvoker/1364880320
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
>
> This came from the fact, that the internal wrapper of the MethodHandle,
> which was created by the call to trySetAccessible() using a MethodHandle. I
> suppose it was used to make the caller-sensitive stuff work correctly. So I
> was baffled, because the warning was not really helpful anymore! The class
> mentioned here does not even exist anywhere!!! ☹
>
> Uwe
>
> -----
> Uwe Schindler
> [hidden email]
> ASF Member, Apache Lucene PMC / Committer
> Bremen, Germany
> http://lucene.apache.org/
>
> > -----Original Message-----
> > From: jigsaw-dev [mailto:[hidden email]] On Behalf
> > Of Alan Bateman
> > Sent: Monday, July 10, 2017 10:07 AM
> > To: Jochen Theodorou <[hidden email]>; [hidden email]
> > Subject: Re: trySetAccessible​
> >
> > On 10/07/2017 00:16, Jochen Theodorou wrote:
> > > Hi all,
> > >
> > > since the JVM now prints warnings if you call setAccssible there was
> > > the advise to move to trySetAccessible​ to prvent these warnings.
> > The motivation for trySetAccessible is to avoid using exceptions for
> > control flow. I don't recall any suggestion here to use it as a way to
> > avoid warnings.
> >
> > Remember the purpose of the warnings is to make you or your users aware
> > that the code will behave differently when access to JDK internals, or
> > other so-called illegal access, is denied.
> >
> > -Alan
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: trySetAccessible​

Jochen Theodorou


On 10.07.2017 10:49, Cédric Champeau wrote:
> I second Uwe's comment here: I was surprised as well, I expected the
> semantics of `trySetAccessible` to be: "let me know if I can do this,
> respecting the semantics of modules, and if not, return false"

I suspect canAccess is supposed to be used here... of course the
semantics of that method are not enough for us.

bye Jochen
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: trySetAccessible​

Jochen Theodorou
In reply to this post by Alan Bateman


On 10.07.2017 10:07, Alan Bateman wrote:
[...]
> Remember the purpose of the warnings is to make you or your users aware
> that the code will behave differently when access to JDK internals, or
> other so-called illegal access, is denied.

In the past we did create a MetaClass, which contains all the accessible
methods and properties. This meta class is used for method selection
during invocation, it is used for querying and for runtime meta
programming.

These warnings now force us to change the semantics and not show the
accessible methods, but all methods. Invocation will then have to make
it accessible... something we moved to meta class creation because it
slows down the invocation mechanism. And then we will still get false
warnings in reflective code.

Example:

module A:

class Foo {
   protected void foo(){}
}

Groovy program:

class X extends Foo {
   def bar() {return {foo()}}
}

if Foo is in an exported package, then it is legal for X to call foo,
even though it is protected. But bar() does not directly call foo, it
will do so in a Closure (not functional closure, not lambdas). In a
Closure the implicit this has no fixed meaning and is realized as
anonymous inner class. With our current protocol the call to foo ends up
in the meta class logic, which then executes the method call. This will
then cause a warning "WARNING: An illegal reflective access operation
has occurred".

Now tell me how this is useful for the user. The call is supposed to be
legal after all. Still we will get a warning. How am I supposed to tell
our users about correct and wrong warnings?

Of course I am aware that I am supposed to give in a Lookup object and
return a MethodHandle instead. But without changes to the MOP API this
cannot be done. And that means Groovy 1.0 code will, for the first time
in our history, no longer really work on a new Groovy version, once this
change is done. And here I am not even sure that "giving in the Lookup
object" is really what I should do. This Lookup object would have full
access to X after all (I need to be able to call private methods too you
know). And that does not sound right either

bye Jochen
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: trySetAccessible​

Alan Bateman
In reply to this post by Cédric Champeau
On 10/07/2017 09:49, Cédric Champeau wrote:
> I second Uwe's comment here: I was surprised as well, I expected the
> semantics of `trySetAccessible` to be: "let me know if I can do this,
> respecting the semantics of modules, and if not, return false"
For the example, trySetAccessible succeeds (returns `true`) because
`java.lang` is open.  If you run with `--illegal-access=deny` then
`java.lang` will not be opened and trySetAccessible should return `false`.

-Alan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: trySetAccessible​

Stephen Felts
Right.
We need an API that returns false with no warning.


-----Original Message-----
From: Alan Bateman
Sent: Monday, July 10, 2017 5:56 AM
To: Cédric Champeau
Cc: jigsaw-dev
Subject: Re: trySetAccessible​

On 10/07/2017 09:49, Cédric Champeau wrote:
> I second Uwe's comment here: I was surprised as well, I expected the
> semantics of `trySetAccessible` to be: "let me know if I can do this,
> respecting the semantics of modules, and if not, return false"
For the example, trySetAccessible succeeds (returns `true`) because `java.lang` is open.  If you run with `--illegal-access=deny` then `java.lang` will not be opened and trySetAccessible should return `false`.

-Alan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: trySetAccessible​

Cédric Champeau
In reply to this post by Alan Bateman
This is not really practical. Basically it means that for every Gradle
build script on earth, we would either choose to make them fail on JDK 9,
or be bloated with warnings, that are actually handled.

2017-07-10 11:55 GMT+02:00 Alan Bateman <[hidden email]>:

> On 10/07/2017 09:49, Cédric Champeau wrote:
>
>> I second Uwe's comment here: I was surprised as well, I expected the
>> semantics of `trySetAccessible` to be: "let me know if I can do this,
>> respecting the semantics of modules, and if not, return false"
>>
> For the example, trySetAccessible succeeds (returns `true`) because
> `java.lang` is open.  If you run with `--illegal-access=deny` then
> `java.lang` will not be opened and trySetAccessible should return `false`.
>
> -Alan
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: trySetAccessible​

Alan Bateman
In reply to this post by Uwe Schindler
On 10/07/2017 09:43, Uwe Schindler wrote:
> Hi Alan,
>
> I was trying to fix Groovy to use trySetAccessible() instead of setAccessible() and this did not change any warnings at all: The code can be found here:
>
> https://github.com/apache/groovy/compare/master...uschindler:java9/trySetAccessible
>
> It did not change anything. In fact, the code behaved as it did before - no change at all! Warnings are almost the same (actually worse, because of how I did it using MethodHandles, see bwlow). It also granted full access, like the usual call to setAccessible()!
This is because the java.lang package is open at runtime in JDK 9. Once
open then you can use both old and new APIs to do so-called "deep
reflection" on members of all classes in the package.

-Alan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: trySetAccessible​

Alan Bateman
In reply to this post by Cédric Champeau
On 10/07/2017 10:59, Cédric Champeau wrote:
> This is not really practical. Basically it means that for every Gradle
> build script on earth, we would either choose to make them fail on JDK
> 9, or be bloated with warnings, that are actually handled.
My mail was just explaining why it returns `true`.

The right way to get rid of these warnings is to fix the underlying issues.

-Alan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: trySetAccessible​

Jochen Theodorou


On 10.07.2017 12:06, Alan Bateman wrote:
> On 10/07/2017 10:59, Cédric Champeau wrote:
>> This is not really practical. Basically it means that for every Gradle
>> build script on earth, we would either choose to make them fail on JDK
>> 9, or be bloated with warnings, that are actually handled.
> My mail was just explaining why it returns `true`.
>
> The right way to get rid of these warnings is to fix the underlying issues.

see my other mail

bye Jochen
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: trySetAccessible​

Alan Bateman
In reply to this post by Jochen Theodorou
On 10/07/2017 10:44, Jochen Theodorou wrote:

> :
>
> Example:
>
> module A:
>
> class Foo {
>   protected void foo(){}
> }
>
> Groovy program:
>
> class X extends Foo {
>   def bar() {return {foo()}}
> }
>
> if Foo is in an exported package, then it is legal for X to call foo,
> even though it is protected. But bar() does not directly call foo, it
> will do so in a Closure (not functional closure, not lambdas).
and therein is the issue because protected members should only be
accessible in the sub-class (or same package).

> In a Closure the implicit this has no fixed meaning and is realized as
> anonymous inner class. With our current protocol the call to foo ends
> up in the meta class logic, which then executes the method call. This
> will then cause a warning "WARNING: An illegal reflective access
> operation has occurred".
Do you have any control on the code that is generated for X?

-Alan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: trySetAccessible​

Uwe Schindler
In reply to this post by Alan Bateman
Hi Alan,

we understand all this. But what you say is also not true. I started a second approach to fix the issue by using canAccess() and also checking the module stuff. For that I executed the following code on the Groovy unnamed module:

import org.codehaus.groovy.reflection.CachedClass;
String.getClass().getModule().isOpen(CachedClass.class.getPackage().getName(), CachedClass.class.getModule());

This returned false, so the java.base module is not open to the package and code hosting Groovy's CachedClass! But setAccessible still works with a warning.

If I do the same using another class from Groovy's own unnamed module, it returns true (as expected). If I call the same with a test of StringBuilder instead of CachedClass it returns true. If I try to access sun.misc.Unsafe that way, it works (as expected, because its declared as "open" in module descriptor - for good reasons, also if you don't permit illegal accesses).

So the module is definitely not "offically open" to the Groovy/unnamed module according to its metadata in java.lang.Module!

Because of this, many people were under the impression that the "open" hack only applied to the "old" setAccessible API, but new Java 9 APIs would behave in the new way. Because of this I understood Mark Reinhold's original proposal mail like this: old-style setAccessible still works with warning, all new APIs (trySetAccessible and Module metadata still say "the computer says no!"). Actually only the module metadata return the correct thing, trySetAccessible behaves like the old setAccessible.

So what we need to fix the issue: Give us an API that we can ask "is access possible" if I respect the module system and the module metadata?

I hacked this in a second attempt to solve Groovy's issue by using the above module metadata. Whenever it figures out that a class returns false for above's call, it does not even try to call setAccessible. See the code here:

https://goo.gl/JnrNyH

This works but the problem is that it is then hard to figure out which methods you can still call without setAccessible. With trySetAccessible or canAccess this would be fine. The problem for Groovy with canAccess() is that you need an instance, which is not available at the time of the check. Why is this? Why do I need an instance for canAccess() checks? I have the feeling because it could be a subclass of the reflected class you try the method call on, right?

Uwe

-----
Uwe Schindler
[hidden email]
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/

> -----Original Message-----
> From: jigsaw-dev [mailto:[hidden email]] On Behalf
> Of Alan Bateman
> Sent: Monday, July 10, 2017 11:56 AM
> To: Cédric Champeau <[hidden email]>
> Cc: jigsaw-dev <[hidden email]>
> Subject: Re: trySetAccessible​
>
> On 10/07/2017 09:49, Cédric Champeau wrote:
> > I second Uwe's comment here: I was surprised as well, I expected the
> > semantics of `trySetAccessible` to be: "let me know if I can do this,
> > respecting the semantics of modules, and if not, return false"
> For the example, trySetAccessible succeeds (returns `true`) because
> `java.lang` is open.  If you run with `--illegal-access=deny` then
> `java.lang` will not be opened and trySetAccessible should return `false`.
>
> -Alan

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: trySetAccessible​

Alan Bateman
On 10/07/2017 16:31, Uwe Schindler wrote:
> Hi Alan,
>
> we understand all this. But what you say is also not true. I started a second approach to fix the issue by using canAccess() and also checking the module stuff. For that I executed the following code on the Groovy unnamed module:
>
> import org.codehaus.groovy.reflection.CachedClass;
> String.getClass().getModule().isOpen(CachedClass.class.getPackage().getName(), CachedClass.class.getModule());
>
> This returned false, so the java.base module is not open to the package and code hosting Groovy's CachedClass! But setAccessible still works with a warning.
This code fragment tests if java.base opens a package to
CachedClass.class.getModule(). Can you say which package CachedClass is
in? I ask because I would have expected to see:

    String.class.getModule().isOpen("java.lang",
CachedClass.class.getModule());

to test if java.base opens java.lang to the Groovy module.

-Alan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: trySetAccessible​

Uwe Schindler
Moin,

> > we understand all this. But what you say is also not true. I started a second
> approach to fix the issue by using canAccess() and also checking the module
> stuff. For that I executed the following code on the Groovy unnamed
> module:
> >
> > import org.codehaus.groovy.reflection.CachedClass;
> >
> String.getClass().getModule().isOpen(CachedClass.class.getPackage().getNam
> e(), CachedClass.class.getModule());
> >
> > This returned false, so the java.base module is not open to the package and
> code hosting Groovy's CachedClass! But setAccessible still works with a
> warning.
> This code fragment tests if java.base opens a package to
> CachedClass.class.getModule(). Can you say which package CachedClass is
> in? I ask because I would have expected to see:
>
>     String.class.getModule().isOpen("java.lang",
> CachedClass.class.getModule());
>
> to test if java.base opens java.lang to the Groovy module.

Sorry, I mixed up the parameters. So basically the "correct" code to check if something like java.lang.String is open to Groovy would be:

Module groovyModule = CachedClass.class.getModule(); // org.codehaus.groovy.reflection.CachedClass;
Class clazz = String.class; // to test if open
return clazz.getModule().isOpen(String.class.getPackage().getName(), groovyModule);

If I do this, it returns "true" for String, Object or any other class. So the behaviour is consistent.

I implemented this check as a single MethodHandle to a precompiled method that takes a Class<?> and returns true/false if the Class is open to Groovy's module: https://goo.gl/XvdCQK
By this it's possible to execute this without a Java 9 at compile time. Unfortunately, it doesn't help, because java.base is open to unnamed module

But now it is impossible for us to check, if something is not open by default. So, to come back to the previous discussion, it is now impossible to make everything accessible (as if illegal-access=deny). This makes migration to Java 10 hard for some projects, because you have to live with warnings that are printed by default, but you can't check if something is allowed without printing a warning.

That's not good. IMHO, this should be improved by:
- adding an API to do the checks, ignoring illegal-access settings
- make the runtime not open by default and instead just allow setAccessible on the java.* modules with printing a warning.

Uwe

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: trySetAccessible​

Alan Bateman
On 11/07/2017 10:16, Uwe Schindler wrote:
> :
> Sorry, I mixed up the parameters. So basically the "correct" code to check if something like java.lang.String is open to Groovy would be:
>
> Module groovyModule = CachedClass.class.getModule(); // org.codehaus.groovy.reflection.CachedClass;
> Class clazz = String.class; // to test if open
> return clazz.getModule().isOpen(String.class.getPackage().getName(), groovyModule);
>
> If I do this, it returns "true" for String, Object or any other class. So the behaviour is consistent.
Yes, it has to be consistent.

As an aside, you can replace getPackage().getName() with
getPackageName() - it's more efficient and avoids the NPE when the class
is an array or primitive.


>
> I implemented this check as a single MethodHandle to a precompiled method that takes a Class<?> and returns true/false if the Class is open to Groovy's module: https://goo.gl/XvdCQK
> By this it's possible to execute this without a Java 9 at compile time. Unfortunately, it doesn't help, because java.base is open to unnamed module
Right, although isOpen("java.lang") will return false because the
package is not open to all modules.


>
> But now it is impossible for us to check, if something is not open by default.
Module::getDescriptor will return the module descriptor for named
modules. So in this case, Object.class.getModule().getDescriptor()
returns the ModuleDescriptor for java.base so you can inspect the
packages and which are exported and/or opened before being changed by
runtime. So there is enough in the API to determine which packages have
been opened at runtime (either via CLI options or APIs).

-Alan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: trySetAccessible​

Jochen Theodorou


On 11.07.2017 12:11, Alan Bateman wrote:
> On 11/07/2017 10:16, Uwe Schindler wrote:
[...]
>>
>> But now it is impossible for us to check, if something is not open by
>> default.
> Module::getDescriptor will return the module descriptor for named
> modules. So in this case, Object.class.getModule().getDescriptor()
> returns the ModuleDescriptor for java.base so you can inspect the
> packages and which are exported and/or opened before being changed by
> runtime. So there is enough in the API to determine which packages have
> been opened at runtime (either via CLI options or APIs).

we need that on the level of a class member. Not every method in a class
from an exported package is accessible or has been made accessible via
runtime mechanisms.

bye Jochen
12
Loading...