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