Skip to main content

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

  • From: Otávio Gonçalves de Santana < >
  • To:
  • Subject: [jsr363-experts] Re: [VOTE] descope UCUM support from JSR 363 RI
  • Date: Thu, 22 Jan 2015 20:47:30 -0200

+ 1

On Wed, Jan 21, 2015 at 2: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
>
>
>
>
>



-- 
Otávio Gonçalves de Santana

blog:     http://otaviosantana.blogspot.com.br/
twitter: http://twitter.com/otaviojava
site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
55 (11) 98255-3513


[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