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: Mon, 26 Jan 2015 14:55:55 +0100
Dear Experts,
Thank you for your wide participation in this ballot. I believe everyone
but maybe 1 or 2 did vote in the end;-)
If you look into the RI code now, you'll notice UCUM support was already
removed and replaced by a SimpleUnitFormat, largely modeled after the one
in UOMo. Since the RI (and SE) LocaleUnitFormat was written for printing/UI
only and can't correctly parse compound units.
That was an issue JScience 5 seems to have introduced either by accident or
deliberately. The SimpleUnitFormat covers both. In theory also
locale-aware, thus we may leverage that into the SE port while a working
PoC for ME compliant l10 already exists under
https://github.com/unitsofmeasurement/unit-ri/tree/master/src/main/java/tec/units/ri/format/internal/l10
I tested that against ME 8 in a small testbed, it works, aside from a
security permission (in the Locale class, currently disabled and set to
"en" as default) we would have to adjust if we wanted to use the actual ME
"locale" property, too.
Instead of UCUM we should at least in the RI stick to the Unicode CLDR. Its
"root" (locale-neutral) unit selection can be found here:
https://github.com/unitsofmeasurement/unit-ri/blob/master/src/test/resources/root/units.json
I started to experiment with a JSON to Properties or Java class conversion.
While JDK offers some level of CLDR support in Java already I am not aware
the relatively new unit types are of any interest to the JDK i18n team yet,
thus we shall deal with this ourselves. ICU4J uses a very similar mechanism
to our Properties/Locale based approach, except the ResourceBundle is
optimized in a binary form rather than Properties files or classes. For the
ME l10 it looks like a class exposing a Map works best. We may require some
small "tool" (probably best under the RI project) to convert new versions
of the CLDR from JSON into the appropriate format. It doesn't look
reasonable to do this with every Maven build automatically (though it would
be nice if we got this some day in the future;-) but at least manually
replacing the code when a new CLDR version demands it seems good.
The only run-time safe "quantity type" in ICU4J is hidden in the JSON
structure, e.g.:
"angle-radian": { "displayName": "rad", "
unitPattern-count-other": "{0} rad" }
where "angle" is the quantity, "radian" (internally called "sub-type";-)
the unit key or constant and the "displayName" usually reflects the
getSymbol() value of Unit.
For QuantityFormat only the "unitPattern-count-other" and similar entries
could be useful, though most cases look like they're simply composed of
"{value} <unit>" there.
I'll add new tasks to uom-se regarding better UCUM support. I hope
especially those who worked on it in the past (Otavio;-) are not too busy
with other projects or JSRs now, otherwise we also have to think about
removing functionality there. We are not obliged to offer any of it in
either implementation. It could well become part of other implementations
either Open Source (UOMo so far has the most complete UCUM support using
the XML file directly) or even commercial closed source products.
Regards,
Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
Eclipse UOMo Lead, Babel Language Champion | Apache Committer | Advisory
Board Member, Java Track Chair, DWX '15
Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | #EclipseUOMo
| #DeviceMap
| #DevOps
Skype werner.keil | Google+ gplus.to/wernerkeil
On Thu, Jan 22, 2015 at 11:47 PM, Otávio Gonçalves de Santana <
>
wrote:
>
+ 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
>
>