Hi allI 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 nightAnatole--Anatole TreschJava Lead Engineer, JSR Spec Lead
CH - 8620 WetzikonSwitzerland, Europe Zurich, GMT+1Twitter: @atsticksGoogle: atsticks
Phone +41-44 334 40 87
Mobile +41-76 344 62 79
[JSR-354] Re: Api Proposals