Hello all
There is a technical problem for which the current situation is not
satisfying, and for which I have trouble to find the best action...
We needs a "Unit of measurement" framework. Because this is important to
so many domains (even the JDK has a TimeUnit class), we made a
standardisation attempts 12 years ago (JSR-108), which failed [1]. We
made a second attempt (JSR-275), which failed again [2]. GeoAPI - and
consequently current Apache SIS - currently have a dependency toward
this failed JSR-275 attempt. This obviously brings two problems:
1) JSR-275 namespace (javax.measure.unit) is not supposed to exist.
2) JSR-275 bugs will never be fixed.
After JSR-275 rejection, the main JSR-275 authors moved their API as
interfaces in the "org.unitsofmeasurement.unit" package under a BSD-like
license [3]. Those interfaces are implemented by the Eclipse UOMo
project among others [4], and his maintainer told me that they are
gaining acceptance in the Eclipse community.
However the maintainer told me that a sensor-related JSR have good
chances to start in 2013, could include units of measurement, and that
they want to go fast. This would bring yet another package name in the
mix (or maybe they would reuse the javax.measure.unit one - we don't
know). So the alternatives at this time are:
1) Keep JSR-275 for now, wait and see.
2) Adopt org.unitsofmeasurement interfaces, then:
2a) Adopt UOMo implementation
2b) Provide our own implementation
3) Define our own interfaces
On 1), we are already waiting for two years and I still have trouble to
figure out if yes or no a third JSR attempt will happen... On 2), the
problem is that the decision does not involve only SIS, but also GeoAPI,
and as a standardisation attempt we are better to be as sure as possible
that we will not change again if, for example, Oracle starts a new JSR.
On 2a), I have not tried this UOMo implementation. But I had some
trouble with the JSR-275 implementation. Many statics methods in the
Units class that I just committed today [5] are workarounds for JSR-275
bugs or limitations. Some methods like "valueOfEPSG" (scroll down until
the bottom of the page) are very specific to the geospatial domain and
unlikely to be supported natively by an external unit framework. The
NetCDF unit names ("degrees_east", "degrees_north") are also quite
specific, so maybe having our own implementation is not completely
non-sense. On 2b) actually we already have an implementation from old
JSR-108 days, so it could be easily refactored to
"org.unitsofmeasurement" interfaces. On 3), it would need to be done in
GeoAPI I don't think it would have a lot of support...
The GeoAPI working group is not active at this time, so I suspect that
we may have more discussion on this SIS list, then brings a proposal to
the GeoAPI list. This proposal (about interfaces only - the
implementation decision stay on the SIS side only) would need to be
written as a change request and posted before December 27 if we want it
to be considered at the next OGC meeting.
Any though, opinion, proposal would be highly appreciated...
Regards,
Martin
[1] http://jcp.org/en/jsr/detail?id=108
[2] http://jcp.org/en/jsr/detail?id=275
[3] http://www.unitsofmeasurement.org/
[4] http://www.eclipse.org/uomo/
[5]
https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/measure/Units.html
