Use Advanced Search to search the entire archive.
[jsr363-experts] EDR State so far (and of last week's F2F)
- From: Werner Keil <
>
- To: "
" <
>
- Subject: [jsr363-experts] EDR State so far (and of last week's F2F)
- Date: Tue, 20 Jan 2015 18:24:14 +0100
Dear Experts,
As you know we had a (slightly smaller after Morocco JUG is not in the EC
any more) EG F2F between Leonardo, myself and SouJava was represented not
only by Bruno but by EC alternate Yara and her husband who gave a nice IoT
talk right before our JSR 363 presentation.
Bruno also mentioned Adopt-a-JSR activities in Brazil during his
presentation that day.
There were no significant issues or questions raised by the EC, so while
many of them probably focus a bit more on the legal side and licensing,
should there be anything severe to raise, I am sure they would have done
so. Based on the most vital input outside the EG or EC coming largely via
the mailing list
https://groups.google.com/forum/#!forum/units-users we
also asked how non EG members raising issues either there or (if they use
java.net) JIRA, GitHub, etc. should be treated if their input may result in
a contribution to either code or spec (even just a line of JUnit test or
similar)
Patrick and other EC members with most insight into IP topics agreed we
should not face legal or other problems if members of the "wider" community
help us find bugs or improve the JSR. If anybody does this very often, we
should ask them if they want to join the JCP and EG, that's happened before.
Unless we get significant feedback to the current EDR I am not sure it
justifies an EDR 2. Leonardo agreed we should wait and see what comes
(there's exactly 1 week left and though there is no ballot here some EC
members may just have noticed it's out from our talk;-)
The discrepancy between UCUM definitions of units it covers (like POUND and
many others) and the way the UCUM Unit System displays them in the RI (and
SE port, they are exactly the same here) is currently the only unsolved
issue based on the mailing list input:
https://java.net/jira/browse/UNITSOFMEASUREMENT-109
All other bugs or errors they mentioned (e.g. wrong conversion factors or
occasional formatting bugs) are now addressed in the HEAD codebase of API
and mostly implementations.
Please have a look at
https://java.net/jira/browse/UNITSOFMEASUREMENT-109
if you can.
Concrete classes like TransformedUnit behave mostly as the Unit interface
specified getSymbol() or getName(). The only difference is, that somewhere
in the process the symbol of the parent unit was taken over by
TransformedUnit.getSymbol() now. That is the only case where the Spec (or
JavaDoc) says differently. Otherwise it should return null except for a
BaseUnit or those other types with a distinct symbol provided.
However, that also contradicts what you'd get if you parse the entire UCUM
file (similar to e.g. UOMo UCUM and any other Java implementation) where
for POUND (depending on which exact one you take;-) we'd see
getSymbol()="lb_av"
getName()="pound"
And the parent unit would also have to be "g" not "kg" as per UCUM
definitions.
Currently getSymbol() would either be null or show "kg" getName() will be
null in most cases and the parent unit is "kg" not "g".
If we at least got the UCUM system to return it like that or look for even
an alternate backing (e.g. loading the actual ucum-essense.xml, of course
it may change over time, but ICU4J also chose some level of static
accessors like KILOGRAM, etc. so we might still do that even if the
available units in the collections methods could in theory differ from the
number of constants)
it's up to SI to do this differently or other systems like US, Imperial,
etc. UCUM should be consistent with the XML file, that seems most important.
Of course we are not obliged to add UCUM support to the RI at all, we may
de-scope it and leave that to other implementations like JScience, UOMo or
others.
Some other questions were answered mostly by Mark Reinhold. There is no
"pick a class you want" standard. So you either have to include an entire
package like "quantity" as a whole or leave the entire package out. Since
all quantity types are only "type markers" we won't have to implement every
single one with a concrete class AFAIK but if say a class like SI used all
of them in a Unit<Q> CONSTANT = ... syntax, ideally every instance of <Q>
should represent a type in the "quantity" package. That's regardless where
the SI class ends up being btw. even if it remains in the RI that would
make no difference.
Mark explained the OSGi approach of "package visibility" will be applied by
Jigsaw in Java 9, too. Even if it may not use the same names, a "module" in
Java 9 behaves like an OSGi "bundle" so you can either hide the entire
bundle and its content (or not even use it) or show all of it. The idea of
"stripped implementations" seems so complex to lawyers (and probably also
technical feasibility) that it does not seem to come at all. Once a fully
modular JDK and solutions that make proper use of it are out, you can chose
custom-sized apps based on that, but you can't say cut a module in half
without breaking compatibility.
Regards,
Werner
[jsr363-experts] EDR State so far (and of last week's F2F)
|
Werner Keil |
01/20/2015 |