[JAVAMONEY-38] RI artifacts found their way into Spec/API Created: 06/Apr/13  Updated: 08/Aug/13  Due: 07/Apr/13  Resolved: 14/Apr/13

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

Type: Bug Priority: Critical
Reporter: keilw Assignee: atsticks
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes


 Description   

This may have been well-intended or fueled by "inspiration" from JSRs like 310 where concrete implementations like Duration are hiding underlying base types such as TemporalAmount, but fact is, concrete final classes Money, MoneyCurrency and MoneyRounding do not belong to the Spec/API in a package like javax.money as it exists today.

If a ThreeTenesque design was intended, a massive restructuring would have to be considered.
Either moving all "javax.money" elements into a sub-package like "javax.money.api" (JSR 352 followed a similar approach, but AFAIK left the root package intentionally empty) or "javax.money.core" could pave the way for putting concrete implementing classes into javax.money.

However, if those "default implementations" are based on BigDecimal like the current Money class, that means, the Spec/API would contain elements of the RI in its root package, and those opposing the use of BigDecimal had to live with this type while not using it.
Worse, given BD does not exist in CLDC the API or Core Module would not be compatible without sub-setting.

The question is quite serious, and requires distinct answers by at least Oracle JDK architects, if they are happy and willing to ignore/deprecate java.util.Currency in favor of a default implementation in the javax.money (or java.money, should the standalone approach this undermines be abandoned?) package space. Notable exceptions would be Collection API or JNDI with both Context and InitialContext in javax.name

IntegralMoney, currently part of the RI should then maybe moved to "ext", while the entire ext question stil needs to be clarified, e.g. de-scoping some of those from the Spec. Having one class of the RI in a completely diffent package/artifact while having all others directly in the main root package of the Spec itself makes it very inconsistent.

Also, if this "default implementation" approach is sanctioned by Oracle/OpenJDK, this means, the jdk-stub will have to die, as it no longer makes any sense that way.



 Comments   
Comment by atsticks [ 07/Apr/13 ]

Isolated core part targeting SE platform on same level as standalone API/TI/TCK.
Will discuss solution with EG in a separate mail with other latest topics and changes/proposals. As for now projcet structure is as follows:

SE scope:
---------

  • money-platform: contains the standalone API/RI
    • money-platform-api: contains the api targeting JDK SE 9
    • money-platform-ri: contains the implementation artifacts targeting JDK SE 9

Standalone scope
----------------

  • money-api: contains the standalone API part
    • convert: currency conversion
    • format: foramtting and parsing
    • provider: accessors
    • ext: extensions
  • money-impl: contains the standalone implementation artifacts
    • ri: contains the reference implementation, runnable on SE 7 or later
    • cdi: contains alternate loader implementation using standalone CDI (weld)
    • java-ee: contains alternate loader targeting EE 6 CDI container integration
  • money-tck: contains the technical compatibility kit (TCK)




[JAVAMONEY-35] OSGi enable JSR Created: 10/Mar/13  Updated: 08/Aug/13  Resolved: 27/Jul/13

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

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


 Description   

Adding OSGi bundle information to API via Apache Felix plugin






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.






[JAVAMONEY-27] Country Created: 05/Feb/13  Updated: 10/Mar/14  Resolved: 10/Mar/14

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

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

Tags: complex, region

 Description   

I still think Country is a crucial concept, as at least most (non-precious-metal) ISO Currencies belong to a Country. Its distinct from locale.

My example implementation for discussion:

https://usertype.svn.sourceforge.net/svnroot/usertype/trunk/cdt/src/main/resources/fmpp/ISOCountryCode.fmt



 Comments   
Comment by keilw [ 05/Feb/13 ]

I feel, it isn't a good idea to ignore JDK i18n team for that. If we can raise a separate JEP for a Country or region type, that sounds like a good idea, but I am not sure, if it won't exceed the JSRs scope adding something that recreates at least large aspects of a country defined in Locale already.

Comment by atsticks [ 06/Feb/13 ]

If country is defined to be an ISO country, using the ISO two letter code, I do not think it is useful (the Locale does its job there quite good). But, we also have the need for further classifications, e.g. the ones defined by the Unicode standard (there called regions). Also here the Locale class may cover some of the aspects, since it is not only supporting ISO countries but also regions.

Nevertheless we also can argue for a even more flexible Region abstraction in our extensions module. We must ensure, that the Region model in our JSR is capable to model the aspects as defined in the Unicode standards (we also can relatively easily support such things in the RI, since the according XML data files can be freely downloaded).
Additionally when handling historic currencies and since currencies also have a relation to countries, then also a need for historic countries may arise, which then may not be covered the Locale class really. Hereby the problem seems to me very similar to namespaces and mappings for currencies. So perhaps we need to generalize these aspects and apply them similarly to countries/regions. Makes things not simpler, but at the end flexible enough to cover the complexity that is reality

Comment by atsticks [ 10/Mar/14 ]

Was decided to be out of scope of the JSR, the JabaMoney library Comes with an according Regions module.





[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#






[JAVAMONEY-13] Abstraction for Currencies Created: 31/Jan/13  Updated: 08/Aug/13  Resolved: 26/Apr/13

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

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

Tags: Currency, CurrencyUnit, api, multi-curency, time_handling

 Description   

Provide an interface and a value type for a CurrencyUnit, which provides the following functionality:

  • the CurrencyUnit interface modelled does not define any methods for changing the internal state.
  • the value type must be final and immutable, and implement the CurrencyUnit interface.
  • CurrencyUnit may have different namespaces, e.g. 'ISO-4217' (default), but also arbitrary others are supported.
  • the namespace of a CurrencyUnit can be accessed by a corresponding method String getNamespace().
  • a CurrencyUnit must have a unique literal currency code unique within the namespace, accessible by a method String getCurrencyCode().
  • a CurrencyUnit provides the basic non localized methods similar to java.util.Currency for maximal backwards compatibility:
    • int getNumericCode() Gets a numeric currency code. Hereby -1 is returned if no numeric code is available for an instance.
    • int getDefaultFractionDigits(), Gets the number of fractional digits typically used by a currency. -1 is returned if no such value is available for an instance
  • a CurrencyUnit has a time period defined, when it is valid. This is modelled by Long getValidFrom(); and Long getValidUntil();.
    • If no feasible values can be returned, or the currency unit is still valid in the current context, null is returned for the time period methods.
    • the implementation of CurrencyUnit by java.util.Currency should always return null for both methods as a default.
    • SPI implementation may create additional instances of CurrencyUnit also for the ISO-4217 namespace, that reflect the currency duration as defined also by ISO.
  • A CurrencyUnit has a boolean flag if it has a legal tender.
  • Finally a CurrencyUnit can be a real or a virtual currency, modelled by the boolean isVirtual() method.
  • a Currencynit extends AttributeProvider, which allows to provide additional arbitrary attributes. This is required since complex use cases, such as not clearly defined ISO codes and legal tenders may require passing additional information, that can not be fully covered by this JSR.
  • The implementations of CurrencyUnit must implement Comparable<CurrencyUnit>, whereas the interface does not define this requirements due to decoupling aspects.

Access
Instances of CurrencyUnit can be obtained

  • by using the CurrencyProvider available on the Monetary singleton. This allows to support more complex use cases, e.g. classification based access, historic currencies and alternate namespaces.
  • by using the static factory method on java.util.Currency instance (the JDK class must, of course, implement CurrencyUnit.





Generated at Sun Apr 19 23:56:59 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.