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


[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