UCUM units still giving wrong symbols

[David Kincaid]

I thought I would give the library another chance now that we are finally able to move up to Java 8. I am seeing that UCUM.POUND.toString() is returning "lb" and UCUM.POUND.getSymbol() is returning null. Shouldn't one of these two return "[lb_av]"?

Thanks,

Dave

[Werner Keil]

Note, to modularize unit systems, a new UCUM project is created here:

https://github.com/unitsofmeasurement/uom-systems/tree/master/ucum

We already removed UCUM from the RI mostly for size reasons. 

The current UCUM module is based on uom-se, though it could be possible to create another one for the RI.

The definition of Unit.getSymbol() says:

@return this unit symbol, or {@code null} if this unit has not

     *         specific symbol associated with (e.g. product of units).

And units like POUND are usually instances  of TransformedUnit. Which is why the symbol returns null in those cases.

The "late binding" UCUM implementation which loads ucum-essence.xml (currently at Eclipse UOMo) is not based on TransformedUnit, therefore you'd get the symbol there, but it does not provide constants, that would contradict the dynamic nature of that UCUM bundle. 

So do you feel the need for a "static binding" version of UCUM or would the "dynamic binding" version (which behaves as you assume) work, too?

If you have a GitHub user already or can join, please raise tickets or comment on existing ones (https://github.com/unitsofmeasurement/uom-systems/issues/4 exists for "ucum-essence.xml"

Another good reason for separate unit system modules is, that it makes it easier for others to collaborate on these (while RI and API are subject to EG and JCP membership)

Thanks and Regards,

Werner

[David Kincaid]

Nice! I really like the idea of separating the unit systems like that. In that case is the idea that we would only need the javax.measure jar and the ucum jar then in our project if we're only using UCUM or would we still need the RI or SE jars?

Let me think a bit about your other questions. There is value in both, so I'm thinking about the trade-offs. Using UCUMFormat.format with the units gives me the UCUM symbols that I'm looking for.

Thanks,

Dave

[Werner Keil]

Yes, you would normally need at least an implementation, either RI or SE, (Eclipse) UOMo or others.

While uomo-ucum does most of the implementation itself (so for "late binding" UCUM one could imagine a smaller number of JARs) it has other dependencies, e.g. XML libraries for handling the ucum-essence.xml.

Let us know which variant you prefer. I am not sure, if a combined UCUM library was a good idea. Such combination may consist of several bundles on top of the API and/or implementations (please also see the diagram in https://github.com/unitsofmeasurement/uom-systems, so at least for "strongly-typed" UCUM it is likely to require at least "si-units" as well, since we aim for reuse wherever possible)

Regards,

Werner

[Werner Keil]

Factoring UCUM out into https://github.com/unitsofmeasurement/uom-systems/tree/master/ucum is now done.

Note, it is currently the most volatile system module ("common" including systems like "US Customary" work perfectly fine) largely due to UCUM so far being SE (8+) based while all other systems use the RI.

Especially for Embedded I see value for an optional UCUM bundle using early-binding in that case. 

For SE/EE both or the XML-based late-bound version could make more sense, which sounds like an overhead to most embedded systems.

Regards,

Werner

[David Kincaid]

I have the current version of uom-se (0.7) using UCUM working well after putting a couple of wrappers around the format and parse to make them easier to use and making sure all the developers know not to use toString() or getSymbol() on any of the units.

Now that I have it working how will the factoring out of UCUM affect how we are using the library?

- Dave

[Werner Keil]

IC, it should work in the new module, as the new place https://github.com/unitsofmeasurement/uom-systems/blob/master/ucum/src/main/java/systems/uom/ucum/format/UCUMFormat.java pretty much mirrors the prior class in uom-se.

The 0.7 tag would allow a patch of uom-se, but I am not sure, if a separate branch for that makes sense?

A pull-request for the UCUM part would be welcome if you're able to factor those wrappers into the new module.

A problem right now is, si-units currently exists only for the RI, but UCUM is/was always based on SE8/uom-se.

There are some base types like AbstractUnit which are not directly interchangeable in the same binary form (they implement the same API but e.g. tec.units.ri.AbstractUnit cannot be cast to tec.uom.se.AbstractUnit) Except AbstractSystemOfUnits most abstract base implementations depend on other implementation specific elements a lot, it seems extremely hard to push that up into the API (like some JSRs do with GenericServlet, GenericPortlet, etc.) and for sometimes very different environments like Java ME vs. SE it currently feels better to leave that to each implementation.

Actually I fixed the RI dependency by providing 2 system classes based on UOM-SE internally to the UCUM module. Please give it a try. A single unit test category in the jackson-serializer (based on UCUM and UOM-SE) failed related to parsing and printing "km" (for some reason to investigate it is m.1000 but that might be related to e.g. the problem of TransformedUnits or "Hz")

All other tests that don't fail for known problems in both RI and SE-port (e.g. "Hz") pass now so please give the uom-system a try. We'd love to see a pull-request there if you can.

Thanks,

Werner

[garret...@gmail.com]

All the links posted on this thread are now broken. I can't find a UCUM implementation of JSR 363 UnitFormat anywhere. See my question on Stack Overflow, UCUM UnitFormat for JSR 363.

I simply want to create a MILLI(LITRE) unit (as per JSR 363 RI) and format it as UCUM "mL". I would have thought it would be super-simple.

Garret

[Werner Keil]

I somehow lost track, but it seems the CQ for Unit-API was approved around the end of last year: 

https://dev.eclipse.org/ipzilla/show_bug.cgi?id=12206

So I'll start exploring how UOMo could leverage that based on what I mentioned, a UnitFormat backed by the XML essence, not a full translation of every XML tag into a Java constant, at least for now.

We're happy if somebody volunteered to help with the strong typing in UOMo, too. 

Everyone who does had to sign the ECA or become an Eclipse committer though.

Werner