Use Advanced Search to search the entire archive.
[jsr363-experts] Re: [VOTE] descope UCUM support from JSR 363 RI
- From: Werner Keil <
>
- To: "
" <
>
- Subject: [jsr363-experts] Re: [VOTE] descope UCUM support from JSR 363 RI
- Date: Wed, 21 Jan 2015 17:31:01 +0100
Thanks, there is no strict minimum number of votes, but e.g. Apache PMC
votes for most of the standard decisions require a minimum of 3 votes to be
valid (so far we got 3;-)
I hope we get a bit more feedback or "quorum" inside the EG but regardless
on how many more respond if the end result doesn't say many -1 I'll add a
JIRA task for this, too.
Werner
On Wed, Jan 21, 2015 at 5:19 PM, Legrand, Karen
<
>
wrote:
>
+1
>
>
Better to remove this dependency from the RI itself.
>
>
>
>
*From:* Chris Senior
>
[mailto:
]
>
*Sent:* Wednesday, January 21, 2015 5:51 AM
>
*To:*
>
>
*Subject:* [jsr363-experts] Re: [VOTE] descope UCUM support from JSR 363
>
RI
>
>
>
>
+1 to defining SimpleUnitFormat and moving UCUM formatters out of RI and
>
into JSR implementations (maybe SE RI)
>
>
On Wed Jan 21 2015 at 11:43:04 AM Werner Keil
>
<
>
>
wrote:
>
>
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
>
>
>
>
>