Use Advanced Search to search the entire archive.
[jsr363-experts] JIRA backlog cleaning
- From: Werner Keil <
>
- To: "
" <
>
- Subject: [jsr363-experts] JIRA backlog cleaning
- Date: Tue, 24 Nov 2015 12:39:40 +0100
Dear Experts,
While PR is ongoing, aside from feedback directly by the EC (none so far)
there are suggestions and (at least to extensions like uom-systems also
outside the EG) improvements beyond the 0.8 release. Which go into the next
(0.9) Snapshot.
About a dozen obvious JIRA tickets went into the next iteration (Public
Draft, so it's more or less planned for the first half of 2016, should
there be any major concerns from the Public Review, we could also
potentially do another PR2, but le't see)
A few in the backlog I am rather hasitent to include. Please look at
https://java.net/jira/browse/UNITSOFMEASUREMENT-77
https://java.net/jira/browse/UNITSOFMEASUREMENT-98
https://java.net/jira/browse/UNITSOFMEASUREMENT-124
And provide input (best with the ticket) what you think about them.
About #77
Actual tests and examples demonstrated, if you return a Quantity subtype
like Temperature, etc. you may do that in some cases, but especially
Quantity operations by nature don't know the exact return type, so
Quantity<?> is often inevitable. And rather than a fairly safe asType()
operation, only an explicit cast could offer the value as say Temperature.
public final class TemperatureAmount extends AbstractQuantity<Temperature>
implements Temperature
in
https://github.com/unitsofmeasurement/uom-impl-enum/ is a case, where
TemperatureAmoun also implements Temperature, but the QuantityFactory
defined by the spec/API right now, returns Quantity<Q> not Q, and both do
not seem interchangable or compatible right now.
Implementations like
https://github.com/unitsofmeasurement/uom-impl-enum/
are free to also implement the concrete interface, but on an API level it
seems safer and more flexible to deal with Quantity<Q> instead of Q.
About #98
It looks like Bootstrap and SystemOfUnitService offer an API level access
to unit systems including the one provided by the RI, so we probably don't
need to expose it by the API.
About #124
Several aspects of UCAR
https://www.unidata.ucar.edu/software/thredds/v4.3/netcdf-java/v4.0/javadocAll/ucar/units/UnitDB.html
like "addSymbol", or "addAlias" we consider or already added (called
label()) to UnitFormat. As they primarily concern formatting and parsing,
not so much retrieving units from a unit system or DB (of course there's
room for interpretation)
So IMO we may not need to specify a UnitDB in addition to SystemOfUnits and
its SPI lookup service.
Thanks and Regards,
Werner
[jsr363-experts] JIRA backlog cleaning
|
Werner Keil |
11/24/2015 |