[foreign-abi] RFR: Rename SystemABI to ForeignLinker, and move C support to a separate class.
jorn.vernee at oracle.com
Mon May 18 11:28:12 UTC 2020
> Looks good - there are few things that need more thinking:
> * the name `C` seems thin. It doesn't describe very well what the class is for. Maybe `CSupport` or something like that
> might be more expressive
Yeah, that's a good suggestion. Will apply.
> * if we have already C somewhere in the class name, there's a question as to whether constants should drop their C-ness
> (e.g. `C.C_BOOL` looks odd).
Thought about this; C.C_BOOL and C.Win64.C_BOOL become C.BOOL,
C.Win64.BOOL. That seems fine. Then there's also static import variants;
C_BOOL, Win64.C_BOOL that go to BOOL and Win64.BOOL. I feel like for the
C_BOOL -> BOOL case some information is lost, and that's the most common
case we have it seems. But, maybe it's clear enough from the context
that a C layout is being used? I think the main risk is confusing with
Java carrier types or layouts (since the names are similar. Feeling a
little on the fence about it, so I held off on the first revision.
> * I wonder if, now that we have a dedicated C class, helpers functions to read/write strings shouldn't just go in there
> (e.g. take Cstring and expand its static helpers onto the new class).
Why not :) having more freedom to add small C utilities is also a good
reason to have a C/CSupport class. (I was using this class to put
VaList/VarArg support in in my experiments as well). Also, looking at
the space occupied by the JNI API, I think that we can afford some API
surface to add some convenience utilities for C in Panama.
> PR: https://git.openjdk.java.net/panama-foreign/pull/174
More information about the panama-dev