Early Draft

[Werner Keil]

Hi,

JSR 363 is soon about to publish Early Draft.

Please have a look at the Spec on Google Docs: https://docs.google.com/document/d/12KhosAFriGCczBs6gwtJJDfg_QlANT92_lhxUWO2gCY
or the PDF snapshots on java.net: https://java.net/projects/unitsofmeasurement/downloads

Feedback is welcome either here on the mailing list or for those of you with java.net account feel free to use JIRA.

Cheers,

Werner

[Chapman Flack]

On 11/26/14 11:06, Werner Keil wrote:
> JSR 363 is soon about to publish Early Draft.
>
> Please have a look at the Spec on Google Docs:
> https://docs.google.com/document/d/12KhosAFriGCczBs6gwtJJDfg_QlANT92_lhxUWO2gCY
> or the PDF snapshots on java.net:
> https://java.net/projects/unitsofmeasurement/downloads

Hi,

It's possible I'm way too late with this suggestion (and it may have
been beaten to death in discussions I didn't see), but I think it could
be very useful to have more introspective access into a UnitConverter.

An example use would be: on a full environment with Java and a
comprehensive unit database, select any two obscure units and
construct a UnitConverter between them, then let some application-
supplied code-generator visitor be sent down the resulting UnitConverter
and its children, emitting custom code to perform that conversion on
some much more constrained device.

Doing this nicely would probably entail some attempt to enumerate what
basic kinds of UnitConverter may exist. My guess is there probably are
not very many. Two kinds are already treated specially with the
isIdentity() and isLinear() methods, but I could imagine a structure like:

interface UnitConverter {
interface Polynomial extends UnitConverter { getCoefficients(); }
interface Linear extends Polynomial { getSlope(); getIntercept(); }
interface Log extends UnitConverter { getBase(); }
interface Exp extends UnitConverter { getBase(); }
interface Rational extends UnitConverter {
UnitConverter getDividend(); UnitConverter getDivisor();
}
}

Am I crazy in thinking a small set like that would cover a large
fraction of UnitConverters in practice? Weird things like currencies
might not fit the scheme, so they might not implement any of the more
specific subinterfaces, and not be easily rendered into code for another
environment.

With the current API, if you get a converter and its isLinear() returns
true, you could pump two values through it and determine what it is, but
that's a little hackish and could get you an approximate result.

Another subinterface that might be of interest could be:

interface Inexact extends UnitConverter {
getRelativeError();
getDomainMin();
getDomainMax();
}

... for a converter that is known not to be using an exact conversion, but
has a known relative error for inputs in a certain range. So a converter
from km to [mi_i] could be linear with slope 15625/25146 exactly, or the
often-used approximate slope 5/8 with getRelativeError() returning 6e-3...

Chapman Flack

[Werner Keil]

Chapman,

Thanks a lot for the suggestions.

Your message was somehow caught by the spam filter but during review I saw it is a real message not the (usually Asian) spam we get here a lot which I always block...

Do you have a GitHub user?

While it could be necessary to sign a "lightweight" contributor agreement by JCP/Oracle in the near future (when JSR 364 defines a new way to contribute mostly for Individuals whether they are independent or employed somewhere) I am not sure, if we need that for RI or TCK as well as other implementations at this point.

I am not aware that as of now you'd have to sign the OCA (http://www.oracle.com/technetwork/community/oca-486395.html) to contribute to RI or TCK (will clarify at the next JCP EC meeting) although at least 2 EG members signed it for OpenJDK in addition to the JSPA.

At first sight it feels like these special sub-interfaces are better suited for either the RI, the alternate Java SE port or both, not the actual spec.

We have a few examples for that already, e.g. a so far only SE specific https://github.com/unitsofmeasurement/uom-se/blob/master/src/main/java/tec/uom/se/ComparableQuantity.java

or the Measurement interface you also read about in the Spec (since the SE port is more a PoC for Java SE 8 it is not mentioned in the Spec, nor are types that only exist there;-)

Especially in SE with Lambdas those suggested extensions could be used in a slightly more powerful way in the implementation. If a sub-interface, not an abstract class (like https://github.com/unitsofmeasurement/unit-ri/blob/master/src/main/java/tec/units/ri/AbstractConverter.java in the RI) was seen best for those ideas, Java SE 8 offers a new "default" body even in interfaces among other features. In the RI which must work in ME Embedded, too we already use alternatives, e.g. abstract classes instead of defining these in the interface already.

We would very much appreciate your input and contribution if you want to use GitHub or already do.

Thanks and Regards,

Werner

[Werner Keil]

Please find the Early Draft (0.7) version of the JSR 363 Specification on java.net:

https://java.net/projects/unitsofmeasurement/downloads

At least after the Christmas break, JCP PMO should publish the Early Draft on jcp.org.

We won't all go into "hibernation", but some may be less active during the holidays.

So for those who won't come by in the next couple of weeks

Merry Christmas and a Happy New Year,

Werner

on behalf of the JSR 363 EG

[Werner Keil]

Just before the end of 2014, the EDR was published on jcp.org: https://jcp.org/aboutJava/communityprocess/edr/jsr363/index.html

Happy New Year,

Werner

[Werner Keil]

Hi,

JSR 385 is about to publish an Early Draft soon (based on JCP.next it should be no later than 9 months after the JSR was approved)

Please hava a look at the Spec on Google Docs: https://docs.google.com/document/d/12KhosAFriGCczBs6gwtJJDfg_QlANT92_lhxUWO2gCY

The only EDR issue open is https://github.com/unitsofmeasurement/unit-api/issues/36 according to the Kanban Board https://github.com/orgs/unitsofmeasurement/projects/1

While comments and recommendations about arithmetics have also been added to JavaDoc, actual measures like RI or API changes are for the next stage as per our pre EDR call. 

A new project in the GitHub organization exists for the PR of JSR 385: https://github.com/orgs/unitsofmeasurement/projects/2

Kind Regards,

Werner