[foreign-memaccess+abi] RFR: Make Addressable sealed again

[Maurizio Cimadamore]

On Tue, 28 Sep 2021 18:18:42 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Following the API refresh, I realized that making `Addressable` non-sealed was perhaps a step too far, at least for the time being. It forces a `scope()` accessor on the interface, which in turns pollutes the `MemoryAddress` interface (since a memory address has no scope).
>> While the API, as currently defined is sound, I'd prefer to make things tighter for now, as I realized that the need to define custom `Addressable` is perhaps limited. For instance, one place I thought they would have been useful was to model structs - but thinking more, a struct is probably backed by a segment anyway - and the segment is addressable. So, assuming the struct exposes a segment accessor, we still have ways to pass it around w/o necessarily having it implement the `Addressable` interface directly.
>> 
>> In the implementation we do have a new internal `Scoped` interface, which is used to keep all by-reference parameters alive by the linker. Basically, this interface re-adds the scope accessor which has been removed from the public API.
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/Addressable.java line 53:
> 
>> 51:      * @return The memory address associated with this addressable.
>> 52:      * @throws IllegalStateException if the scope associated with this addressable has been closed, or if access occurs from
>> 53:      * a thread other than the thread owning that scope.
> 
> Assuming that this method can still throw an exception for the reason described here, is it okay for API methods to throw unspecified exceptions?

for runtime exception, I think that's fine. That's kind of the case with `UnsupportedOperationException`. We might add some text to the documentation, but in general I think that's within bounds.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/586