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 <uschindler at apache.org>:

> 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
> uschindler at apache.org
> ASF Member, Apache Lucene PMC / Committer
> Bremen, Germany
> http://lucene.apache.org/
>
> > -----Original Message-----
> > From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf
> > Of Alan Bateman
> > Sent: Monday, July 10, 2017 10:07 AM
> > To: Jochen Theodorou <blackdrag at gmx.org>; jigsaw-dev at openjdk.java.net
> > 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
>
>