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

[Henry Jen]

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.
>> 
>> 
>