How could we support new features like JDK's Vector API?

[keilw]

We consider supporting the Java Vector API (#215) either now or whenever it leaves the incubator, so that features like Vector support offered earlier in JScience could be possible in a future version of the API.

However, based on discussions in the RI (around indriya#364) OpenJDK contributors including @AlanBateman reassured, that you must not declare any new class or Interface in a Multi-Release JAR that uses let's say elements in jdk.incubator.vector if those elements are not declared in the root (minimal JDK) element of the same MR JAR, as well.

Of course that is impossible declaring say:

QuantityVector<Q extends Quantity<Q>> extends jdk.incubator.vector.Vector<Q>

(just a guess, but any class or method that uses Vector types in the signature would be affected)
because how would that work in the root source folder where Vector is completely unknown?

What is the recommendation by the OpenJDK team especially for a possible new version of the JSR in the future?
Should a (presumable) Units of Measurement 3.0 then require a minimum version of Java like 16 or 17 (which is also an LTS) because the Vector API was not available before that?

Thanks and Regards,
Werner

[desruisseaux]

I agree that putting vector in public API may force the minimum Java version to something like Java 20 (we do not know yet when the vector API will be released). But it may be a question for the future. For now, the vector API is still in incubator and get incompatible changes from version to version. Some incompatible changes are already announced for next version (some methods to be removed in favour of Panama objects).

I think that we should not put dependency to incubator API in the unit API, unless the unit API are made available only as a "preview" and not a formal release. For a formal release, I think that we need to wait for a formal release of vector API as well. Then the next question will be: do we need to put that in public API, or should it be considered as an implementation details?

[keilw]

@desruisseaux Thanks for your thoughts on that topic. That's the problem of the JDK that "API" and implementation details are often tightly coupled and unlike most proper JSRs hard to separate, see java.time (which even comes wiht a circular dependency between the "API" and "impl" part ;-/) and many others, Also same for Collections or Vector API wherever the future package may be factored to (I would assume java.vector but no idea what the plans are for it) which might make independent implementations a bit easier, see Javolution by @dautelle or Eclipse Collections, but both come with most default implementations in the same package/module.

So yes one possibility could be implementation specific like the MixedQuantity which remains in the RI for now, but even there it would not be allowed to declare such new element in a Java 16+ or 20+ Multi-Release JAR folder, otherwise it'll cause the same conflict we discussed in indriya#346.
A separate "incubator" module could help on top of Indriya to explore those kinds of things, but as soon as we consider something like a VectorMeasure earlier JSRs proposed (and JScience still contains) even implementation-specific (remember JScience was also briefrly the RI for JSR-275 ;-) we would have to include it at least into implementations the same way e.g. MixedQuantity is now in the RI.