Proposal: Allow illegal reflective access by default in JDK 9

[Alan Bateman]

On 19/05/2017 17:42, Peter Levart wrote:

> :
>
> 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.
This is a good point as it would of course be a big set back to open new 
packages (such as jdk.internal.misc as we have been discussing here). 
The JDK 9 build has the list of the JDK 8 internal packages (as it is 
needed for other tools) so it is feasible to not export the internal 
packages that are "new" in JDK 9. We need to give the proposal a few 
days to collect feedback before bringing up all the detailed issues 
around this.

> :
>
> - 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.
The JDK modules aren't going to export these packages so anyone 
compiling code with JDK 9 and static references to types in these 
packages will need to compile with `--add-exports`. You are right that a 
possible option is to open specific packages but that has lots of 
implications, particularly for the standard modules. It would also be 
problematic for `--illegal-access=deny`, something that is important to 
have in 9 to test how code will behave when the JDK internals are 
eventually encapsulated.


> - 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.
We've presented data on static references to sun.* APIs at conferences 
as it's not hard to do static analysis to get this data. It's much 
harder to get data on code using reflection to get at JDK internals. 
Early builds allowed deep reflection of all members of all types in 
exported packages - that was the initial proposal in 2015 to keep as 
much existing bad code working as possible. Fixing that issue 
(#AwkwardStrongEncapsulation) exposed a lot more hacks with code that is 
breaking into protected and private members of public types in exported 
packages. There was a notable increase in the hate mail with that 
change. There is also the anti-pattern that is 
obj.getClass().invoke(...). I've tried of dozens of libraries and 
frameworks to identify the hacks. In general they are all over the map 
but there is a concentration of hacks on protected and private members 
of java.base's exported packages.


> - User modules can explicitly open selected packages or entire modules 
> if they feel so
Yes.

> - 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.
Automatic modules have always opened all packages so I don't think there 
is an issue there.

-Alan