Groovy with Jigsaw

[Alan Bateman]

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.

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.

-Alan.

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