[foreign-memaccess/abi] where do unsafe operations live

[Maurizio Cimadamore]

Hi,
As I was using foreign-memaccess and foreign-abi in anger, it occurred 
to me that the current layout of the incubating module is a bit limiting 
in case the user wants to perform some unsafe operations.

Right now, unsafe operations are defined in the class 'ForeignUnsafe' 
which lives in the (non-exported) jdk.incubating.foreign.unsafe package.

Since the package is not exported, users that want to access unsafe 
stuff need to add a manual --add-exports option.

This is fine, and, in fact, it was intended to have something that 
required an explicit opt-in, given that these are unsafe operations.

That said, let's look at the situation from the perspective of a library 
writer: if I write a Java bindings, it is very likely that I might want 
to create MemoryAddress from longs, and the likes. But if I do that, I 
need to break into the jdk.incubating.foreign module, and _require that 
all my clients do the same_!

I think this is excessively punitive. It's a good idea to have a sharp 
separation between "safe" and "unsafe" parts of the API - and it is also 
good if the "unsafe" parts of the API live in modules that are 
non-resolvable by default (e.g. you need to "require" them explicitly, 
or they won't be available).

But if somebody is packaging a library in a module, it is kind of sad 
that there's no way for the library writer to depend on the 'unsafe' 
module, if he so wishes (and free the library clients from having to 
make this explicitly).

All things considered, I think that a better structure would be to have 
_two_ modules:

* jdk.incubating.foreign - usual, safe portion of the API
* jdk.incubating.foreign.unsafe - unsafe portion of the foreign API 
(requires jdk.incubating.foreign)

This way, a library developer can just say "requires 
jdk.incubating.foreign.unsafe" and be done. The library clients will 
have to do nothing, assuming their module path is set up correctly.

Thoughts?

Maurizio