Replace JSR 275 Units Library - STEMLab/geotools GitHub Wiki

Description

The JScience beta units library is responsible for javax.measure packages including SI and NonSI. We use this library to handle reference system measurement conversions.

JSR-275 was rejected and cannot be considered for use. We are stuck using the JScience beta (or considering one of the alternatives).

Reference code example using current JScience beta:

Measurable<Duration> time = Measure.valueOf(2, MINUTE);
long milliseconds = time.longValue( MILLI(SECOND));

The beta is method compatible with JSR-275.

References:

JSR-363 unitsofmeasure library

JSR-363 is the replacement proposal. The proposal is well underway with a unitofmeasurement organization on github.

  • units-api

    BLOCKER The interfaces are provided under a non-open source specification license which self destructs after two years or something.

    Kind of odd that they would let something this destructive into maven central.

  • unit-ri - for Java 7 and ME

    BSD License for the implementation, depends on on units-api above.

  • uom-se - for Java 8 and above

    BSD License for the implementation, depends on units-api above.

We cannot upgrade at this time, due to the specification license. Once this JSR is approved we would be in position to change our dependency, and perform a small bit of refactoring.

Critically the package names used for the API are similar to JSR-275 and the JScience beta.

JScience is available as 4.3.1, so it's no longer Beta: http://search.maven.org/#artifactdetails%7Corg.jscience%7Cjscience%7C4.3.1%7Cjar is available, but according to its POM it seems under Apache 2, not BSD

I hope you are aware, JSR-275 0.9.3, which GeoAPI 3.0 uses as of today http://search.maven.org/#artifactdetails%7Cjavax.measure%7Cjsr-275%7C0.9.3%7Cjar uses exactly the same "destructive" license, so you used it for more than 2 years now and it did not seem to self-combust so far (except, the JCP EC never approved it, so it's "inofficial" to "illegitimate" depending on who you ask)

UOMO

Seems okay, API has an open source and a commercial implementation.

uomo

More set up as an OSGi bundle, than as a jar we can use.

Hang tough on JScience beta (wait for release of JSR-363)

We have the option of using JScience Beta of JSR-275 (as long as the BSD-3 license on the beta holds up to review) until such time as JSR-363 is approved (at which point no package changes would be required).

As an example the header from NonSI.java:

/*
 * JScience - Java(TM) Tools and Libraries for the Advancement of Sciences.
 * Copyright (C) 2006 - JScience (http://jscience.org/)
 * All rights reserved.
 * 
 * Permission to use, copy, modify, and distribute this software is
 * freely granted, provided that this notice is preserved.
 */

And the pom.xml contained in the jar manifest has:

  <licenses>
    <license>
      <name>BSD License</name>
      <url>http://jscience.org/doc/license.txt</url>
      <distribution>repo</distribution>
      <comments>A business-friendly OSS license</comments>
    </license>
  </licenses>

Roll our own

Similar to the idea of [removing geoapi interfaces](Resolve GeoAPI 3.0.0 Incompatibilities) we could roll our own unit classes, even using the JScience beta code as a starting point.

Status

Choose one of:

  • Under Discussion
  • In Progress
  • Completed
  • Rejected,
  • Deferred

Voting:

  • Andrea Aime
  • Ben Caradoc-Davies
  • Christian Mueller
  • Ian Turton
  • Justin Deoliveira
  • Jody Garnett
  • Simone Giannecchini

Tasks

This section is used to make sure your proposal is complete (did you remember documentation?) and has enough paid or volunteer time lined up to be a success. Use initials to indicate volunteer, or ⚠️ where volunteer is neededs. Proposals that lack resources to be successful are unlikely to be approved.

  1. Add new dependency.
  2. Refactor code to new units library, and pass tests.
  3. Remove JSR-275 dependency
  4. Make a note on the upgrading page.
Add a custom footer
⚠️ **GitHub.com Fallback** ⚠️