Skip to main content

[JSR-354] Re: CurrencyData (was Separation of Validity)

  • From: <magesh.kasthuri@...>
  • To: <jcurrency_mail@...>
  • Cc: <mark@...>
  • Subject: [JSR-354] Re: CurrencyData (was Separation of Validity)
  • Date: Mon, 10 Jun 2013 04:27:07 +0000
  • Accept-language: en-US

All

 

Validatable as a factory representation having isValid(), setIsValid() and validate(), getFieldToValidate() is better and has been practiced in other common frameworks in java like

http://docs.oracle.com/cd/E13222_01/wls/docs81/javadocs/weblogicx/jsp/tags/validators/Validatable.html

http://documentation.softwareag.com/webmethods/centrasite/soal8/jd/csaf/validation/com/softwareag/centrasite/appl/framework/validation/impl/ValidatableFactory.html

https://github.com/vaadin/vaadin/blob/master/server/src/com/vaadin/data/Validatable.java

 

We can also have method like canValidate(), setValidationMessage() if agreed in common.

 

Regards,

Magesh

Technical Consultant | Wipro Technologies | Bangalore

 

From: Werner Keil [mailto:werner.keil@...]
Sent: 09 June 2013 22:30
To: jcurrency_mail@...
Cc: Mark Davis
Subject: [JSR-354] CurrencyData (was Separation of Validity)

 

All,

 

Thanks to some of the Adopt-OpenJDK guys and their efforts there are Git clones of the recent Java 8 codebase, see CurrencyData.properties:

as well as an earlier Java 7 version:

https://github.com/openjdk-mirror/jdk7u-jdk/blob/master/src/share/classes/java/util/CurrencyData.properties

If you compare the two, you'll notice, Java 7 had some "historic" validity information like 

 
# VENEZUELA
 
VE=VEB;2008-01-01-04-00-00;VEF
 

for Venezuela and a few others, while Java 8 seems to contain no such thing.

 

We should hook up with the i18n team to find out, why this was removed between version 151 and 154 of the data set, and whether the reason is, Oracle/OpenJDK does not consider that relevant enough any more?

 

Above examples show, it was maintained using standard means of the JDK, even though in most cases you would not have direct access to it.

Most likely, if the system date was before 2008 for Venezuela, you'd simply get the old currency, which by now JDK considers irrelevant. 

 

Bugs like this 

show there are still changes and at least the Java 8 version of CurrencyData.properties seems to not take it into consideration.

 

There is of course at least one more:

 

It contains plain text "metainformation", but no relevance as a date or year.

 

An internal helper class for CLDR can also be found there:


However, it seems, JDK classes related to currency so far don't use CLDR directly. 

Given the cutover date can be used by java.util.Currency, via a currency.properties, it just isn't exposed, it seems best to remain compatible with that where we can. With the difference of exposing such cutover date via the API. 

 

If separating this into 3 interfaces or classes (CurrencyUnit, Displayable and either Validatable or something else) does not confuse people, it seems fine, given at least CurrencyUnit and Displayable are usually bound together in a concrete class like java.util.Currency or similar implementing classes.

 

What isn't part of java.util.Currency right now, we should find an approach that is similar to what Mark proposed, but compatible with that Java i18n got so far.

 

Werner  

On Sun, Jun 9, 2013 at 5:37 PM, Werner Keil <werner.keil@...> wrote:

Mark,

 

Thanks for the concrete code proposal.

The boolean getter for tender probably should be isTender() or similar. 

 

While it may be a little late for Java 8, it looks like the i18n team at OpenJDK thinks about tweaking currency data, especially that one may apply for ad-hoc changes to currency information:

or

 

 

However, we should communicate with Naoko and others in the i18n team ASAP.

While it may not make sense for Java 8 to add some of the information discussed, it is in everyone's interest to add such information to later versions or even Updates of Java 8 (things like JavaFX were added to Java 7 in a MR rather than waiting all the way for SE 8, technically some of that could be added to 8 at a later point if there is an equally good reason for it) in a compatible way that doesn't break what they're just adding right now.

 

 

About immutable classes or interfaces, this note at EclipseLink, the JPA RI also sounds quite interesting, while we may explore, whether CurrencyUnit could also be used in such an adapter or MonetaryAmount to marshal the entire monetary value

 

Regards,

Werner

 

