[foreign-preview] RFR: 8282873: Bring back SymbolLookup

[Maurizio Cimadamore]

On Thu, 10 Mar 2022 20:51:23 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> This patch brings back the `SymbolLookup` abstraction, which was initially left behind during the move to java.base.
>> 
>> In hindsight, moving lookup capabilities to `CLinker` and `ClassLoader`, while economical in terms of API surface, is problematic, as it is much harder to users of the API to understand how to look up for library symbols (since lookup capabilities are scattered across different classes).
>> 
>> Moreover, recent JDK changes, such as JDK-8281335 and JDK-8282608, make library loading more flexible, and much closer to a raw dlopen/dlsym/dlclose. Which means we can now provide, in addition to loader and system lookup, a *third* kind of lookup, which features deterministic library loading/unloading (see `SymbolLoojup::libraryLookup`).
>> 
>> Overall, I think that having a dedicated abstraction for looking up symbols in libraries is a good thing; not only it makes the API more discoverable, but it also allows clients to define custom lookup (as `SymbolLookup` is a simple functional interface).
>
> src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 126:
> 
>> 124:      */
>> 125:     @CallerSensitive
>> 126:     static SymbolLookup libraryLookup(String name, MemorySession session) {
> 
> This could just call the Path version, creating a path from the name (or vice versa), rather than duplicating the code.

This cannot call the path version. Note that `dlopen` has its own "known" library names. On linux I can open `libc.so.6` by name, and the correct file fill be found, using the linker cache. MacOS also has some notion of libraries that are not really files: https://developer.apple.com/forums/thread/655588

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

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