[foreign-abi] minimizing the surface of restricted native access

[Ty Young]

On 11/29/19 6:27 AM, Jorn Vernee wrote:
> Hi Ty,
>
> None of the packages with 'internal' in the name will be exported, 
> since they are not part of the public API, but an implementation 
> detail. This naming pattern is followed in many places in the JDK 
> (e.g. java.base has a bunch of these packages [1], which are not 
> exported by default [2]).


Well, not all JDK developers got or read the memo then. Doing 
"jdk.internal." for me brings up:


clang

ed

jvmstat

le

opt

vm.ci

vm.compiler

vm.compiler.management


So whoever sent the memo the first time might want to resend it.


>
> Just like reflectively changing 'private' fields of a class is 
> ill-advised, because you can end up going around invariant 
> checks/assumptions and break the functioning of the class, you can 
> break invariants by directly accessing an implementation detail in an 
> internal package. So, no, this package will not be exported by default 
> (just like we don't make all our fields 'public'). This is also 
> important for keeping the option open of changing the implementation, 
> which is much harder if users outside of the JDK depend on that 
> implementation.
>
> Would you wish to access an internal package any ways, you would need 
> to provide an additional command line flag (--add-exports ...) to 
> break the encapsulation (similar to setAccessible(true) for hacking 
> into a private field). By providing the command line flag you 
> explicitly except the risk of breaking the VM, and the risk that the 
> code you depend on can change it's behavior or shape at any time, or 
> becomes inaccessible altogether. i.e. it's similar to removing a 
> "warranty void if removed" sticker found on some consumer electronics.


I'm aware of the --add-exports however IMO it's easier to just export it 
in the module-info and compile from source.


>
> Of course, if you're making a library that depends on internal APIs, 
> the users of your library must also explicitly opt into using these 
> implementation details (through your library), and thus also 
> explicitly accept the risks tied to the use of internal code. While 
> you may be comfortable with removing the 'sticker', your clients might 
> not be, so they again have to opt in.
>
> Jorn
>
> [1] : 
> https://github.com/openjdk/jdk/tree/master/src/java.base/share/classes/jdk/internal
> [2] : 
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/module-info.java