Skip to main content

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

  • From: "Legrand, Karen" < >
  • To: " " < >
  • Subject: [jsr363-experts] Re: [VOTE] descope UCUM support from JSR 363 RI
  • Date: Wed, 21 Jan 2015 16:19:01 +0000
  • Accept-language: en-US

+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 
< <mailto: >>
 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