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

[John Rose]

On Jan 31, 2019, at 1:56 PM, Henry Jen <henry.jen at oracle.com> 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)

I'd rather have a prefix on those too, so I prefer your suggestion further down.

> 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

Yes.  Or possibly ABITypes, with the understanding that C and
the ABI are interdependent.

> 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

There are only a few of these; they can be duplicated on both sides.

> java.foreign.Platform.*; // Those are for portable types safe on same VM architecture, explicit length and same endianness as JVM, INT16, INT32, INT64

Yes, platform is OK.  I expect many users will want to
say import static java.foreign.Platform.* and be done.

There might be a place to use static inheritance to organize
subsets and supersets of these names.  I'm thinking maybe
CTypes <: Platform for example, since the ABI types are
a superset of the platform types.  But maybe the names
are all disjoint, in which case it's moot.

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

Yes, I suppose we don't need both kinds of names, and
given a choice we should have more name spaces rather
than fewer, to allow selective imports that distinguish
between Platform (which is pure Java) and ABI (which
brings in dependencies on C definitions).  Also BE and
LE for people working with protocols and other rigidly
defined formats.

For the record, I don't mind the fact that BE.INT32 and
LE.INT32 have the same name, even though it could
potentially be confusing to the reader of code far
from the import statement.  It's a stylistic choice
for the writer of the code:  Either declare "house
rules" for endian polarity and use the ambiguous
names, or else require a BE or LE prefix everywhere.
(Or a mix; that's possible also.)  For this particular
application, having two meanings for one importable
name is OK, since the point of ambiguity is well
known and there are several conventions for dealing
with it.  We allow coders to pick their convention.

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

Rather than adding even more names, I would prefer to have
an operator on the constants to switch polarity.  Something
like:

  assert  BE.INT32.endian(Endian.LE) == LE.INT32;

This is the sort of degree of freedom that the intrinsic API
is designed to support:  https://openjdk.java.net/jeps/348
The idea is that a call to an intrinsic method on a constant
will also be a constant.

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