Skip to main content

[jsr363-experts] Re: Pluggable (Modular) Unit Systems

  • From: Werner Keil < >
  • To: " " < >
  • Subject: [jsr363-experts] Re: Pluggable (Modular) Unit Systems
  • Date: Tue, 9 Jun 2015 15:04:33 +0200

P.s.: While it may seem a bit of an overhead to separate "uom.si" and
"uom.systems" with their own dedicated domains and repositories, the latter
helps control over the SI module.
As of now, only the EG team can push there. While the uom-systems repo is
open to Adopters, too.

Even with some of the domains being a little more expensive than say the
"tec" ones, which are just virtual reserved names, all of them together
seem cheaper than e.g. just a single ".io" domain so man projects are mad
for right now;-) Looking at JSRs like 330, its MR Crazy Bob had the former
domain "atinject.org" long expire, while RI and TCK will use it forever. So
eventually we may do this if it was an issue some day. Guess the .org
domain simply feels outdated nowaways, and Jean-Marie could let it expire
just like Bob Lee did with 330.

Regards,
Werner




On Tue, Jun 9, 2015 at 12:37 PM, Werner Keil 
< >
 wrote:

> Dear Experts,
>
>
> While trying to reduce and align the number of quantities in the API with
> established definitions, those we used to carry in the "quantity" package
> need to go to another place(s)
>
> Please have a look at this JIRA task
> https://java.net/jira/browse/UNITSOFMEASUREMENT-121
>
> Since SI and other systems or catalogues like oBIX, UCUM, etc. need more
> quantities, at least where compile-time type-safety is required (especially
> UCUM or others may also retrieve units and quantities from files like
> ucum-essence.xml, there validation only happens at runtime) they shall be
> defined in additional "quantity" modules for either SI or other systems.
>
> Major challenges are
>
>    - Trying to get implementation independent (see
>    https://java.net/jira/browse/UNITSOFMEASUREMENT-98 the idea of having
>    an "SI" class in the API may not be a perfect solution any more, since
>    "Full SI" will require additional quantities, but trying to use the SPI
>    similar to say JSR 354 is a proper goal if the SI class and module should
>    be independent of the underlying implementation
>    - Formatting
>       -  For RI/Java ME there are some issues to solve especially few
>       Reflection pieces left related to SymbolMap and accurate 
> formatting/parsing
>       - For SE all formatting is so far based on Java ResourceBundles,
>       even if locale should not matter (e.g. for UCUM) The problem is,
>       traditional Resource Bundles backed by Properties files can only 
> handle a
>       single properties file each. As soon as you try say adding
>       "message.properties" with new definitions for a unit system like SI, 
> UCUM
>       or others, this overwrites the old formats. We also require some SPI 
> that
>       allows adding formats for a new unit system / source.
>
>
> Please have a look if you're able to help with some of that. Not
> everything is in scope of the actual JSR, that sort of makes it easier,
> because non EG members could help with modules like "si-units" or
> "uom-systems". We'll try to advertise this at upcoming Hackathons or
> -garten events between next week and JavaOne, too.
>
> Regards,
>
>
> Werner
>
>
>
>
>
>


[jsr363-experts] Pluggable (Modular) Unit Systems

Werner Keil 06/09/2015

[jsr363-experts] Re: Pluggable (Modular) Unit Systems

Werner Keil 06/09/2015
 
 
Close
loading
Please Confirm
Close