Reintroduce UCUM

[keilw]

While the previous UCUM system based on JScience 5 was incomplete, unlike other unit systems UCUM is publicly available (www.unitsofmeasure.org) and free of charge, so a unit system looks OK here unlike e.g. ISO80k which currently cannot be made available Open Source

[keilw]

Also see #4

[garretwilson]

Thank you so much for bringing UCUM back in, @keilw . I also see that you've added some other issues for completing the UCUM implementation and updating it to the latest spec.

I'll gladly get one of my developers working on some of these tasks as soon as possible. Before getting started, though, it would be nice to get a bit of context with an overview of the situation for us newcomers:

• What is the state of the current state of the UCUM implementation (which you just brought back in)?
• Does the UCUM implementation already implement JSR 363 final?
• I'm inferring from some of your comments that the UCUM implementation is functional and usable as-is, but is simply not complete. Is that basically the situation?
• After we get the code completed and updated to the latest spec, do you think we could get a new build on Maven pretty quickly?

As far as procedure:

• Once I identify a task for one of my team to work on, can I ask you to assign that task to them to help track the implementation?
• Do you prefer that they do a pull request directly to uom-systems master; or do you prefer that I fork uom-systems to my organization GlobalMentor, Inc., do work on the fork with my team, and then do a pull request from the fork?

Thanks, and I look forward to getting started!

[keilw]

Does the UCUM implementation already implement JSR 363 final?

Yes it does, uom-se 1.0.4 (http://search.maven.org/#artifactdetails|tec.uom|uom-se|1.0.4|) is the most recent Java SE 8 implementation of JSR 363 Final API.

After we get the code completed and updated to the latest spec, do you think we could get a new build on Maven pretty quickly?

At the moment, there is a Milestone 0.7 https://github.com/unitsofmeasurement/uom-systems/milestone/3 proposed for the end of March. If we find out something takes longer, we could either move the date a bit or schedule it for a new milestone (as before that would likely be 0.7.1 etc. I just thought adding UCUM again deserves a first decimal bump)
#60 is a candidate, but I did not want to force it into the 0.7 release yet. Let's see, if any of those new units could even be there (UCUM 1.9 was released 3 years ago, a little before the Java SE implementation first started) and which of them are how relevant for practical use. If some are not that highly used, they could be deferred to a minor upgrade like 0.7.1, too.

Do you prefer that they do a pull request directly to uom-systems master; or do you prefer that I fork uom-systems to my organization GlobalMentor, Inc., do work on the fork with my team, and then do a pull request from the fork?

That (forking it into either your personal or organization repo, then when something finished propose a PR to uom-systems) sounds best.

Thanks for offering to help out with it.

[keilw]

I trust you have no problem using Java SE 8 or above in your projects. Please let us know if otherwise (UCUM is unlikely to work with Java ME 8 in this form, but it would be possible to make it work on SE 7 if a strong requirement exists, of course there is no cheap or easy support for SE 7 now, so it makes sense to use 8 when possible;-)

[garretwilson]

I trust you have no problem using Java SE 8 or above in your projects.

None at all! In fact I would prefer to use the latest Java 8 features such as Optional and Stream (where appropriate, of course.

[garretwilson]

That (forking it into either your personal or organization repo, then when something finished propose a PR to uom-systems) sounds best.

OK. I'll fork everything and have a meeting with my developers/students in the next few days and determine what we need to do.

[keilw]

We do, Optional was explored, but unfortunately it has some major issues with Generics and the way the typesafe Unit/Quantity system uses them. I know we experimented with it in the Range SPI class in uom-se, but the result caused some problems with the current Java type system. Streams and Lambdas are used in uom-se. If some of you feel like helping the SE implementation directly, we would ask those to join the JCP as Associate Members, so those can also be mentioned as Contributors on https://jcp.org/en/jsr/detail?id=363 like Nathan. The SE implementation may become the RI of a future JSR version, so we ask for that to be on the safe side. UCUM contributions are not so problematic. If those who help had no problem signing the Eclipse Contributior Agreement (http://www.eclipse.org/legal/ECA.php) that would allow to merge the type-safe UCUM system with UOMo UCUM if we feel that's appropriate in the future. That is up to you, we/Eclipse won't need it now, just wanted to mention it.

[garretwilson]

OK I've forked this repository to the GlobalMentor organization. I have a meeting with the developer who is going to be working on this, and if it needs more resources I can bring some students in, but for now it looks manageable by one or two people. I want to get this addressed as soon as possible so it can get in the next release.

We'll be using the issue system for this repository so you can track the progress and answer any questions we have. (I'm sure there will be several.) Please keep us updated if the status changes or any other news related to UCUM implementation. Thanks.

[keilw]

Thanks. If you want to document you can use this ticket (although it's closed, because it was mainly to create the module) or one of the other UCUM related. If you feel it works better, you can also add new tickets.

[garretwilson]

I'm going over this with GlobalMentor developer @magnonasc right now. I'm recommending that he approach this in several steps:

1. Create a separate issue to merely verify the current UCUM implementation and bring the comments up-to-date with the latest specification headings. (I note that some of them seem to be referencing older versions of the specification. For example in TYPESETTER'S LENGTH UNITS: UCUM 4.4 §39, it appears that "typesetter's lengths" is now §42.
2. Fix any bugs such as UCUM: some results like "m/s" are not formatted correctly #21.
3. Address the missing units that are mentioned in the current implementation (e.g. SECTIONS §41-§43 skipped; implement later if needed) for Add missing UCUM units #59.
4. Implement units added in later versions of the UCUM for Add units from UCUM 1.9 #60.