[foreign] RFR 8218153: Read/Write of Value layout should honor declared endianness

[Maurizio Cimadamore]

Can I suggest that, from a logistical point of view, we split the 
original changeset from the static import discussion?

Which kind of imports we need in practice is a question that will be 
much better answered by looking at concrete use cases, and using the API 
in anger, rather than trying to abstractly find the best possible split.

Also, where to put these extra constants depend, in my view, on what we 
do with SystemABI - if that would to become a public type, I think that 
would be a natural place where to put some of these.

Maurizio

On 31/01/2019 21:56, Henry Jen wrote:
> Great, I’ll get rid of default endianness construction in Value.java. What’s left is how we divide those LayoutType constants for import(a bike shed),
>
> So here is what I think,
>
> java.foreign.NativeTypes.*; // Those are for portable types, explicit length, endianness same as JVM(platform)
> java.foreign.NativeTypes.LE.*; // Portable Little Endian types
> java.foreign.NativeTypes.BE.*; // Portable Big Endian types
> java.foreign.CTypes..*; // Types that are matching C types and ABI dependent
>
> If we want to be even more strict, further split NativeTypes.* into
>
> java.foreign.NativeTypes.*; // // Those are for completely portable types, explicit length, endianness is not relevant, like VOID, INT8
> java.foreign.Platform.*; // Those are for portable types safe on same VM architecture, explicit length and same endianness as JVM, INT16, INT32, INT64
>
> I think we need separate class to make the import required for platform specific types, so that as John suggested, we will have clear evidence on top knowing the class maybe platform specific. Same reason we probably should use nested class for BE/LE instead of prefixed type names, as we don’t need both.
>
> Note that we might want to have LE/BE variants for CTypes as well since endianness and size are orthogonal. As what we have in
> https://hg.openjdk.java.net/panama/dev/file/5216c920ce97/src/java.base/share/classes/jdk/internal/foreign/memory/Types.java
> btw, which is only valid for x86 at the moment.
>
> Suggestions?
>
> Cheers,
> Henry
>
>
>> On Jan 31, 2019, at 11:51 AM, John Rose <john.r.rose at oracle.com> wrote:
>>
>> I would be very happy with this outcome, and I think we can also
>> make the users happy (in their various kinds and factions),
>> by providing a tidy menu of import options.
>>
>> On Jan 31, 2019, at 10:59 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>> I think all this goes for the nuclear option (c), with some static import reliefs.
>>>
>>> I also think that inferring LE or BE always (as per my option b) is as wrong as inferring platform endianness - in terms of place where bugs can hide, and difficulty in terms of finding where such bugs are coming from (because it's implicit).
>>>
>>> So, I think the Value layout API should NOT have a default constructor w/o endianness.
>>>
>>>