Ticket #1621 (closed task: fixed)

There is some discussion of units in ticket #445.

I have also done some initial investigation into JScience, ucar udunits, and uomo.

JScience 4.3.1 is the current version. It seems lightly used in the developer community. It implements JSR 275 which is a somewhat dead specification. The developers forums are nearly all spam. 4.3 was released in 2007 and had a bugfix release in 2011.

JScience 5.0 will be the implementation of the units of measure interface api. It might be what we need. But it was hinted to be ready in Dec 2011 and yet no release 13 months later. Again a pattern of a possibly dead project. Contacting Jean Marie Dautelle (lead developer) might clarify things.

uomo is a units library that is less ambitious than JScience. JScience wants to be a large library that supports lots of scientific programming functionality. In contrast uomo just wants to support units. It is actively developed but might be immature. It also shoots for the units of measurement api. Contacting Werner Keil (lead developer) might clarify things.

It's possible to develop using either JScience or uomo since they support the units of measurement api. We could choose one and switch to the other if there are issues. Jean Marie and Werner seem to be collaborators on units related projects.

TODO - look at ucar udunits more. It is older and old colleagues of Curtis pointed us in the direction of JScience when asked about udunits. It is a C library (though the NetCDF Java team might possibly release a Java implementation). It has had updated releases as late as 2011.

Sent messages to two forums in hopes of determining the status of uomo and JScience 5.0

To mailing list unitsofmeasure@… re: JScience 5.0 in hopes Jean Marie will see.

Resulting thread ==  http://java.net/projects/jscience/lists/unitsofmeasure/archive/2013-01/message/0

To forum  http://www.eclipse.org/forums/eclipse.uomo in hopes Werner will reply

Resulting thread ==  http://www.eclipse.org/forums/index.php/t/448936/

Note I tried to determine the fewest jars required by uomo given the ability to define units in terms of other units and perhaps to parse them from strings. To do just this requires 6 jars (hopefully this is not too many dependencies):

• 3 from uomo itself: core, ucum, and units
• the units of measure api interfaces jar
• icu4j: enhanced unicode classes
• osgi

Here is the test stub program:

import org.eclipse.uomo.ucum.Parser;
import org.eclipse.uomo.units.SI;
import org.eclipse.uomo.units.impl.system.Imperial;
import org.unitsofmeasurement.quantity.Length;
import org.unitsofmeasurement.unit.Unit;
import org.unitsofmeasurement.unit.UnitConverter;

public class Main {

/* ARG - it looks like uomo core requires osgi */

public static void main(String[] args) {

SystemOfUnits system = SI.getInstance();
Unit<Length> km = SI.METRE.multiply(1000);
Unit<Length> foot = Imperial.INCH.multiply(12);
UnitConverter converter = km.getConverterTo(foot);
Parser<String, Unit<?>> p = null;
Unit<?> userDefinedUnit = (p == null) ? null : p.parse("m/s^{2");
System.out.println("0.1 km in feet = " + converter.convert(0.1));}

}

}

I asked a question here ( http://www.eclipse.org/forums/index.php/t/457564/) about avoiding osgi in uomo. It seems osgi is a key component of the design. ctrueden had mentioned that there is an acceptable level of osgi integration that IJ2 could support. I am asking him to review whether uomo's needs go beyond that level.

Uomo is still in development. Werner was not planning on releasing as maven jar until at least version 1.0. I don't think we want to be tied to a such a moving target. I have instead made a simple UnitService set of classes in the imglib2-meta package that for now uses UCAR UDUNITS. This has been merged to master and could use a little cleanup. For now I will close this ticket. We can revisit uomo support in the future.