On Sun, Jun 9, 2013 at 5:12 PM, Mark Davis ☕ <mark@...> wrote:

I agree with separating out the validity checks from the currencies. As to the precise form that takes, I suggest a class (name TBD), with a factory method that returns a concrete class that has the CLDR data for currencies. The two main requirements are: 

  1. for a region (country code), find the currencies and periods in which they were valid;
  2. for a currency, find the countries in which it was valid (and for which periods).

So you could do something like:

 

CurrencyValidityData myCurrencyInfo = CurrencyValidityData.getInstance("cldr");

 

for (CurrencyValidity info : myCurrencyInfo.getInfo(CurrencyUnit.getInstance("USD")) {

// would cycle through the regions in use, eg for USD: Haiti (HT), Panama (PA), U.S. Virgin Islands (VI), Caribbean Netherlands (BQ), Zimbabwe (ZW), Ecuador (EC), Northern Mariana Islands (MP), Diego Garcia (DG), El Salvador (SV), U.S. Outlying Islands (UM), Guam (GU), Palau (PW), Puerto Rico (PR), American Samoa (AS), British Indian Ocean Territory (IO), Micronesia (FM), United States (US), British Virgin Islands (VG), Turks and Caicos Islands (TC), Timor-Leste (TL), Marshall Islands (MH), Cuba (CU), Dominican Republic (DO)

 

  CurrencyUnit unit = info.getCurrencyUnit(); // constant USD in this case

  String region = info.getRegion(); // eg US or TC

  long from = info.getFrom(); // eg 1792-01-01 00:00 or 1969-09-08 00:00; MIN_LONG if no known start date

  long to = info.getTo(); // eg MAX_LONG  if no known end date

  boolean tender = info.getTender(); // eg true

}

 

or

 

for (CurrencyValidity info : myCurrencyInfo.getInfo("RS") {

  // would cycle through the CurrencyUnits for Serbia: eg RSD, CSD, YUM

...

}

 

The info could also have:

  int decimals = info.getDecimalDigits(); // eg 2

  int rounding = info.getRounding(); // eg 0

  int cashRounding = info.getCashRounding(); // eg 5

 

The stock info could have a getInstance for "cldr". We could have methods so that others could be registered, and you could find the available ones.


 

 

— Il meglio è l’inimico del bene —

 

On Sat, Jun 8, 2013 at 8:39 AM, Anatole Tresch <atsticks@...> wrote:

Deaar all

 

I was thinking about, how we can separate Validity from the instances, e.g. CurrencyUnit (one of the key feedback points out of the EDR). As attachment find my proposal how we can achieve that:

 

  • The Validity value type defines a validity for any item where it can be used: CurrencyUnit, but also ExchangeRate.
  • I defined another interface Validateable which can be implemented by classes that support validity ranges. I suggest hereby that
    • CurrencyUnit will NOT extend this interface. Basically this leads to a very lean CurrencyUnit, which basically only extends the current Currency class by namespaces, the general legal tender and virtual flags (see also attached interface). As a side effect the implementation of equals/hashCode also gets simple.
    • ExchangeRate would implement this interface.
    • Additionally for the MonetaryCurrencies singleton, within the ext package a ValidatedCurrencyUnit class can be implemented that extends CurrencyUnit with Validateable.
    • Similarly a ValideatableAmount class can be added that combines validity with a MonetaryAmount.

I know that not all details were worked out, but I think, it is worth starting the discussion given the two interfaces attached and the comments above. So the discussion is open!

 

Cheers,

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

 



 

--

Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead, Babel Language Champion | Java Godfather

Twitter @wernerkeil | @JSR354 | #EclipseUOMo | #Java_Social | #OpenDDR

Skype werner.keil | Google+ gplus.to/wernerkeil

 

* Eclipse DemoCamps Kepler 2013: June 19-28 2013, Germany, Denmark, Austria. Werner Keil, UOMo Lead, Mærsk DevOps Build Manager will present "Triple-E’class DevOps with Hudson, Maven, Kokki, Multiconf & PyDev", "M4M 2 the Rescue of M2M"

 

Please do not print this email unless it is absolutely necessary.

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

www.wipro.com



[JSR-354] CurrencyData (was Separation of Validity)

Werner Keil 06/09/2013

[JSR-354] Re: CurrencyData (was Separation of Validity)

magesh.kasthuri 06/10/2013
 
 
Close
loading
Please Confirm
Close