Small query on CLinker

[Maurizio Cimadamore]

Note that the API we have today is much simpler (I think you are looking 
at the Java 16 API):

https://download.java.net/java/early_access/jdk18/docs/api/jdk.incubator.foreign/jdk/incubator/foreign/CLinker.html

We no longer have C layouts (like C_POINTER) and TypeKind is also gone. 
So, one could argue that, _today_, CLinker looks a more general than it 
used to.

Maurizio

On 23/03/2022 13:04, Julian Waters wrote:
> Hi Maurizio, thanks for the reply,
>
> I was thinking about language specific quirks being confined to 
> specific implementations while having CLinker being the language 
> agnostic interface too, from what I can tell quite a lot would have to 
> be migrated from CLinker (Or renamed Linker if it does end up as truly 
> agnostic) to each language specific file though (C_POINTER and 
> TypeKind etc), I can't at the moment tell if that would be feasible
>
> best regards,
> Julian
>
> On Wed, Mar 23, 2022 at 8:18 PM Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com> wrote:
>
>     Hi Julian,
>     This question has come up, both internally and externally.
>
>     I agree that CLinker is a pretty general abstraction and there's
>     nothing
>     in it that is too C specific. The concepts of taking a function
>     descriptor and turning it into a method handle, or, conversely,
>     taking a
>     method handle and turning it into a function pointer are reusable
>     across
>     different languages.
>
>     That said, there are a couple of ways in which language details can
>     creep back in:
>
>     * not all linkers might support the same set of layouts in the
>     provided
>     function descriptor. For instance, a language might not have
>     support for
>     by-reference arguments (so that ValueLayout.ADDRESS is not an
>     option).
>     Or a language might not support composite types (so struct/union
>     layouts
>     are not possible)
>     * the support for variadic functions is pretty tied to how the ABI is
>     defined; in C we have to know which arguments layouts in the function
>     descriptor correspond to "variable arity" arguments, because the ABI
>     needs to treat them differently.
>
>     Of course, one option would be to make the javadoc of CLinker
>     language
>     agnostic (this is easy - 90% of the javadoc already is) - and move
>     the
>     language-dependent details in the linker factory (e.g. set of
>     supported
>     layouts/parameters, handling of variable arity, etc.)
>
>     Thanks
>     Maurizio
>
>     On 23/03/2022 12:03, Julian Waters wrote:
>     > Hi all,
>     >
>     > Small query about CLinker, would it be more appropriate to
>     rename it (And
>     > the systemCLinker method) to just "Linker" to better fit its
>     role? It is
>     > after all supposed to be an abstraction for any sort of foreign
>     interface,
>     > and I feel like the name CLinker would intuitively signify that
>     it can
>     > *only* work with C and nothing else. Or would this undermine the
>     fact that
>     > native calls have to follow the C ABI?
>     >
>     > best regards and have a great day,
>     > Julian
>