<< Back to previous view

[JAVAMONEY-59] Isolate Validity Services Created: 24/Aug/13  Updated: 10/Nov/13  Due: 26/Aug/13  Resolved: 27/Aug/13

Status: Resolved
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
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day

Tags:
Participants: atsticks

 Description   

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.





[JAVAMONEY-54] Define the ItemFormat instances and styles to be required by an implementation Created: 08/Aug/13  Updated: 10/Nov/13  Resolved: 30/Aug/13

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

Type: Task Priority: Major
Reporter: atsticks Assignee: atsticks
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: atsticks

 Description   
  • Define exactly what ItemFormat implementation must be provided by the (reference) implementation.
  • Along with that for each ItemFormat the according supported LocalizationStyle attributes must be defined.
  • Define which FormatToken implementations must be provided by the (reference) implementtion.
  • Similarly define the supported LocalizationStyle attributes.

Since when working with FormatToken}}s there are ultiple tokens in place, we need to define an "addressing" scheme, so attributes in a {{LocalizationStyle passed can be either

  • match to several tokens (unspecified)
  • match exact to one target token (explicit)

The mechanism/naming scheme should be made explicit and be discussed and also added to the specification/TCK.






[JAVAMONEY-53] Update/prepare Spec for Public Draft Review Created: 08/Aug/13  Updated: 15/Sep/13  Resolved: 15/Sep/13

Status: Resolved
Project: javamoney
Component/s: Spec: Specification
Affects Version/s: 0.4-EDR1
Fix Version/s: 0.5

Type: Task Priority: Major
Reporter: atsticks Assignee: atsticks
Resolution: Fixed Votes: 0
Remaining Estimate: 4 days
Time Spent: Not Specified
Original Estimate: 4 days

Tags:
Participants: atsticks

 Description   

Update the JSR specification for the Public Draft Review. Especially

  • adapt/include all changes done since EDR
  • Read through for improving English (must be done by a native English speaking colluege)
  • Add comments for points that must be checked by the TCK.

The PDR specification is located at:
https://docs.google.com/document/d/1FfihURoCYrbkDcSf1WXM6fHoU3d3tKooMnZLCpmpyV8/edit#heading=h.1e43k8j0bpig






Define updating mechanism (JAVAMONEY-47)

[JAVAMONEY-52] Update the CurrencyProviders to use the updater Created: 08/Aug/13  Updated: 15/Sep/13  Resolved: 15/Sep/13

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 0.1.0, 0.2.0, 0.3, 0.4-EDR1
Fix Version/s: 0.5

Type: Sub-task Priority: Major
Reporter: atsticks Assignee: Unassigned
Resolution: Fixed Votes: 0
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours

Tags:
Participants: atsticks

 Description   

Update the CurrencyUnit providers (ISO, CLDC for cash rounding) to use the updater for accessing data.






Define updating mechanism (JAVAMONEY-47)

[JAVAMONEY-51] Update the CLDC region providers to use the updater Created: 08/Aug/13  Updated: 15/Sep/13  Resolved: 15/Sep/13

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 0.1.0, 0.2.0, 0.3, 0.4-EDR1
Fix Version/s: 0.5

Type: Sub-task Priority: Major
Reporter: atsticks Assignee: Unassigned
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: atsticks

 Description   

Update the CLDR loaders/region providers to use the updater for locating/registering their resources.






Define updating mechanism (JAVAMONEY-47)

[JAVAMONEY-50] Update the IWF and EZB Exchange rate provider to use to the updater Created: 08/Aug/13  Updated: 10/Nov/13  Resolved: 15/Sep/13

Status: Resolved
Project: javamoney
Component/s: API, Impl: RI, Spec: Specification
Affects Version/s: 0.1.0, 0.2.0, 0.3, 0.4-EDR1
Fix Version/s: 0.5

Type: Sub-task Priority: Major
Reporter: atsticks Assignee: Unassigned
Resolution: Fixed Votes: 0
Remaining Estimate: 8 hours
Time Spent: Not Specified
Original Estimate: 8 hours

Tags:
Participants: atsticks

 Description   

The IWF/EZB currency conversion providers both just directly read data from the internet on component creation. Instead of, both should use the common data updater/provider, which also is capable of transparently updating the data. Additionally initial versions of data files, should be added to the classpath as defined by the updater mechanism.






[JAVAMONEY-47] Define updating mechanism Created: 08/Aug/13  Updated: 10/Nov/13  Resolved: 15/Sep/13

Status: Resolved
Project: javamoney
Component/s: API, Impl: RI, Spec: Specification
Affects Version/s: 0.1.0, 0.2.0, 0.3, 0.4-EDR1
Fix Version/s: 0.5

Type: Task Priority: Major
Reporter: atsticks Assignee: Unassigned
Resolution: Fixed Votes: 0
Σ Remaining Estimate: 3 days, 22 hours Remaining Estimate: 12 hours
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: 3 days, 22 hours Original Estimate: 12 hours

Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVAMONEY-50 Update the IWF and EZB Exchange rate ... Sub-task Resolved  
JAVAMONEY-51 Update the CLDC region providers to u... Sub-task Resolved  
JAVAMONEY-52 Update the CurrencyProviders to use t... Sub-task Resolved  
JAVAMONEY-60 Define and test an updater mechanism Sub-task Closed atsticks  
Tags:
Participants: atsticks

 Description   

Define and implement an updating mechanism/policies to keep changing resources up to date, e.g. countries, régions or currency data. Hereby I see the following policies:

  • LOCAL: read resources from the classpath, no automatic update (default).
  • CACHED: read resource from the CP, too, but automatically reload/update the resources using the configured connections.
    • The cache location may also be configured:
      • VM try to write the files into a locatoin within the JDK/JRE.
      • USER write the data to the user directory.
      • TEMP write the files as temporary files only and delete them on VM exit.
      • CUSTOM write the files to a custom location.

For the second part, the locations, where the different resources can be looked up and read, can be configured. This allows clients which want to control the update mechanism (e.g. due to security reasons) to configure a local company update site, instead of directly loading the resources, e.g. from ISO, Unicode.

The machanism implemented hereby should support the following features:

  • Each resource is defined by a resourceID and a resource location. Resources are accessed by its id.
  • It should be extendible (it can cache arbitrary resources), so it can also be used by spi implementations of this JSR.
  • The resources cached should be accessible by an API of the updater, clients should not directly access the file system.
  • Updating can be triggered programmatically.
  • There is a JMX bean that can be loaded, to trigger the update mechanism.
  • Finally it should be possible to configure some automatic updating, e.g. by using a Timer.





[JAVAMONEY-46] Add support for accountants notation Created: 08/Aug/13  Updated: 10/Nov/13  Resolved: 30/Aug/13

Status: Resolved
Project: javamoney
Component/s: API, Spec: Specification
Affects Version/s: 0.4-EDR1
Fix Version/s: 0.5

Type: Task Priority: Major
Reporter: atsticks Assignee: Unassigned
Resolution: Fixed Votes: 0
Remaining Estimate: 4 hours
Time Spent: Not Specified
Original Estimate: 4 hours

Tags:
Participants: atsticks

 Description   

EDR Feedback: When we look at formatting, do we need to cover the concept of accountants notation, i.e. '(100)' not '-100'.

-> This formatting type should be enabled.
-> This qould already be possible with the curent ItemFormatBuilder, but I am not sure, if the according numeric formatter already is present.
-> Add a monetary amount ItemFormat implementation, that is supporting this feature.
-> Document the format as required format for an implementation.






[JAVAMONEY-45] Design/add support for ISO 20022 Created: 08/Aug/13  Updated: 10/Nov/13  Resolved: 30/Aug/13

Status: Resolved
Project: javamoney
Component/s: API, Spec: Specification
Affects Version/s: 0.4-EDR1
Fix Version/s: 0.5

Type: Task Priority: Major
Reporter: atsticks Assignee: Unassigned
Resolution: Fixed Votes: 0
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours

Tags:
Participants: atsticks

 Description   

There is no technical specification related to ISO 20022. Since business cases involves in money transfers, developer community would expect data structure related to messaging attributes like Swift.
This topic should help to decide how we can best support this standard.

atsticks: I assume we should add an according ItemFormat implementation and document it as requird part of an implementation.

Definition: Amount of money of the cash balance.
Data Type: ActiveOrHistoricCurrencyAndAmount
This data type must be used with the following XML Attribute: Currency (Ccy) which is typed by

ActiveOrHistoricCurrencyCode.
Format: ActiveOrHistoricCurrencyAndAmount
fractionDigits: 5
minInclusive: 0
totalDigits: 18

ActiveOrHistoricCurrencyCode
[A-Z]{3,3}
Rule(s): ActiveOrHistoricCurrencyAndAmount

CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
Note: The decimal separator is a dot.



 Comments   
Comment by atsticks [ 30/Aug/13 07:28 AM ]
  • I added an according ItemFormat requirement, so we are able to Format/parse according amounts from to String.
  • I think it does not make sense to have a dedicated numeric MonetaryAmount implementation, since ISO 20022 is more an interchange Format, than a caclulation Format for internal use.




[JAVAMONEY-44] Enhance Spec (EDR feedback) Created: 08/Aug/13  Updated: 30/Aug/13  Resolved: 30/Aug/13

Status: Resolved
Project: javamoney
Component/s: Spec: Specification
Affects Version/s: 0.4-EDR1
Fix Version/s: 0.5

Type: Bug Priority: Major
Reporter: atsticks Assignee: atsticks
Resolution: Fixed Votes: 0
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours

Tags:
Participants: atsticks

 Description   
  • What about implementation details for Equals, hashCode and comparable for MonetaryAmount
  • As a developer, I would expect a displayvalue attribute in MonetaryAmount (a currency with 2 digits of fraction precision rounded to be displayed to user in order to avoid confusion in displaying > 2 digits of decimal numbers) -> Explain that it is part of the formatting, toString may implement a simple altenative.
  • Is there any default setting/constructor for classes like CurrencyUnit based on default locale (to be loaded with LC_ALL attribute in server) -> Explain how the default setting is working, define it, if necessary
  • What about ISO or display name representation for Decimal units (eg: displaying RAPPEN, PAISA etc.,) -> Part of Formatting
  • I believe that getLegalCurrencyUnits(Region region) in MonetaryRegions class gives multi-currency details (eg: swiss supports CHF and EUR both) -> Perhaps add this use case as an example





[JAVAMONEY-43] Improve Description of Rounding/Truncation Created: 08/Aug/13  Updated: 30/Aug/13  Resolved: 30/Aug/13

Status: Resolved
Project: javamoney
Component/s: Spec: Specification
Affects Version/s: 0.4-EDR1
Fix Version/s: 0.5

Type: Bug Priority: Major
Reporter: atsticks Assignee: Unassigned
Resolution: Fixed Votes: 0
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Tags:
Participants: atsticks

 Description   

Page 29 doesn't explain in detail on Rounding and truncating the fraction. If we want to round to a certain fraction only (eg: currency usually rounds to 2 digits after decimal). Also, rounding or truncating based on decimal precision (round if > 0.5 and truncate if < 0.5) is not explained/considered. I have seen bank transfers in some banks handling with truncation if needed (could be depending on country)






[JAVAMONEY-42] Add Percent Operation Created: 09/May/13  Updated: 10/Nov/13  Resolved: 30/Aug/13

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 0.4-EDR1
Fix Version/s: 0.5

Type: Improvement Priority: Minor
Reporter: keilw Assignee: keilw
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: core arithmetic
Participants: keilw

 Description   

Based on Chris' suggestion
1) Do we need to model the concept of a percentage? I think this would make a lot of money operations more readable (especially GST / VAT), and it's a candidate for being an immutable type itself.

and existing approaches to that in Eclipse UOMo Business let's try to create a reusable Percent operation ideally based on the MonetaryOperation/MonetaryFunction paradigm the JSR already has.






[JAVAMONEY-18] Managed Precision Created: 01/Feb/13  Updated: 30/Aug/13  Resolved: 30/Aug/13

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

Type: New Feature Priority: Critical
Reporter: atsticks Assignee: atsticks
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: atsticks and chrispheby

 Description   

Several aspects of arithmetic precision were identified:

  • internal precision defines the precision used for performing arithmetical operations. By default a MonetaryAmount will always represented/rounded to this internal precision internally. This allows to separate concrete rounding requirements from the types numeric representation.
  • When MonetaryAmount with different precision are used for a caclulation:
    • then the higher of both precisions is used for the result. This is also the case if the system's internal precision is less.
    • If the higher of both precisions is less than the internal precision, the result has the internal precision.
  • external precision is the precision applied, when a MonetaryAmount is externalized, e.g. by calling one of the int toInteger(), double toDoubple(), float toFloat() etc. methods, or by calling <T> T asType(Class<T>). Hereby the precision basically should be the same as the internal precision, but the representation of the externalized value may require to reduce the precision. In case of the toInteger() method this is quite obvious.
  • formatting precision this is the precision (or rounding) applied, when a monetary amount should be formatted for print out or display.

All these must be clearly separated, especially external and formatting precision are not part of the monetary amount's value type. Nevertheless the internal precision also must be serialized somehow, since different VMs may operate with different internal precisions. Therefore it is important that the precisoin information is also available on the target VM, so different precisions can be managed.

So the following points must be considered:

  • internal precition must be defined (by default)
  • internal precision must be accessible
    • the default precision
    • the effective precision on an instance
  • precision must be adaptable based on the use case
  • precision must be serialized
  • mechanisms must be defined and implemented that ensure correct precision handling.


 Comments   
Comment by chrispheby [ 05/Feb/13 03:11 PM ]

Two important use cases for precision are performing calculations (especially division) and pricing, i.e. ticks. There's a list of some common ones here: http://en.wikipedia.org/wiki/Commodity_tick.

Exchange rates are a specialised case of pricing, and we might also need to consider whether that has any impact on the user view of an exchange rate (thats for another issue I guess).





[JAVAMONEY-14] Support different time dimensions Created: 01/Feb/13  Updated: 09/Mar/14  Resolved: 09/Mar/14

Status: Resolved
Project: javamoney
Component/s: API, Spec: Specification
Affects Version/s: None
Fix Version/s: 0.5

Type: New Feature Priority: Major
Reporter: atsticks Assignee: atsticks
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: date time timestamp time_handling
Participants: atsticks, chrispheby and keilw

 Description   

This JSR must handle different date and time aspects, such as timestamps, time durations or time periods. It was agreed that JSR 310 basically would be the way to go. Nevertheless, it would be useful to have a solution that is more compatible with JDK releases prior to SE 8. It was decided to
use solve this as follows:

  • usage of java.lang.Long for modelling UTC timestamps, where as the value denotes the ms starting from 1.1.1970 00:00.
  • when a value is not define null may be returned.


 Comments   
Comment by chrispheby [ 05/Feb/13 03:20 PM ]

I still think that timestamp since 1970 is not appropriate. Actually we don't need full millisecond precision so if we must use long, something like day from a reference point as a long would be better... can't go back too far it gets complicated.

I don't see a problem with depending on JSR 310. Just as Stephen is doing, we can provide a backport which depends on JSR310 backport if necessary

Comment by keilw [ 05/Feb/13 06:33 PM ]

Based on recent statements by Oracle about Java (SE) 8 and its Profiles, beside nobody from Oracle having officially confirmed 310's inclusion into Java 8 e.g. at JFokus just now (the profiles were explicitely confirmed there) the API, even the Convert module should refrain from direct references to elements of 310. The backport isn't acceptable for a JSR at all, as elements of java.* or javax.* must not use outside APIs like org.apache., org.eclipse. or any other external library such as org.threeten (the current package for this backport)

Unless some generic value or the smallest denominator (like java.util.Date, likely to be in almost EVERY SE 8 Profile, while java.time probably will only be optional or part of the Biggest SE 8 Profile) can be found, either long or int beside the equivalent wrapper types are the most sensitive option now.

Some implementations (also considering how Profiles work in SE 8 and if Java 8 should be the minimal version?) could internally use 310 to calculate something, but the "Spec" part of the API shall store it as long. Whether that's a timestamp like Sytem.currentTimeMillis() or some other interval, that's up to JavaDoc in this case to spefify or suggest. It may actually be up to an implementation in some cases, how to treat such timestamp. If an timespan is required, 2 longs can be used.

Probably lesser known, but since Java 5, there is a System.nanoTime() method, used e.g. by Concurrency, UI elements like Swing and a few other places, especially Random.
Imagine some traders rely on real time, this method may actually be used, while other cases could find miliseconds sufficient. So not sure, if the "timestamp" should be too restricted. An implementation of an interface with one or more timestamps could handle the difference in nanos, while others may use milis, both are long.

Comment by keilw [ 09/Mar/14 04:44 PM ]

Long (or long where null is not an issue) is used for UTC timestamps for various reasons. Independence from system time especially in business critical environments (like Real Time Trading) is probably the most important reason NOT to use System.getTimeInMillis() or equivalents like JSR-310 provides from Java 8.





Generated at Fri Apr 25 03:47:59 UTC 2014 using JIRA 4.0.2#472.