Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dimension interoperability #38

Open
desruisseaux opened this issue Apr 10, 2017 · 4 comments
Open

Dimension interoperability #38

desruisseaux opened this issue Apr 10, 2017 · 4 comments

Comments

@desruisseaux
Copy link
Contributor

If we want cross-implementation interoperability, we may need to define the behavior of Dimension.equals(Object). It would be needed because two Unit 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 require Dimension.equals(Object) to compare the symbols. But we could also choose that allowing mix of different Dimension implementation is not a goal, which is all-right (I just don't know if it was a conscientious decision or an accident).

@keilw
Copy link
Member

keilw commented Apr 10, 2017

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.

@keilw keilw added the invalid label Apr 10, 2017
@desruisseaux
Copy link
Contributor Author

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.

@keilw keilw added deferred and removed invalid labels Apr 11, 2017
@keilw
Copy link
Member

keilw commented Apr 11, 2017

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.

@keilw
Copy link
Member

keilw commented Mar 5, 2019

@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.

@keilw keilw removed this from the 2.0 milestone Mar 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants