Groovy with Jigsaw

[Uwe Schindler]

Hi,
 
> On 10/09/2015 23:57, Uwe Schindler wrote:
> > :
> >
> > 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?
> >
> >
> Right, there is compatibility issue here (third item in the "Risks and 
> Assumptions" section of JEP 261 [1]).
> 
> The setAccessible methods don't declare any checked exceptions. The 
> only exception they declare is SecurityException. This exception make 
> sense when running with a security manager and the specified 
> permission check fails. This exception is the wrong exception to fail 
> with when the member is not an an exported package as this is nothing 
> to do with the security manager. Sadly, these methods do throw 
> SecurityException when attempted on a constructor of java.lang.Class, 
> I've been trying to dig into the history on this oddity.

Sorry I missed that. You are right, setAccessible does not throw any checked reflective Exception. I was under the impression it might throw IllegalAccessException or the like, sorry for that. But the issue still persists!

One solution to solve the problem would be to make the java.lang.reflect.InaccessibleObjectException a subclass of SecurityException? This also looks not ideal, but this would fix all code which is well behaved and catches SecurityException on setAccessible. And simple googling shows tons of this.

You may add this to the Javadocs of this method and to the documentation of the Exception, explaining that it is a subclass of SecurityException for backwards compatibility. Are there any other places where java.lang.reflect.InaccessibleObjectException is used?

> Anyway, retrofitting these methods to throw 
> ReflectiveOperationException (or sub-type) isn't really an option 
> because this is a checked exception so it would add a source 
> compatibility issue to the list. For now, the prototype API changes 
> these methods to throw InaccessibleObjectException and we'll have to 
> see the impact of this. I hope we aren't force to change this to throw 
> SecurityException as it's the wrong exception, but less impact 
> compatibility- wise because there is some chance that existing code might handle that already.

I agree, maybe add new exception as described above.

> -Alan.
> 
> [1] http://openjdk.java.net/jeps/261

Thanks, very helpful. So looks like setAccessible is the only affected method.