Skip to main content

[JSR-354] Re: Api Proposals

  • From: Werner Keil <werner.keil@...>
  • To: mail@...
  • Subject: [JSR-354] Re: Api Proposals
  • Date: Sun, 16 Jun 2013 14:43:05 +0200

Hi,

Looks good. 

Two minor things, for consistency that StyleID should probably be an Id, and unless you changed it back  in the fork, that singleton was renamed to MonetaryFormats, avoiding confusion with any value type

Speak soon those who join the Hangout,

Werner

On Sun, Jun 16, 2013 at 1:30 AM, Anatole Tresch <atsticks@...> wrote:
Hi all

I have tried to summarize the API proposals int my personal fork:

I propose you my have a look at there, so we can then discuss the different points.

Basically I did the following changes:
  • I removed validFrom/validUntil from the CurrencyUnit interface and according implementations.
  • I added a Validation interface and a ValidationResult class. The Validation implementations can be registered to a Validator, which then can perform customizable validation, e.g. on CurrencyUnit, Amounts or completeley other (financial) artefacts, or intermediate results.
  • I defined a abstract ValidityInfo, which is generic regarding its type (e.g. CurrencyUnit, MonetaryAmount ,...)  and its reference type (e.g. Region, Rounding, ...).
  • I defined an abstract CurrencyValidityInfo, which basically sets the template parameter type from above to CurrencyUnit.class.
  • I defined an abstract MonetaryAmountVatlidityInfo, which basically set s the template parameter type from above to MonetaryAmount.class.

Finally, several discussions with JUG Vienna and others, has shown me, that we have some kind of misconception/over engineering in the formatting area:
  • A LocalizationStyle should basically be a simple configuration structure - a style, with
    • a styleID
    • an arbitrary set of attributes.
  • Said this the methods for date, time, number, translation locales were not necessary (and so removed!). If someone, wants to model these things this is still possible, but out of the box most users are confused by the different locales.
  • Consequently the format, print and parse methods on the ItemFormat take now an additonal locale parameter that, as usual controls the formatting/parsing locale (translation). In most of the use cases this is sufficient and there is no need to create style instances for each different translation locale. Also the style now helps identifying and configuring the ItemFormat instance, when accessing from the MonetaryFormat singleton, but in action, the locale is passed, as also in existing formatting in the JDK.
  • Finally, since now the LocalizationStyle renders into a reusable value type, it is also easily cacheable, since different target translation locales are mapped by the locale instance passed.
  • Summarizing a ItemFormat is configured using a named style ( LocalizationStyle). When formatting or parsing basically only the the item and the target locale must be passed, similarly to the existing formatters in the JDK.
I thinks all this result in quite elegant and flexible APs, which also are able to cover use cases not included in the JSR. More details I can give you on the hangout tomorrow as needed.

Cheers and a good night
Anatole

--
Anatole Tresch
Java Lead Engineer, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon

Switzerland, Europe Zurich, GMT+1
Twitter:  @atsticks
Google: atsticks
Phone   +41-44 334 40 87
Mobile  +41-76 344 62 79



[JSR-354] Api Proposals

Anatole Tresch 06/15/2013

[JSR-354] Re: Api Proposals

Werner Keil 06/16/2013
 
 
Close
loading
Please Confirm
Close