Thank you. Also, I noticed a bug in the current implementation of AbstractConverter, causing a stack overflow. It is easily reproducible;
Using the converter that uses promitives number works as expected. However, using any implementation of java.lang.Number as the parameter causes a StackOverflow. This is due to the implementation of convert(Number) in AbstractConverter.java.
@keilw thanks for your response. I will have a focus on uom-systems to see if it fits.
by "converting UOM symbols" I mean to convert to UOM symbols. that is having arbitrary uom strings (used by a domain which are not standard), parse it into a known unit (very likly via some mapping config) and then get out the actual UCUM symbol from it.
Currently I do have
org.geotools:gt-opengis:14 on my classpath which ships with jsr-275 beta jar which provides a UnitFormatter via `UnitFormat.getUCUMInstance(). However, JSR-275 was rejected by the EC.
BaseUnithas an additional argument
Q, but I see no realistic way to pass that when constructing the class, nor to retrieve it later. Using the
Classmaybe, that's already done in other places like unit systems.