I'm not sure if this is the right place to ask, but using the latest revision of units-api and unit-ri for JSR-363, what would be the best way to obtain a unit instance from a String representation? I believe SimpleFormat.getInstance().parse("STRING REPRESENTATION") would be the best way?
Thank you. Also, I noticed a bug in the current implementation of AbstractConverter, causing a stack overflow. It is easily reproducible;
'
SI.METRE.getConverterTo(US.FOOT).convert(1.0);
SI.METRE.getConverterTo(US.FOOT).convert(new Double(1.0));
'
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.
This is probably caused by a loss of precision in the double representation of 1.0/100000.0. I don't see why these extra parenthesis are necessary. I would simply remove them in your API if I were you.
Showing 0.005005000000000001 as either 0.005, 0.005005 or even just 0 is subject to the format part of the API and implementations. Especially for the RI there are some changes to get rid of java.text and other elements that are incompatible with Java ME Embedded. In UOM-SE those are possible as is using "plain old" ResourceBundle or BigDecimal. Which is why there could be different precision in SE or ME due to that.
Btw, almost every issue you mentioned here is RI-specific, did you know there's another room https://gitter.im/unitsofmeasurement/unit-ri here, too? ;-)
hey there .. just found jsr363 and your contributions on github ... nice work so far. I do have external data source(s) which describe UOM in a non-standard way. I'd like to have UCUM symbols instead which are required to be set by OGC standards. I could not find similar use cases/tests in the uom-api code. Is the librabry/implementation capable in converting UOM symbols?
Hi, Thanks for your interest and suggestions. About OGC standards, probably best talk to @desruisseaux since he also leads the GeoAPI standard. UCUM and other systems would mostly be under https://github.com/unitsofmeasurement/uom-systems.
HTH? I am not sure, what you mean by "converting UOM symbols"? The API and JSR provides means of converting quantities from one unit into other compatible units, but not "convert" the symbols as such. Maybe you can explain further what you would like to archive, unless you find it in above system libraries anyway.
@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.
@ridoo Thanks for the clarification. As this is usually domain- and sometimes also locale-specific, it's not something we expect to be integral part of UoM libraries or systems. These offer say different systems like UCUM, SI or ISO80000, but trying to convert a string like "kilom" into "km" just as an example before parsing "km" via UnitFormat instances should be done by an application or framework first. While JSR 275 was rejected at PR stage, OCG did not bother and made it part of their GeoAPI 3 standard. Hence, it is "embedded" in another standard and used widely. Until now, usage stats of common repositories like Sonatype/MavenCentral or Bintray/JCenter show higher demand for JSR 275, mostly due to GeoAPI and projects using or implementing it. JSR 363 is in Public Review as we speak. And with IoT, BigData and other areas showing a big need for this kind of standard (both inside the JVM and via neutral formats like JSON, XML and UCUM also outside) plus corporate partners and interest, we are rather optimistic it should pass this time. However, you won't see it in GeoAPI or LocationTech, etc. until OGC releases a new version of GeoAPI using JSR 363 instead ;-)
@keilw okay, thanks for your comments. I agree with you, that converting arbitrary units is certainly a domain related task. I wanted to be sure that there is no integration point for custom user configuration in your API before creating my own one. However, I think that it should not be that big deal though :)
hello, I'm having a hard time finding the EA (each) unit. If you google it you will see such a unit of measure is quite common: https://www.google.bg/?gfe_rd=cr&ei=atkLWMHJIojY8AeikL_gDQ&gws_rd=ssl#q=each+unit+of+measure and even the top hit points to the oracle website.. is this something included in the API?
This is not subject to the API. Please check https://github.com/unitsofmeasurement/uom-domain/tree/master/retail, we might cover something similar there, units like CRATE were already started. Happy to use your help on that if you want to contribute.
JSR-310, which became the Java 8 date/time API
In the next few days, I could create and pull-request methods for converting a java.time.Duration to Quantity<Time> and vice-versa, plus reference implementations. Do you folks agree this would be useful?
Hi, JSR 310 was started long after 275 and took at least 3 more years after 275 was stopped (310 had been completely stalled at the time, so it played no role in the EC's decision to reject 275) before it was usable to Java SE 8. There is no API relevance by Java SE 8 or JSR 310, but please see https://gitter.im/unitsofmeasurement/uom-se and the respective implementation for Date/Time integration. It's all been done there already, using TemporalQuantity. So no PRs in the API project please, but if you want to help uom-se to improve the quantity.time package and its elements, please feel free to do so.
