Use Advanced Search to search the entire archive.
[jsr363-experts] [VOTE] descope UCUM support from JSR 363 RI
- From: Werner Keil <
>
- To: "
" <
>
- Subject: [jsr363-experts] [VOTE] descope UCUM support from JSR 363 RI
- Date: Wed, 21 Jan 2015 12:37:45 +0100
Hi,
As mentioned in the message yesterday and also discussed with Chris in
GChat, I'd like to hear your opinion on removing the UCUM system and at
least renaming UCUMFormat, etc. to something like "SimpleUnitFormat"? (see
JDK equivalents;-)
To reduce size and effort for RI and to some extent also TCK (though most
of it is about at least ONE implementation of UnitFormat sticks to its
definition) and avoid discrepancies between the UCUM system as it is now
and implementations loading the ucum-essence.xml file directly (where
especially Unit.getSymbol() may return a different result based on the XML
file than what's currently defined in the SI system)
Although e.g. ICU4J or earlier JSRs like the ME attempt 256 by Nokia apply
a mix between static constants like KILOMETER, CUP,... and a flexible type
system allowing to add your own MeasureUnit with string-based quantities
(thus neither is never going to be compile-type safe) which we may also do
for UCUM, there are other obstacles for RI, especially depending on XML
support if we use the ucum-essence.xml file at least somewhere. ME does not
always support XML so UCUM for ME would have to be a separate (optional)
module anyway. Which is why it's a good idea to leave it out of the RI and
where there's demand on ME do this separately.
For uom-se I see no reason to remove them but they should be fixed and (at
least towards Java 9) be turned into a module, too.
Please vote +1 or -1 if you don't say anything that's as good as abstaining
here;-)
Thanks,
Werner