Any now-usable open source implementation?

[Chapman Flack]

Hello,

I would very much like to be a user of the Units API. I have
downloaded both the 0.5.2 (org.unitsofmeasure) and 0.6-RC1
(org.unitsofmeasurement) jar files. Now of course
I can still do nothing with units until I find any usable open-source
implementation
of the interfaces (either 0.5.2 or 0.6).

The List of Known Implementations refers to JScience and UOMo. I have
spent hours
browsing JScience source and the contents of jscience-5.0-SNAPSHOT.jar
without
finding any trace of an implementation of either Units API version. Is
there a separate
download that I need, or something I have overlooked?

At least I have not spent fruitless hours looking at UOMo because
there is nothing
to look at. The Download page offers two file.zip links that lead to
"file unavailable"
error pages, and the Getting Involved (CVS, wiki) page gives a 500
internal server
error.

Can someone tell me if there exists at this time any usable,
downloadable, open
source, functioning implementation of any version of this Units API at
all? Even better,
one that can stand alone with few dependencies (my target is a mobile
device that
will not likely have Eclipse installed!)?

If there is a usable implementation anywhere and you can help me find
it, I will be
happy to contribute to your wiki about it so that other users do not
lose the same
hours I have trying to find it.

Thank you,
Chapman Flack

[Werner Keil]

Dear Chapman,

Thanks a lot for the interest. Eclipse UOMo Units is available and ready to use now.

Please excuse, as the project has just been created, it is currently still available as code, but thanks to Maven (Hudson at Eclipse.org pending) everything is built at a single click and all builds succeed right now.

UOMo Units has very few dependencies. Beside Unit-API it is OSGi ICU4J (which can be large, but multiple versions all the way down to Android are available) UOMo Core and potentially some dependencies of an OSGi Runtime like Equinox, Felix or Virgo.

The footprint of UOMo itself is less than 150kb, that's even together with Unit-API still less than the JSR-275 JAR alone used to be while the JSR was still in proposal phase.

I'll present UOMo at the next JUG Chennai Meeting on Dec 11th or the week after. At least then I plan to also create downloads like binaries and a few examples, mostly inside an OSGi Container or Eclipse Workbench.

Please check out http://www.eclipse.org/uomo for more details and the latest news.

Kind Regards,

-- 

Werner Keil | UOMo Lead | Eclipse.org | Agile Coach, Principal Consultant | emergn limited

590 Madison Avenue. New York. NY 10022 | 68 Lombard Street. London EC3V 9LJ UK

UK Mobile:   +44 770 7823984 | DE Mobile: +49 176 83222017 | Skype: werner.keil

US Toll Free:  +1-877.964.1981 | Worldwide Toll Free:  +800.225.53482

www.emergn.com

success is a planned event...

* JUG Chennai: December 11, Chennai, India. Werner Keil, Agile Coach and Principal Consultant, will be presenting "Eclipse UOMo and JSR-308 - Type Annotations"

* STP Conference & Expo: March 24, 2011, Nashville, TN. Werner Keil, Agile Coach and Principal Consultant, will be presenting "Agile Test Automation"

[Chapman Flack]

Dear Werner,

Thank you for the rapid reply. I am glad you mentioned versions of the
dependencies available even down to android, which happens to be the
platform I had in mind (and this my first essay into android app
development). I am also not experienced with the OSGi development
model, which seems rather different from the native android model.

I did some searching about OSGi after my first post and read about the
early challenges of supporting the necessary dynamic bytecode
generation
on android (where the Dalvik VM requires its own different bytecode).
It
appeared that early installations may have required rooting the phone
and granting world-write on a dalvik cache directory (with unspecified
implications for the security model). A blog entry suggested that a
change in android 1.5 had simplified the problem, but didn't have a
reference link to the change and I have not yet found a more detailed
explanation.

If you know of any existing efforts to use UOMo Units on android,
their
experiences would be of great interest to me, as it sounds a bit
bleeding-edge for me to experiment with at the same time I am
developing
for android the first time. I am also curious whether this approach
can
lead to an application that an end user will install with the standard
android market experience and no unfamiliar technical steps. (And, of
course, how many licenses are involved to be checked for
compatibility.)

On Nov 30, 2:50 am, Werner Keil <werner.k...@gmail.com> wrote:
> Please check out http://www.eclipse.org/uomo for more details and

