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

[Jorn Vernee]

On Tue, 28 Sep 2021 18:11:56 GMT, Maurizio Cimadamore <mcimadamore 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.

Marked as reviewed by jvernee (Committer).

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?

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

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