Extending tec.uom.se.unit.Units to add custom derivative units?

[Robert Bates]

Hi there!  First off, let me say I very much appreciate all the hard work that has gone into the JSR as well as the wonderful RI and SE codebases. 

TL;DR is there a good guide on how to extend existing or define a new SOU via the SPI?  I haven't had a lot of luck finding one and was hoping maybe it's just tucked back somewhere I haven't managed to uncover yet.

I am trying to leverage the SE codebase in a modeling+simulation application where I am standardizing a simulation on SI base units, yet want to allow users to enter simulation parameters in dimension-compatible units (e.g. filling in the blanks for Time, Mass, Length, Energy based on concepts from http://www.ontobee.org/ontology/UO).

My first attempt was to extend the Units class, but that didn't appear to work as an empty Set<> came back from getUnits() and any calls to ServiceProvider.current().getSystemOfUnitsService().getAvailableSystemsOfUnits() doesn't show my new SOU as being available.

I've read the RI user guide, but it skims over the SPI layer and really doesn't have a lot of detail re how to define/extend a custom SOU beyond digging through the RI of UCUM codebase, which I can't make heads or tails out of how the custom SOU is getting registered (and looking at SE it also looks like several quantity factory and format classes are also defined and somehow hooked in).

Any help/links/guidance would be greatly appreciated!

-R

[Werner Keil]

Hi Robert,

Thanks a lot for your interest and question.

I agree, the RI guide does not cover every single aspect in such great detail. The SOU and SPI are also described in the Spec, if you haven't done so, please check it out: https://docs.google.com/document/d/12KhosAFriGCczBs6gwtJJDfg_QlANT92_lhxUWO2gCY

https://github.com/unitsofmeasurement/uom-guide is an attempt to create a wider guide book for Units of Measurement, but it is still a work in progress. Help is certainly appreciated if someone has something to share.

tec.uom.se.unit.Units or its RI equivalent are meant to be extended. 

Because UCUM or CLDR and others are based on several different other systems or e.g. USCustomary is non-metric, these won't do so, but please look at the SI system:

https://github.com/unitsofmeasurement/si-units/blob/master/units-java8/src/main/java/si/uom/SI.java

Units is a representative but smaller sub-set of the SI to keep it at a modest size. It will not require additional quantities not defined by the API, while either SI Units or other extension libraries come with additional quantities. 

SI is the first layer on top of an implementation, so it should give you a good idea what's needed to properly register your own SOU with the API/SPI.

The two JUnit tests in https://github.com/unitsofmeasurement/si-units/tree/master/units-java8/src/test/java/si/uom/impl should give a bit more insight into how ServiceProvider behaves once a new system like SI has been registered. Depending on the custom ServiceProvider you write it'll override the default or may come after the implementation one, but you should have more than one. And ServiceProvider.current().getSystemOfUnitsService().getAvailableSystemsOfUnits() would either show only your new SOU or multiple, if you decided to also the buillt-in systems.

Hope that helps, let us know, if there are other questions.

Regards,

Werner