[JAVAMONEY-59] Isolate Validity Services Created: 24/Aug/13  Updated: 05/Feb/15  Due: 26/Aug/13  Resolved: 27/Aug/13

Status: Closed
Project: javamoney
Component/s: API
Affects Version/s: 0.4-EDR1
Fix Version/s: 0.5

Type: Improvement Priority: Major
Reporter: atsticks Assignee: atsticks
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day


when writing on the spec this morning, I felt not satisfied, with our solutions how validities for currencies and regions were handled. Basically, with ValidityInfo and RelatedValidityInfo we already have a generalized solution for the return types. But the accessor methods were specific on the {MonetaryCurrencies}} and Regions singletons.

Therefore I propose(in ext) an additional Validities singleton, which provides validities as required. But I still was not satisfied, since there were a lots of access methods that did more or less the same, just varying the input parameters a bit. Additionally we also support querying of legal tender related validities, which are different than the normal currencies per region relation. So I was looking for a more flexible solution and came to ValidityQuery, RelatedValidityQuery and ValidityType.

The distinction what kind of ValidityInfo is required, I solved by adding a ValidityType value type. By default this is set to ValidityType.EXISTENCE, when a new ValidityQuery is created, but for legal tenders or other use cases may have different values, e.g. ValidityType.of("legalTender".

Basically I see not many disadvantages, but many Advantages:

  • Validities are not constrained to currencies and regions anymore, also other types can be supported, by simply registering corresponding ValidityProviderSpi instances.
  • Queries can be extended, when useful (must be supported by the provider answering the query of course), so also very complex customer specific use cases can be modelled.
  • The client API is simple (4 methods only in tota).
  • Even bitermporal historization would be possible, by adding an additional parameter.

Generated at Mon Nov 30 12:56:42 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.