search

unitsofmeasurement / unit-api

Units of Measurement API
http://unitsofmeasurement.github.io/unit-api/
Other
182 stars 42 forks source link

enum missing in javax.measure.MetricPrefix #255

Closed sonideft closed 6 days ago

sonideft commented 12 months ago

In version of unit-api.jar 2.0, the sources have an enum for DEKA. In the latest source it was removed. I'm not sure why as the related static method is retained. I needed to add it back in order to get the latest version of GeoTools (Snapshot 31) to run (compiles fine). I'm not sure where the issue actually is, but I thought I would start here as DEKA appears half implemented.

keilw commented 12 months ago

This was discussed and deciced upon in #250, @desruisseaux also said in that ticket, it should not be a big issue. Having 25 Prefix implementations would just be plain wrong, but @dautelle or @desruisseaux what do you say? The method is a convenience method, not half-implemented. Removing the enum corrected an old issue of having the US spelling by mistake. As early as JScience, where the US spelling was also used for METRE, so it produced an inconsistency we fixed with 2.2.

Seshat does not yet implement it, but I trust @desruisseaux will find a way to work with the new API, please clearly say, if that would suddenly be a problem. After all, the US spelling is handled in resource bundles by Seshat with cm=centimeter for US and cm=centimetre for UK. There is currently no translation for things like dag=decagram (UK) vs. dag=dekagram (US), but there is a mechanism for that if needed. I know, it's a breaking change, but having to skip enums or break the API and TCK by being forced to change all JUnit tests plus the TCK (by changing NUM_OF_METRIC_PREFIXES = 24 to 25) seems just plain wrong.

I trust there can either be patches to Snapshot 31 or a Snapshot 32, changing the API dependency temporarily to 2.1.3 (as long as you don't already embrace the 4 new enums) or fixing whatever reference (I assume it's a resource bundle like Indriya's messages.properties you might have.

We don't forsee a 3.x API anytime soon (unless maybe the JDK some day offered a true value type or another breaking change in its type system) so 2.2 as opposed to 2.1.x seemed a viable step for that, after all there are also 4 new prefixes that did not exixt before. In theory a backport (2.1.4) of the API with the 4 new prefixes added, but the old DEKA simply deprecated and marked for removal could be doable, if that helps your implementation, but I would not pollute or mess up 2.2 or any other version by adding a 25th prefix.

GeoTools is also no stranger to its own breaking changes, see GeoTools 30.x in upgrade.

sonideft commented 12 months ago

Thanks everyone for commenting so fast. For my purposes, I am OK, since I copied the sources and just added an enum. It is puzzling how GeoTools (snapshot 31) was even able to compile. I'm not sure what the correct action should be, but I'm leaning towards GeoTools making an adjustment.