Skip to main content

[JSR-354] Re: Region API/SPI

  • From: Werner Keil <werner.keil@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Re: Region API/SPI
  • Date: Mon, 15 Jul 2013 13:30:51 +0200

Anatole/Stephen/all,

Thanks for discussing this. Pity some of you (except Anatole or myself)
didn't make it to join the Hangout yesterday evening, but of course some
may have family responsibilities, especially on a weekend that are more
important (just heard of an Oracle employee who just said in a JCP.next
call he'd have to prefer Disneyland over OSCON '13[?])

Replies also inline

On Mon, Jul 15, 2013 at 10:10 AM, Tresch Anatole (KFSC 225) <
anatole.tresch@...> wrote:

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

Didn't know, Mark was at Apple back then, but indeed he was a co-founder of
Unicode together with a former Xerox employee
http://en.wikipedia.org/wiki/Unicode#History

Beside a very dedicated level of membership history (even "In Memoriam",
guess JCP isn't so nostalgic about its members?[?]) one can see, the State
and several Civic bodies of India are full members, and even the Church of
Mormon, see http://www.unicode.org/consortium/memblogo.html
(note to myself, I was almost about to raise the question of churches being
non-profit or not, hope Mark could answer, if a church generally qualifies
as Non-Profit at Unicode or if they look at its financial position, some
churches, especially in the US aren't doing so badly[?])

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

It may exceed the scope of "Money" in some cases, but looking at Unicode
and ICU4J (by someone who uses it a lot and even found occasional limits
developing UOMo on top) there are plenty more things to ICU than just
formatting or spelling. Although marked as "internal only" there is a whole
lot of "CurrencyMetaInfo" and similar elements aiming at similar
challenges.

**
>
> 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.****
>
> **
>
Region and an inner enum RegionType are defined by ICU4J, and I hope,
veteran ICU and Unicode experts like Mark could help with this. Ideally
something of value to applications, otherwise the ICU framework would not
define things just for its own entertainment either.

Mark himself is called author of a GenderInfo class. Another "internal"
element, but even such often differently handled information is tackled by
ICU4J (nobody should e.g. store the ordinal() value of the
GenderInfo.Gender enum, but that's similar for almost every enum including
the ones used by this JSR, 310 or others[?])

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

While the small monetary package JScience contained has a more scientific
or academic sounding name "economics", I chose to call the UOMo
bundle/module "UOMo Business", too. Google using the same ICU4J as UOMo
does has a portal "Google Finance", so do others like Yahoo. Part of what
they provide are sources to the JavaMoney Conversion module.

ICU4J offers a whole variety of "Business" tools in disguise of a "Unicode
API", including Currency and time on top of a general Measure value holder.
You'll notice a familiar author of TimeUnitAmount
http://icu-project.org/apiref/icu4j/com/ibm/icu/util/TimeUnitAmount.html very
similar to types spread across Java 8 in JafaFX, JSR 310 and (in a lower
level form) java.util.concurrent. Mark's JavaDoc suggests, it was modeled
after Currency which existed earlier in ICU4J.[?]

Formatters while based on "bad old" java.text.Format look extremely
powerful, though Money and Currency formatting is hidden in ICU's improved
NumberFormat
http://icu-project.org/apiref/icu4j/com/ibm/icu/text/NumberFormat.html


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

Another good example for ICU4J being more extensible than all Java(JDK)
Date/Time APIs so far is its Holiday API.  You'd probably call it
"Business" related, too, which is why java.time replicates the
functionality of java.util.Date/Calendar but adds none of that.
Nevertheless a vast majority of applications, not just by banks or
businesses needs to know, whether something happens on a work day or
holiday, ports and shipping being just one example, look at every public
transport schedule around the world,... well, they have ICU4J for that[?]



> **
>
> 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.****
>
> **
>
Here ICU4J finds Region sufficient, even for nodes or branches of its
"tree". Maybe worth having a look at it, after all we'd talk about the same
CLDR data it models, so unless you try to "enrich" that with additional
information, there should not be too many things you'd need, that ICU
does't already get out of this data structure.

Werner


> **
>
> -- Anatole****
>
> ** **
>
> On 14 July 2013 23:44, Anatole Tresch <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/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/****
>
> > Google: atsticks****
>
> > Phone   +41-44 334 40 87****
>
> > Mobile  +41-76 344 62 79****
>

Attachment: 329.gif
Description: GIF image

Attachment: 347.gif
Description: GIF image



[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