Thanks - I see that this morning the "get involved" git link works (no
longer gives the 500 internal server error). The "download" link still
leads to two dead file.zip links ("The selected file is invalid, or it
is no longer available for download").

Thank you for the information,
-Chap

[Werner Keil]

Dear Chapman/all,

Glad my information helped and that you also plan to use UOMo on Android. I am currently in close touch with the Sequoyah Project at Eclipse which backs many features in Motorola's IDE MotoDev for Android. If we find places where UOMo is beneficial for the IDE, we shall also explore them, but most of that may need till Incubation has passed. Having the 5+ years of mature heritage of the JSR-275 proposal plus earlier versions of another JSR (that project now is called UCAR) and JScience means, it is quite mature, even if Eclipse requires all projects to undergo a 0.x release incubation phase. Some like Virgo with vmware's commercial pressure behind it, made it to 1.x or 2.x almost immediately after creation, and Jetty also seems to have kept its version numbers.

I had a working JSR-275 demo more or less based on the "travel fuel cost" demo by JScience ready and working in Android emulator on "Android Day Munich", the same day the G1 was introduced to the world. To us at the event through a live video conference with Page&Brin in NY. The same app runs on my Samsung Galaxy 7500 with Android 1.6 also. Although the battery of that device is total crap. Hope, the Nexus2, rumoured to be from Samsung or the Galaxy Tab are significantly better on that? The main OS is better than the battery, and word completion even much better than the iPhone all the way till 3.0. It makes up bogus words sounding like the "Nell" movie and her language

Java2Days and the GTUG meeting I spoke at about Android 2.2 again asked me for demos and slides, so I may actually write a Froyo version of the UOMo travel demo for that purpose and upload it on the UOMo download page as soon as that's ready.

Regarding the payload, either Android or Harmony are ideal environments for UOMo, as they bring ICU4J already as part of the system. Like Eclipse. Thus you may find different "distros" or feature bundles of UOMo, one for platforms where ICU4J, OSGi or other dependencies are known to exist, and one "Full Download" containing even a standalone JAR for ICU4J.

For Java SE 8 and related JSRs, I am working on evolving the PoC, a JSR-308 committer has written to use Type Annotations with Units of Measure, too. This may eventually become a new Unit JSR, but I can neither guarantee a timeline, nor tell you, if the package may again be javax.measure. If it was, we may use 0.9.6 (or 0.9.5) which is beyond the last release at Kenai.com. If the package name was different, any number is possible, but considering it may aim for a much faster progress, close to 1.0.0 seems like a good idea.

UOMo will be sure to be compatible with whatever that may look like. Thus, using the Unit-API compliance in UOMo not only ensures, you may some day switch to other implementions if you feel those matched your purpose better, it'll also guarantee, your code is mostly compatible with possible future versions of a Unit-JSR. Where ICU4J and its compatibility with Eclipse, Android, Harmony or some Google products like GWT and Google Finance suit your needs better, that is the second way, UOMo allows you to fit into established standards and frameworks. In Eclipse 4 or based on Java 8 there may be UOMo versions based on other technologies like JSR-308 or 310, and of course a Unit-JSR if it was resurrected before SE8, but for all current environments ICU4J is pretty certain to stay. 

P.s.: Regarding the footprint, one has to keep in mind, JScience also comes at least with Javolution. Jean-Marie likes Android, but I'm not sure, if he has any plans to port that to Android?

Kind Regards,

Werner

[Werner Keil]

Are you on the JScience mailing list, too, or have you missed Jean-Marie's reply?

Please excuse him btw, beside his other "baby" JScience, his daughter was just born a week ago

Regards,

Werner

----- Original Message -----

From: Jean-Marie Dautelle

To: unitsof...@jscience.dev.java.net

Sent: Monday, November 29, 2010 6:24 PM

Subject: Re: [unitsofmeasure] Does a JScience org.unitsofmeasure.* implementation exist?

Hi,

JScience implementation has not been released yet. It will be released few days before Christmas (in about 20 days).

Cheers,

Jean-Marie.

[Chapman Flack]

On Nov 30, 4:25 pm, Werner Keil <werner.k...@gmail.com> wrote:
> Are you on the JScience mailing list, too, or have you missed Jean-Marie's
> reply?

I think I am not on that mailing list but that I received his reply
directly. Thank you for checking and forwarding it.

-Chap

[Werner Keil]

Although no immediate effect on UOMo comes from that, Google put ICU
4.4 in a prominent place listing it among highlights of Gingerbread:
http://developer.android.com/sdk/android-2.3-highlights.html

UOMo Units currently works as far back as ICU4J 4.0, so older versions
of Eclipse or Android work without problems, too.

[Werner Keil]

Martin/all,

Thanks a lot for sharing this request.

As Jean-Marie already mentioned, at least indirectly, default unit
systems like SI are now part of implementations as many of its types
rely more or less directly on implementing classes like BaseUnit,
TransformedUnit, etc.

UOMo calls it SI, and although package-local to support other formal
system classes, NonSI is also there. The class to find INCH now is
USCustomary. ICU4J, the underlying Unicode and Globalization Framework
uses both these terms internally, too, so I decide to stick with them.

JScience may or may not call them like that, and unless any of those
classes/interfaces ever got back into a common spec, it is free for
every implementation to declare unit systems as they like. UOMo has
some others in development, some also specific to UCUM or local
requirements, e.g. for Asian countries like India or China. Which
ICU4J again supports with corresponding calendars.

As for the code, I cannot say for sure, that an equivalent to
RelativisticModel currently exists in UOMo or underlying frameworks
like ICU4J. That is the only case, all other classes exist while some
may be defined by ICU4J (like improved forms of BigDecimal, etc.)

The monetary/trip cost example from JScience:
http://www.jscience.org/api/org/jscience/economics/money/package-summary.html#package_description

Is a bit of a quasi TCK I used as of JScience4. The results are
identical (except a bit of rounding or formatting) although UOMo
Business is also still being finalized for some parts like Currency
Conversion, so that part may look a bit different at the moment. All
other figures match and could in most cases withstand a JUnit type of
test (even without calling it a JSR for now, we may create such tests,
as long as our "TCK" is open and non-restrictive ;-)

Kind Regards,
Werner

-------- Original-Nachricht --------
> Datum: Thu, 16 Dec 2010 12:02:04 +0100
> Von: Martin Desruisseaux <martin.de...@geomatys.fr>
> An: unitsof...@jscience.dev.java.net
> CC: tro...@IMR.no
> Betreff: [unitsofmeasure] State of implementations?

> Hello all
>
> We got the following question from a user about JScience implementation of
> Unit-API. Does someone could give us some clues?
>
> On a related side, I would like to take the opportunity for asking if
> there is
> any news on the implementation side (JScience and UOMo)?
>
> Regards,
>
> Martin
>
>
> > I thought it would be a good idea just to make a small example for
> myself and downloaded:
> >
> > jscience-5.0-SNAPSHOT.jar and unit-api-0.6-RC1.jar
> >
> > I included these jar files in the project and tried to cut and paste an
> example from the javadoc.
> > Obviously these examples are not complete and the complete examples I
> found in Java World Articles etc was with the previous javax.* interface.
> >
> > Here is my source code:
> >
> > package unitsofmeasurements;
> > import org.jscience.mathematics.number.Float64;
> > import org.jscience.physics.amount.Amount;
> > import org.jscience.physics.model.RelativisticModel;
> > import org.unitsofmeasurement.unit.Unit;
> > import org.unitsofmeasurement.unit.SystemOfUnits;
> > import org.unitsofmeasurement.quantity.Length;
> > import org.unitsofmeasurement.quantity.Mass;
> > public class Main {
> > public static void main(String[] args) {
> >
> > RelativisticModel.select(); // Selects a relativistic model.
> > Amount<Float64, Length> x = Amount.valueOf(100, NonSI.INCH);
> > x = x.plus(Amount.valueOf("2.3 µs")).to(METRE); // Length and
> Duration can be added.
> > Amount<Float64, Mass> m = Amount.valueOf(12,
> Unit.ValueOf("GeV")).to(KILOGRAM); // Energy is compatible with mass (E=mc2)
> >
> > }
> > }
> >
> > THE PROBLEM: The static import of SI.* and NonSI.* I am not able to find
> them ????
> >
> > Can you give me a hint ?
> >
> > Best regards
> >
> > Trond