Java value layout constants

[Uwe Schindler]

Hi Maurizio,

> For this reason, I'd like to propose a small tweak, which would
> essentially revert alignment constraints for Java layout constants to
> what they were in 17. In other words, let's keep the "good" JAVA_XYZ
> names for the _true_ Java layouts (including alignment as seen by VM).
> If clients want to create unaligned constants they can do so, as they
> can also create big-endian constants where needed. In the majority of
> cases, since access will be aligned (for performance reasons), this will
> not really change much for clients. But some of those clients that need
> to pack data structures more (Lucene?) will need to define their own
> packed/unaligned layout constants.

That's all fine. In my first JDK 18 branch of Lucene's new MMapDirectory, I did it like that:
https://github.com/uschindler/lucene/blob/ad3a81e3d348d6aa417aa785bdfe9e7a39c1ee53/lucene/core/src/java/org/apache/lucene/store/MemorySegmentIndexInput.java#L36-L40

Basically we have layout constants anyways (as the file format has a defined byte order). At the time when I wrote this (in September) I was already thinking: "maybe add withBitAlignment(8) everywhere?"

In general, when you define your own constant for on-disk layouts it is always adviseable to be specifc with byte order and alignment.

Anyway, we are working on Lucene to have alignment in our files at least for those non-packed formats. E.g. we now align file slices (we call them CFS files) always with 8 bytes to not add additional misalignment there. At some point in future we may to enable the alignment checks, but this will be after several years (file format compatibility).

Uwe