Open desruisseaux opened 7 years ago
Currently it is not possible to have more than one implementation in the same classpath. Something various JSRs are facing, e.g. mixing multiple JSF implementations causes all sorts of UI troubles or worse (e.g. artifacts that won't even deploy) which is why most JSF implementations bundle the API in a single JAR. We don't have to go that far, but having e.g. unit-ri and uom-se in the same classpath can lead to unpredictable results like ClassCastException
.
I do not know for RI implementation, but other implementations do not necessarily have issue with multiple implementations co-existing on the same classpath. I think it is actually likely to happen. However I'm fine about waiting that the situation happen in practice before revisiting this task.
I marked it as deferred. Before the CGPM 2018 (http://www.bipm.org/en/measurement-units/rev-si/) when the SI standard and definitions are supposed to get a major upgrade, I don't think significant API changes or a new JSR would be justified. After that let's see, either a MR or new JSR could then make sense, depending on where it impacts us.
@desruisseaux I think we could try to explore this if Indriya and Seshat implement 2.0 but I would probably descope it from the Final 2.0 release and leave it for e.g. a MR.
If we want cross-implementation interoperability, we may need to define the behavior of
Dimension.equals(Object)
. It would be needed because twoUnit
instances are considered convertible if all their dimensions are equal. One possible approach would be to normalize dimension symbols (L
for length,T
for time, etc.) and requireDimension.equals(Object)
to compare the symbols. But we could also choose that allowing mix of differentDimension
implementation is not a goal, which is all-right (I just don't know if it was a conscientious decision or an accident).