[JSR-354] Re: Region API/SPI
- From: "Tresch Anatole (KFSC 225)" <anatole.tresch@...>
- To: <jcurrency_mail@...>
- Subject: [JSR-354] Re: Region API/SPI
- Date: Mon, 15 Jul 2013 10:10:13 +0200
Thanks very much for your input, I try to give my answers inline...
Providing a Region API is quite a major job. It would need to be done
in association with changing Locale, as Locale is the primary class
for accessing a region today. In addition, the design of Locale would
encourage a separate Language object to represent the language part of
-> I am in strong contact for example with Mark Davis (Unicode founder), so I
am not completely off here.
-> The support of Locale for countries is completely insufficient and since
year one of the weaknesses of the platform.
Since regarding currencies we have a string relation to region, we must
add something here, if not IMO we fail to map what is
required for managing currencies effectively.
In addition, creating region hierarchies will have a tendency to be
quite business specific. Different organizations will get that data
and structure it in different ways. Credit Suisse's view and Expedia's
view are probably different.
-> I would like to mention that this API basically was already part of the
EDR and also in the discussions there was quite interest for it!
-> I would predefine the basic tree by specification. As a starting point, we
could add the CLDC Unicode structures by default, which also include the
stabilized country mapping based on
ISO and UN country codes (for example as provided by icu4j). They are
well managed, have a usable and updatable data format and with the colleagues
from Google we also have the
required know how to support this.
-> Basically my idea IS that users are able to define their custom region
trees easily, I see a plenty of use cases. Here and yes, this will be
different depending on the enterprise context as
well as also the use cases. I don't see anything wrong here.
-> The point that we should support accessing a Region also by a Locale, to
bridge with the existing JDK functionality, I find also a very good point.
This, and amount type, feel more like trying to create a general
"business utilities" library, rather than a money API.
-> The monetary API from the beginning was separated into different areas. We
from the start had many discussion on the targeted scope here. One might also
argue that we only require, what as of now is part of the core package
(currency conversion and formatting can also be seen as "business
-> The region functionality is part of the extensions, so I agree, it is not
at a total core part. But nevertheless our objective was also to support
mapping of things like legal acceptance, currency validity per country (and
region), and also discussions with JUGs and users here have shown, that this
is also seen as an important aspects, we should try to cover. Also for me, in
general, it is important to think on how a functionality introduced may be
useful for the people that are building on it, especially the ones providing
more advanced financial libraries (I have written quite a bunch of them).
Talking of that, I think, three aspects are crucial: 1) model aspect with
simple and comprehensive concepts. 2) ensure the model is extensible and
adaptable., 3) provide the most common aspects as a starting point out of the
-> I also agree, that we will not add the amount type to the core, but as
wrapper class in the extension package, it may be useful.
-> Finally I either do not want to add lots of additional functionalities to
the JSR, it is a normal process that additional topics arise and may also
want to be included. IMO this must be prevented, or minimized, because
without the JSR will not focus enough. And this is still the case: beside the
small amount type extension since EDR there is no additional functionality
defined. The only thing is that I try to get the things there to a point
where simplicity, extendibility and minimal provided functionality are
On the specific design, why "GER"? Locale defines "DE".
-> GER is the three digit ISO country code.
Why Regions.get() when Java is moving to Regions.of()?
Why RegionNode and not Region?
-> The region is modeled by Region. And is a simple type, like a currency.
-> The RegionNode contains/represents a Region, but adds tree functionality
to it. Also it would be an option to let RegionNode extend Region, but find
it better to avoid inheritance here to separate the concepts.
On 14 July 2013 23:44, Anatole Tresch <atsticks@... <mailto:atsticks@
> Dear all
> yet another topic is the Regions API. I wold like to do another proposal to
> simplify/separate concerns:
> Hereby the keypoints are:
> A Region is just an interface with
> - a RegionType (as before)
> - a textual code (required)
> - an (optional) numeric ID
> And yes, this is very similar to what we have in the area of currrencies.
> Similar to currencies (but without the regional relation) I can access
> RegionValidty instances.
> Additionally I can access the (possibly) different RegionNode as region
> forest, or access a RegionNode by its top level region identifiers (type,
> code). The RegionNode similar to the previously modeled Region, has a
> parent and children and allows for tree navigation.
> This makes the API quite simply, e.g.
> Region ger = Regions.get(RegionType.COUNTRY, "GER"); // Germany
> RegionNode reg = Regions.getRegionNode(ger);
> Collection<RegionNode> children = reg.getChildren();
> RegionNode reg2 = Regions.get(RegionType.COUNTRY, "GER"); // Germany
> RegionNode reg3 = Regions.get("WOLRD/EUROPE/COUNTRIES/ISO/GER");
> // Germany by path
> On the spi side this has some advantages:
> Spi implementation for region definition, region validity and region tree
> structure can be easily separated.
> Access to regfions/region nodes is still simple.
> Region tree is highly adaptable and easy to extend.
> So have a look at this and write down your feedback.
> Have a good night (or morning...).
> - Anatole
> Anatole Tresch
> Java Lead Engineer, JSR Spec Lead
> Glärnischweg 10
> CH - 8620 Wetzikon
> Switzerland, Europe Zurich, GMT+1
> Twitter: @atsticks
> Blogs: http://javaremarkables.blogspot.ch/
> Google: atsticks
> Phone +41-44 334 40 87
> Mobile +41-76 344 62 79