Groovy with Jigsaw

[Uwe Schindler]

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
uschindler at apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/