Skip to main content

[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
>>
>>
>>
>>


[jsr363-experts] [VOTE] descope UCUM support from JSR 363 RI

Werner Keil 01/21/2015

[jsr363-experts] Re: [VOTE] descope UCUM support from JSR 363 RI

Chris Senior 01/21/2015

[jsr363-experts] Re: [VOTE] descope UCUM support from JSR 363 RI

Werner Keil 01/21/2015

[jsr363-experts] Re: [VOTE] descope UCUM support from JSR 363 RI

Legrand, Karen 01/21/2015

[jsr363-experts] Re: [VOTE] descope UCUM support from JSR 363 RI

Werner Keil 01/21/2015

[jsr363-experts] Re: [VOTE] descope UCUM support from JSR 363 RI

Martin Desruisseaux 01/21/2015

[jsr363-experts] Re: [VOTE] descope UCUM support from JSR 363 RI

Jean-Marie Dautelle 01/21/2015

[jsr363-experts] Re: [VOTE] descope UCUM support from JSR 363 RI

Leonardo Lima 01/21/2015

[jsr363-experts] Re: [VOTE] descope UCUM support from JSR 363 RI

Werner Keil 01/21/2015

[jsr363-experts] Re: [VOTE] descope UCUM support from JSR 363 RI

Personal Mail 01/22/2015

[jsr363-experts] Re: [VOTE] descope UCUM support from JSR 363 RI

Otávio Gonçalves de Santana 01/22/2015

[jsr363-experts] Re: [VOTE] descope UCUM support from JSR 363 RI

Werner Keil 01/26/2015
 
 
Close
loading
Please Confirm
Close