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 13:05:01 +0100
+1 I also vote early this time.
Especially given not all EG members also actively contributed to RI and we
have an obligation to produce a TCK rather than implement 5 or 10 different
concrete cases of an API element I'd say remove it and let the community do
this elsewhere. Should at least an optional (J9/Jigsaw) module come out of
uom-se that alongside CLDR support outside ICU4J would be a great topic for
future SE/EE work and at least via some "Module repository" (aka
MavenCentral, Mark Reinhold was quite frank most modules would also end up
there sooner or later;-D) be offered to anybody on top of OSGi or Java 9+
Werner
On Wed, Jan 21, 2015 at 12:51 PM, Chris Senior
<
>
wrote:
>
+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
>
>
>
>
>
>
>
>