[foreign-preview] RFR: 8282476: Drop NativeSymbol [v2]

[Paul Sandoz]

On Wed, 2 Mar 2022 14:22:06 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.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments
>   * remove remaining references to native symbol in CLinker javadoc
>   * improve javadoc of ClassLoader::findNative

Marked as reviewed by psandoz (Committer).

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

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