[JAVAMONEY-153] Language and clarity improvements Created: 23/Sep/15  Updated: 23/Sep/15

Status: Open
Project: javamoney
Component/s: Spec: Specification
Affects Version/s: 1.0
Fix Version/s: 1.x

Type: Improvement Priority: Minor
Reporter: mutonhojeff Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PDF File JavaMoney_Specification_1.0-final-jeff-edits.pdf    
Tags: specissue

 Description   

Language corrections and specification clarity improvements. The improvement comments are visible through activation of the "Comments" window in Adobe PDF Reader.



 Comments   
Comment by keilw [ 23/Sep/15 ]

Since this is a change request to the spec, however minor found typos or other proposed changes may be, it can't be published without an official MR (thus target version 1.x which means a MR like 1.1, etc.)





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

Status: Closed
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
Labels: None
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour


 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-53] Update/prepare Spec for Public Draft Review Created: 08/Aug/13  Updated: 05/Feb/15  Resolved: 15/Sep/13

Status: Closed
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
Labels: None
Remaining Estimate: 4 days
Time Spent: Not Specified
Original Estimate: 4 days


 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






[JAVAMONEY-83] Change key type in Contexts/Queries to String Created: 02/Feb/15  Updated: 05/Feb/15  Resolved: 05/Feb/15

Status: Closed
Project: javamoney
Component/s: API, Impl: RI, Spec: Specification, Test: TCK
Affects Version/s: 0.9
Fix Version/s: 1.0

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


 Description   

Change key type in Contexts/Queries to String (currently it is Object). This reduces the complexity of the context class and its builders drastically.



 Comments   
Comment by atsticks [ 05/Feb/15 ]

Fixed in 1.0-RC2.





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

Status: Closed
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
Labels: None
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours


 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 ]
  • 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-46] Add support for accountants notation Created: 08/Aug/13  Updated: 05/Feb/15  Resolved: 30/Aug/13

Status: Closed
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
Labels: None
Remaining Estimate: 4 hours
Time Spent: Not Specified
Original Estimate: 4 hours


 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.






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: 05/Feb/15  Resolved: 15/Sep/13

Status: Closed
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
Labels: None
Remaining Estimate: 8 hours
Time Spent: Not Specified
Original Estimate: 8 hours


 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-14] Support different time dimensions Created: 01/Feb/13  Updated: 05/Feb/15  Resolved: 09/Mar/14

Status: Closed
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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: date, time, time_handling, timestamp

 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 ]

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 ]

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 ]

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.





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

Status: Closed
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
Labels: None
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours


 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-47] Define updating mechanism Created: 08/Aug/13  Updated: 05/Feb/15  Resolved: 15/Sep/13

Status: Closed
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
Labels: None
Σ 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 Closed  
JAVAMONEY-51 Update the CLDC region providers to u... Sub-task Closed  
JAVAMONEY-52 Update the CurrencyProviders to use t... Sub-task Closed  
JAVAMONEY-60 Define and test an updater mechanism Sub-task Closed 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-71] Get rid of Serializable in API or fix Spec if we can't Created: 03/May/14  Updated: 02/Sep/14  Resolved: 02/Sep/14

Status: Closed
Project: javamoney
Component/s: API, Spec: Specification
Affects Version/s: 0.8
Fix Version/s: 0.9

Type: Bug Priority: Minor
Reporter: keilw Assignee: atsticks
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: interoperability, serialization

 Description   

The use of Serializable in the API rather than RI (at least by every *Context class and ExchangeRate breaks compatibility with Java ME.
Serializable does not exist even in ME 8.

The corresponding notes in the Spec (=== EE and ME Support and a few other paragraphs) are incomplete, as they don't include Serializable. It seems OK for a (currently SE only) RI like Moneta, but should be removed from the API.

If that wasn't possible, the only alternative is to scrap notes about ME compatibility, and (similar to e.g. JSR 353) require a "down-grade" or fork of the API for ME.



 Comments   
Comment by keilw [ 20/Jul/14 ]

This seems not desired or doable for some classes, at least concrete classes like AbstractContext.

Comment by keilw [ 02/Sep/14 ]

Given the usage of Serializable and SE 8 features by the API, this makes little sense.





[JAVAMONEY-17] Define Attributable Feature for Extended Use Cases Created: 01/Feb/13  Updated: 11/Mar/14  Resolved: 11/Mar/14

Status: Closed
Project: javamoney
Component/s: API, Spec: Specification
Affects Version/s: None
Fix Version/s: 0.8

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


 Description   

Discussions have shown that many use cases that can not be covered by this JSR. This requires to add some more flexibility to some of the artifacts (value types) defined. It was basically agreed that this features should be minimized and modeled as type safe as possible:

  • this feature is modelled by an interface called javax.money.util.AttributeProvider.
  • attributes can be accessed by <T> T getAttribute(String key, Class<T> type).
  • the current defined keys can be accessed by Enumeration<String> getAttributeKeys().
    • It was decided to use an Enumeration since it is commonly used within the JDK and also matches better to the use case since Iterator#remove() is not supported.
  • The attribute type for a key can be accessed by Class<?> getAttributeType(String key), if no such key is available null is returned.

Since adding attributes is not simple, it may be required that creating attributable instances may require using a 'builder pattern'.






[JAVAMONEY-19] Support for regional Rounding Rules Created: 01/Feb/13  Updated: 10/Mar/14  Resolved: 10/Mar/14

Status: Closed
Project: javamoney
Component/s: API, Impl: RI, Spec: Specification
Affects Version/s: None
Fix Version/s: 0.8

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


 Description   

Support for regional and custom rounding rules is provided:

  • Roundings that are defined by a CurrencyUnit, refer also to the Unicode standard.
  • Support for arbitrary roundings defined by use cases.
  • Providing a comprehensive API/SPI for Rounding and according accessor methods.
  • Ensure interoperability with rounding as defined by java.math.


 Comments   
Comment by chrispheby [ 05/Feb/13 ]

Couple of use cases:

In Singapore, 1 cent coins are no longer being produced although they remain in circulation. As a result I have never seen one. Retailers round cash (but not card transactions) to the nearest 5 cents. I believe Canada is in the process of doing this the same move currently.

In Saudi Arabia, some retailers round up to the nearest riyal, with the difference forming a charitable donation.

Comment by atsticks [ 10/Mar/14 ]

MonetaryRoundings allows to pass a MonetaryContext that may contain any additional Parameters required. So this Feature is fully covered by the current API.





[JAVAMONEY-15] EDR Specification Document Created: 01/Feb/13  Updated: 10/Mar/14  Resolved: 10/Mar/14

Status: Closed
Project: javamoney
Component/s: Spec: Specification
Affects Version/s: None
Fix Version/s: 0.4-EDR1

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

Google Doc



 Description   

Provide a sharable EDR document for collaboration and review:
https://docs.google.com/document/d/1BX-oBcRfE9baD1YCIPN3Fp6Tft85RknwphtkGz0roNA/edit#






Extended JSR Scope (JAVAMONEY-23)

[JAVAMONEY-32] Separate platform aspects from advanced features. Created: 16/Feb/13  Updated: 10/Nov/13  Due: 01/Mar/13  Resolved: 27/Apr/13

Status: Closed
Project: javamoney
Component/s: General: Build and quality management, Impl: RI, Spec: Specification
Affects Version/s: 0.3
Fix Version/s: 0.4-EDR1

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


 Description   

Separate platform aspects from advanced features. Ensure separation also within other area, e.g.

  • specification
  • JIRA
  • etc.

Discuss details in next EG meeting.






Generated at Fri Feb 12 15:19:42 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.