Skip to main content

[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

Hi Stephen

 

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

the locale.

-> 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 
utilities").

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

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

 

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.

 

-- Anatole

 

On 14 July 2013 23:44, Anatole Tresch <atsticks@... <mailto:atsticks@...> > 
wrote:

> Dear all

> 

> yet another topic is the Regions API. I wold like to do another proposal to

> simplify/separate concerns:

> https://github.com/atsticks/javamoney/tree/master/money-api/ext/src/main/java/javax/money/ext
>  
> <https://github.com/atsticks/javamoney/tree/master/money-api/ext/src/main/java/javax/money/ext>
>  

> https://github.com/atsticks/javamoney/tree/master/money-api/ext/src/main/java/javax/money/ext/spi
>  
> <https://github.com/atsticks/javamoney/tree/master/money-api/ext/src/main/java/javax/money/ext/spi>
>  

> 

> 

> 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/ ;
> <http://javaremarkables.blogspot.ch/

> Google: atsticks

> Phone   +41-44 334 40 87

> Mobile  +41-76 344 62 79



[JSR-354] Region API/SPI

Anatole Tresch 07/14/2013

[JSR-354] Re: Region API/SPI

Stephen Colebourne 07/15/2013

[JSR-354] Re: Region API/SPI

Tresch Anatole (KFSC 225) 07/15/2013

[JSR-354] Re: Region API/SPI

Werner Keil 07/15/2013
 
 
Close
loading
Please Confirm
Close