[foreign-memaccess] RFR 8228444: Add common value layout constants

[Maurizio Cimadamore]

On 19/07/2019 18:22, Jorn Vernee wrote:
> I'm not sure I love the names either... 'BYTE_X_BE' seems to 
> reminiscent of a Java (or C) byte. How about `V8_BE`, `V16_LE`, etc... 
> ('V' standing for 'Value')?

I agree that BYTE is problematic here - I originally came up with

OCTET
HWORD
WORD
DWORD

but wasn't sure of that either.

Another option is to go "bitty":

BITS_8
BITS_16
BITS_32
BITS_64

Which looks more agnostic.


>
> About the JAVA_XXX constant; maybe it's good to put these in a nested 
> class as well, that way users can use a static import to import just 
> the Java constants, they will be grouped together, and after all 
> `JAVA_BYTE` is almost the same as `Java.BYTE`. (what do you think?)
We could go there - don't feel too strongly either way - but I don't 
like too much nesting.
>
> Also, it seems that TestMemoryAccess could use the Java constants 
> instead of calling the factories, what gives?

Yeah - I will/can consolidate after I remove also the factories (see 
other patch)

Maurizio

>
> Jorn
>
> On 2019-07-19 18:49, Maurizio Cimadamore wrote:
>> Hi,
>> this is a first stab at implementing a set of layout constants along
>> the guidelines described in [1].
>>
>> http://cr.openjdk.java.net/~mcimadamore/panama/8228444/
>>
>> More specifically, the Layouts class introduces layouts constants to
>> be used for language agnostic serialization, with explicit endianness:
>>
>> BYTE_LE, BYTE_BE, BYTE_2_LE, BYTE_2_BE, ...
>>
>> And some Java-friendly constants whose endianness defaults to BE (same
>> as ByteBuffer):
>>
>> JAVA_BYTE, JAVA_SHORT, ...
>>
>> In the future, we will create nested interfaces here, one per
>> supported ABI, with ABI-specific layout constants - e.g.
>>
>> SysVABI.C_INT, SysVABI.C_LONG_DOUBLE, ...
>>
>> This patch also removes endianness implicit constructors from
>> ValueLayout - now endianness is always explicit (but if you use
>> constants, you can ignore it, up to a point).
>>
>> Overall this seems like the right mix of decisions - different
>> constants, different users, different requirements. Not sure I totally
>> love the names, the challenge here is to find something that is
>> relative semantics-neutral (since we plan to 'free' layouts from
>> semantics considerations such as signed/unsigned int/float).
>>
>>
>> [1] - 
>> https://mail.openjdk.java.net/pipermail/panama-dev/2019-July/006001.html