[foreign-preview] RFR: 8282476: Drop NativeSymbol

[Jorn Vernee]

On Tue, 1 Mar 2022 11:03:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This change drops the `NativeSymbol` interface from the API, for the following reasons:
> 
> * A `NativeSymbol` is essentially a `MemorySegment` w/o a length - following JDK-8280460, zero-length memory segment are better supported and can be used instead.
> 
> * Whenever the API takes a `NativeSymbol` (e.g. in linker downcall handles) we can take `Addressable` and have a more flexible API
> 
> * The extra level of safety added by `NativeSymbol` was questionable for such a low level API. The only difference between a `NativeSymbol` and a `MemorySegment` is the fact that the former does not support slicing and dereference. But the same is true for a zero-length segment. Also, while `NativeSymbol` made it harder for developers to pass wrong types to linker method handles (e.g. a `VaList`), it is still possible to unsafely wrap bad data into a `NativeSymbol` (e.g. the API implementation won't really check that the address used to construct a new `NativeSymbol` is really that of a "symbol"). And, `NativeSymbol` also made it harder for developers to pass raw native addresses to the linker (such addresses needed to be wrapped into a symbol instead).
> 
> Ultimately, the concept of "symbol" was a bit too fuzzy: we came to it mostly because it made sense as a return type for lookups - but it doesn't ultimately add anything to the API, other than providing two different ways to do the same thing.

Marked as reviewed by jvernee (Committer).

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

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