Update Spec Document for MR2 about unit-api HOT 5 CLOSED

No problem for RI, demo or documentation. For the API itself, even if on my side I'm on Java 11, there is a lot of software that are still on Java 8. So I guess that the API needs to still Java 8 compatible for a few more years. But only the API, the rest can move on.

from unit-api.

I created this ticket for a few minor spec improvements, primarily how to use the record from Java 16 onward. @desruisseaux, @dautelle, @otaviojava or others, would you be able to check it out briefly?

from unit-api.

What records would be used for? Would it be adding examples in the documentation about how JSR 385 could be implemented with records, or is this issue about changes in JSR 385 API?

from unit-api.

Yes, for now examples like uom-console-demos-java17 most of which the spec example code is based on demonstrate how to use records.
In addition, while that was always a PoC applying what I demonstrated in uom-demos to a new uom-impl-enum version also sounds feasible. While enums are a good match for limited scope units with a less complex hierarchy, quantities or measurements (where "measurement record" is a rather common term) work well with records under similar conditions.

I also consider to replace the default Measurement implementation and the QuantityRange in the RI with record-based versions after upgrading the Multi-Release-JAR of Indriya to a Java 17 or 16 version. Plus maybe one for Java 21 once that is Final next month. And squash the Java 12 and 14 ones into the 16 or 17 one. Until a possible MR3 I guess Java 8 is still supported, but the next Multi-Release probably will be 11 and 17 because those are the other LTS versions, as well as 21 (because the final Switch Pattern Matching offers nice redesign of some classes ;-)

from unit-api.

For MR2 the RI should also stick to Java 8. It may also start using Java 11 in a future version, but only a few minor 2.x digits down the road. As the RI should be closer to the API than other implementations, And Multi-Release-JARs work fine for Indriya.

So until maybe true value types or a final Vector API became relevant for the API (in which case, the API would have to move drastically to Java 23, 25 or similar) I see no need to support the latest Java types there yet.

from unit-api.