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
