Hi,
> Now a more practical one... In Groovy we have code like this:
>
> try {
> AccessController.doPrivileged(new PrivilegedAction() {
> public Object run() {
> c.setAccessible(true);
> return null;
> }
> });
> }
> catch (SecurityException e) {
> // IGNORE
> }
>
> which is code supposed to "check" if we can access the class member or if
> any security manager will disallow this. In this case the method becomes
> unavailable for invocation... Now jigsaw changes do make the setAccessible
> method also throws java.lang.reflect.InaccessibleObjectException. What is
> the suggested way to handle this for code that has to be also compatible to
> pre JDK9 code?
> catch RuntimeException, check the class name and rethrow if the name does
> not fit?
I already opened an issue about this:
https://issues.apache.org/jira/browse/GROOVY-7587
This makes Groovy unuseable at the moment with JIGSAW. Elasticsearch is
affected by this, but also the Ant-based build scripts used to build Lucene and
Forbiddenapis (both use Groovy from Ant). I think the only "quick" fix would be
to check RuntimeException, check class type, otherwise rethrow.
I also wanted to ask the question: setAccessible() already throws some checked
exceptions, why invent a new one that’s no longer checked? Could it not simply
be one already there - one of the checked ones - or a new one just subclassing
ReflectiveOperationException? This is completely inconsistent to other core
reflection APIs. Why have a totally unexpected new one?
Uwe
-----
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
