[JAVAMONEY-31] Adding two get methods to CurrencyUnitProvider to make the String namespace parameter as default to 'ISO-4217' Created: 11/Feb/13  Updated: 08/Aug/13  Resolved: 12/Feb/13

Status: Closed
Project: javamoney
Component/s: API
Affects Version/s: None
Fix Version/s: 0.3

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

javax.money. interface CurrencyUnitProvider


Tags: adoptajsr, jugchennai

 Description   

Currently CurrencyUnitProvider provides two get method with parameter (String namespace, String code) and (String namespace, String code, long timestamp). Both these method mostly user need to specify a namespace and code. If we provide a get method without namespace, we can minimize the entry of namespace. The provider can give a default namespace to the API.

So we can provide two get method as
public CurrencyUnit get(String code);
public CurrencyUnit get(String code, long timestamp);

for the current RI we can can make the namespace to "ISO-4217" as default value.



 Comments   
Comment by atsticks [ 11/Feb/13 ]

That's a good point, convenience also is important. Additionally I would add a method:

String getDefaultNamespace();

Also not that timestamp currently is modelled as Long not long for enabling passing null as undefined value.

Additionally default namespace can be changed by setting a system property: -Djavax.money.defaultCurrencyNamespace=whateverNS.

Comment by atsticks [ 12/Feb/13 ]

Methods were added on interfaces and test/RI implementations.

Comment by Rajmahendra Hegde [ 12/Feb/13 ]

@atsticks I just saw this now.. sorry..

What about if we do the same way to isAvailable method also?

We have one method

 
public boolean isNamespaceAvailable(String namespace);   //this is meaningful

but for other isAvailable method, we can give methods without the namespace parameter

Comment by atsticks [ 12/Feb/13 ]

This may be similarly useful, yes.

Comment by Rajmahendra Hegde [ 12/Feb/13 ]

Cool then I will update the description to incorporate this changes also.





[JAVAMONEY-24] Mapping of Currencies Created: 02/Feb/13  Updated: 10/Mar/14  Resolved: 10/Mar/14

Status: Closed
Project: javamoney
Component/s: API
Affects Version/s: None
Fix Version/s: 0.3

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

Tags: currency, grouping, mapping, region

 Description   

Define a flexible API to map between different currencies:

  • map between different codes within the same namespace
  • map between different namespaces
  • think of grouped or leading currency instances
  • think of mapping the relations between current currencies in a country and former historic ones:
    • e.g. in Italy ITL was the valid currency before introduction of the EUR.

Since mapping can be implemented by several realizations active at the same time, a mechanism must be defined, how different Spi implementations can be used in parallel and transparently in the accessor implementation.



 Comments   
Comment by atsticks [ 10/Mar/14 ]

Functionality was decided to be too specific and will not be part of the JSR.





[JAVAMONEY-23] Extended JSR Scope Created: 02/Feb/13  Updated: 10/Mar/14  Resolved: 10/Mar/14

Status: Closed
Project: javamoney
Component/s: Misc: JCP Administration
Affects Version/s: None
Fix Version/s: 0.3

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

Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVAMONEY-32 Separate platform aspects from advanc... Sub-task Closed  
JAVAMONEY-33 Update public JSR descriptions Sub-task Closed atsticks  
Status Whiteboard:

The ballot has been closed:

  • 4 votes for platform
  • 1 vote for standalone
  • 1 vote for EE profile
  • 5 votes for mixed

It was decided by the spec lead to go for a mixed scope, but with a clear separation of concerns. There will no separate JSR be defined, but the official statements on the JCP site must be clarified.
The scope redefinition was summarized in the following document:
https://docs.google.com/document/d/1e08N4Gp1677nTP0YZza_kuo3356iBMk93ApTCzePXA4/edit#heading=h.2kjfhpo1yuna

Tags: EE, JSR, extended, scope

 Description   

This JSR's scope has to be discussed and probably redefined/extended so all features and requirements discussed in this EG can be successfully made generally available to the user. Depending on the constraints this may require to create an additional EE targeting JSR, or perhaps also it is possible to extend this JSR to also define some EE features additionally.



 Comments   
Comment by atsticks [ 10/Mar/14 ]

It was decided to go for a standalone scope first. Integration with JDK will be discussed at a later Point.





Generated at Sun Aug 30 17:37:43 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.