Proposal: Allow illegal reflective access by default in JDK 9

[Peter Levart]

Hi,

Just a thought...

What about keeping the "opens pkg" and "open module m" as is - there is 
a legitimate argument in keeping all accesses (static and reflective) in 
sync.

But it does not mean that "--illegal-access=permit" must be equivalent 
to --add-opens all-modules/all-packages=ALL-UNNAMED. It could mean a 
slightly different thing - just enough to keep the compatibility with 
JDK 8. There's no point in making jdk.internal.* packages open for 
example - they are mostly new APIs and not relevant to backwards 
compatibility.

More precisely,  let "--illegal-access=permit" allow 
.setAccessible(true) be called by unnamed module(s) on otherwise 
inaccessible (private, package-private, protected) members/classes of 
exported packages only.

The reasoning is as follows:

- selected JDK modules can explicitly open selected packages if they 
feel they should keep runtime compatibility with applications but 
prevent compilation with such APIs (like jdk.unsupported module does for 
example). In JDK 10 they can close those packages again.
- I don't know what percentage of JDK-internal APIs used by applications 
through reflection is in exported packages and what percent in 
concealed. It would be interesting to know such statistics first.
- User modules can explicitly open selected packages or entire modules 
if they feel so
- User automatic modules already export all packages, but to allow 
access to their private members via reflection, they should perhaps be 
equivalent to open modules with all packages exported in addition.

What do you think?

Regards, Peter



On 05/19/2017 04:27 PM, Peter Levart wrote:
>
>
> On 05/19/2017 04:05 PM, Alan Bateman wrote:
>> On 19/05/2017 14:54, Peter Levart wrote:
>>
>>> :
>>>
>>> Opening the whole JDK (--illegal-access=permit by default) means 
>>> that all internal "public" APIs are made accessible if by chance 
>>> someone can grab an instance of target object and/or an instance of 
>>> Method/Field object. Imagine a JDK developer that thought that by 
>>> putting a public type into a concealed package was equivalent to 
>>> making the type module-private. This is a big surprise from the 
>>> security perspective and jdk.internal.misc.Unsafe.getUnsafe() might 
>>> not be a lone example.
>> True although it's no different to JDK 8 and older behavior where all 
>> public members of all public types in all packages were accessible to 
>> code on the class path. 
>
> Except that in the meanwhile a lot of internal code was written for 
> JDK 9 that assumed the level of privacy provided by concealed 
> packages. This level is about to be changed by the proposal in the 
> last minute...
>
>> Furthermore, setAccessible could be use to hack everywhere. The 
>> proposal is really just giving libraries and tools more time to sort 
>> out their issues.
>>
>> -Alan
>
> Regards, Peter