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

[Jorn Vernee]

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')?

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?)

Also, it seems that TestMemoryAccess could use the Java constants 
instead of calling the factories, what gives?

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