[JAVAMONEY-70] Simple package name in RI does not match RI for conversion Created: 11/Mar/14  Updated: 11/Mar/14  Resolved: 11/Mar/14

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

Type: Bug 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   

In API ist javax.monex.convert,
whereas in RI it is org.javamoney.moneta.conversion
The name in the RI should be changed to org.javamoney.moneta.convert .






[JAVAMONEY-69] isLowerBound and isUpperBound should be hasLowerBound and hasUpperBound in ProviderContext Created: 09/Mar/14  Updated: 05/Feb/15  Resolved: 10/Mar/14

Status: Closed
Project: javamoney
Component/s: API
Affects Version/s: 0.7
Fix Version/s: 0.8

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

Tags: conversion

 Description   

The ProviderContext class in the "convert" package has 2 methods isLowerBound() and isUpperBound().
While is* tends to be used for boolean getters, there are exceptions, and those cases prefer has*

API elements with a similar purpose like *Range in Google Guava consistently call these
public boolean hasLowerBound() or hasUpperBound().






[JAVAMONEY-68] Consider renaming JavaMoneyConfig Created: 02/Mar/14  Updated: 10/Mar/14  Resolved: 10/Mar/14

Status: Closed
Project: javamoney
Component/s: API
Affects Version/s: 0.7
Fix Version/s: 0.8

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

Tags: spi

 Description   

While JavaMoney is the domain for the overall project, the term seems more attached to the RI or downstream projects.
Could we rename JavaMoneyConfig to MonetaryConfig in the SPI?

The name for the properties file wouldn't have to change because of that.



 Comments   
Comment by atsticks [ 10/Mar/14 ]

Class was renamed and additionally also moved to RI part.





[JAVAMONEY-67] Replace BigDecimal in ExchangeRate conversion factor Created: 02/Mar/14  Updated: 09/Mar/14  Resolved: 02/Mar/14

Status: Closed
Project: javamoney
Component/s: API
Affects Version/s: 0.7
Fix Version/s: 0.8

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

Tags: conversion

 Description   

the factor value of javax.money.convert.ExchangeRate refers to BigDecimal.
As JSR 354 introduced a type NumberValue this type should also be used there instead.



 Comments   
Comment by keilw [ 02/Mar/14 ]

Replaced BD with NumerValue

Comment by keilw [ 09/Mar/14 ]

Done





[JAVAMONEY-66]  Compatibility with new Stream-API of Java 8 Created: 25/Nov/13  Updated: 10/Mar/14  Due: 26/Nov/13  Resolved: 10/Mar/14

Status: Closed
Project: javamoney
Component/s: None
Affects Version/s: 0.7
Fix Version/s: 0.8

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

Tags: design

 Description   

Based on Public Draft input we shall reconsider MonetaryFunction and/or MonetaryOperator instead of MonetaryAdjuster.
The term Financial Adjustment has at least 3 special meanings, see: http://financial-dictionary.thefreedictionary.com/Adjustment
Especially 1. is directly related to "Bad Banks", hence we clearly want to avoid such impression in the API






[JAVAMONEY-65] Add new SNAPSHOT version post PR Created: 10/Nov/13  Updated: 02/Mar/14  Resolved: 02/Mar/14

Status: Closed
Project: javamoney
Component/s: API
Affects Version/s: 0.7
Fix Version/s: 0.8

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

Tags: release

 Description   

As the PR is frozen the latest master release should be 0.8-SNAPSHOT



 Comments   
Comment by keilw [ 02/Mar/14 ]

Done





Define updating mechanism (JAVAMONEY-47)

[JAVAMONEY-60] Define and test an updater mechanism Created: 27/Aug/13  Updated: 10/Mar/14  Resolved: 10/Mar/14

Status: Closed
Project: javamoney
Component/s: Impl: RI
Affects Version/s: None
Fix Version/s: 0.8

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


 Description   

Define and test an updater mechanism usable by the different component within the RI with the following:

  • Reads resources from the internet
    • scheduled
    • on programmatic trigger
    • on JMX trigger
    • never
  • Reads fallback resources, when no newer version is available
    • from classpath
    • from the filesystem
  • Caches newly loaded files in the local filesystem (if writable)
    • in a specified location
    • within the user directory


 Comments   
Comment by atsticks [ 10/Mar/14 ]

There is a LoaderService SPI, that can be implemented in different ways, providing loading, Caching, reloading and listener hooks.





[JAVAMONEY-48] Design and implement caching of value types Created: 08/Aug/13  Updated: 10/Mar/14  Resolved: 10/Mar/14

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

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


 Description   

Check the RI implementation, where simle caching of values can be feasible to reduce creation of new object instances.



 Comments   
Comment by atsticks [ 10/Mar/14 ]

Basically Caching can be implemented for all parts of the JSR by the SPIs registered. For currencies it is basically in place, whereas for monetary amounts it may be nt feasible in most Scenarios, since an amount's MonetaryContext can make Caching quite useless.





[JAVAMONEY-41] Consolidate Logging Frameworks Created: 27/Apr/13  Updated: 10/Mar/14  Resolved: 10/Mar/14

Status: Closed
Project: javamoney
Component/s: General: Build and quality management
Affects Version/s: 0.4-EDR1
Fix Version/s: 0.8

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

Tags: logging

 Description   

Various components use different logging frameworks, including

  • java.util.logging
  • SLF4J
  • Log4J

Except for those parts where only the JDK build in java.util.logging API shall be used to avoid 3rd party dependencies, all others should use SLF4J. Its bridge also to java.util.logging allows a unified logging better than direct calls to individual APIs.



 Comments   
Comment by keilw [ 02/Mar/14 ]

Is this done?

Comment by atsticks [ 10/Mar/14 ]
  • Currently API, RI and TCK only use JUL.
  • JavaMoney Library I think uses only slf4j

The JSR related parts so are clean at least.





[JAVAMONEY-28] Serialization Created: 05/Feb/13  Updated: 10/Mar/14  Resolved: 10/Mar/14

Status: Closed
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 0.1.0
Fix Version/s: 0.8

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


 Description   

Should the API standardise the serialization form for the core types.
This seems to be necessary for the SE RI to interoperate with other implementations.



 Comments   
Comment by atsticks [ 06/Feb/13 ]

I think it is useful. An important point is that the precision in use also should be transferred. Would you like to make a proposal?

Comment by atsticks [ 10/Mar/14 ]

Javadoc was updated accordingly, no further Action planmned on this.





[JAVAMONEY-26] Multi ExchangeRate Created: 02/Feb/13  Updated: 11/Mar/14  Resolved: 11/Mar/14

Status: Closed
Project: javamoney
Component/s: API
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

Tags: compound_rate, exchange_rate

 Description   

Define a compound multi-valued exchange rate that consists of several exchange rates:

  • of the same provider, but with different target currencies
  • of different providers, but with the same target currency
  • a mix of the above.

A compound value has the following properties:

  • it is immutable.
  • it does not offer arithemtics
  • it provides access to all its containing{{ExchangeRate}} instances:
    • Map<String,ExchangeRate> getAll()
    • Enumeration<String> getKeys();
    • ExchangeRategetExchangeRate(String key)
    • boolean isExchangeRateDefined(String key)
  • It allows access to all different rates contained:
    • Enumeration<ExchangeRate> getContainedExchangeRates()
  • it provides a CompoundExchangeRateFactory for creating compound values.
  • Since a compound amount is defined to be immutable, it can only be extended/adapted as follows:
    • CompoundExchangeRate add(String key, ExchangeRate amount);
    • CompoundExchangeRate remove(String... key);
    • CompuntExchangeRateBuilder toBuilder() // and using the builder to create a new instance


 Comments   
Comment by chrispheby [ 05/Feb/13 ]

I guess this would be part of an extension module.

Comment by atsticks [ 06/Feb/13 ]

Basically they are currently here, because I was thinking about using them in some API/SPI here for multi provider access of exchange rates (until now I did not have the time, to dive deeper on this topic). If finally (since it shows not to be useful, I am not able to make a useful proposal or whatever) they are not used by this module, of course, I totally agree, to move them to the extensions part. So just be a bit patient





[JAVAMONEY-22] Support Complex Usage Scenarios for Exchange Rates and 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.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

Tags: complex, conversion, currency, exchange_rate, region

 Description   

Define a flexible API tu support complex usage scenarios for exchange rates and currencies, such as

  • access per region or terrritory
  • direct and chained exchange rates
  • multiple data provider support
  • handling of deferred rates
  • Check modelling for trading systems e.g. including separation into bid/ask etc.


 Comments   
Comment by keilw [ 02/Feb/13 ]

Same here, it's not subject to the Core module, but Convert / Exchange, either of its own base or an extension to it.

Comment by atsticks [ 10/Mar/14 ]

The conversion API in 0.8 allows to pass a ConversionContext when accessing rates, so all possible data can be passed.





[JAVAMONEY-21] Provides access for historic exchange rates. 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.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   

Currencies must be also be provided as historic instances, where possible. Similarly exchange rates also must be accessible for historic timestamp. This includes also defining a small but powerful SPI that allows to include several service provider implementations simultaneously.

Historic instances can be obtained

  • by using the corresponding XXXProvider available on the Monetary singleton.
  • by creating according instances manually using the static factory method/builder on value type class.


 Comments   
Comment by atsticks [ 10/Mar/14 ]

The conversion API allows to pass several (basically arbitrary) data with the ConversionContext, so this Feature is fully covered.





[JAVAMONEY-20] Formatting and Parsing Created: 01/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.8

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

Tags: Locale_extensions, builder, format, parsing, styles

 Description   

Define comprehensive and powerful formatting and parsing features for the different artifacts and use cases defined in Java Money. Hereby support

  • multiple styles
  • multiple locales
  • additional custom attributes required by the parser/formatter.
  • For programmatic use cases provide also a builder pattern.

The Locale extensions available since SE 7 provide a good starting point. Also the Unicode standard gives additional input.



 Comments   
Comment by chrispheby [ 05/Feb/13 ]

One point is that in almost all locales western number formatting and English are used for financial calculations even if alternatives are used in other contexts. Also we need to consider use case specific representations - e.g. use of '(' and ')' in financial accounts. i.e. common use of the API may not simply be render in the users locale.

Comment by atsticks [ 05/Feb/13 ]

I made some tests with the new Unicode Locale extensions support, valid starting from JDK7. In my opinion the possibilities are very strict, so I still think we need some style artifacts as the ones designed currently.

Comment by atsticks [ 10/Mar/14 ]

There is a simple formatting API since 0.8.





[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-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-16] Abstraction for Monetary Amounts Created: 01/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.8

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

SE


Tags: amount, javamoney_core, monetary, monetary_amount

 Description   

Model an interface MonetaryAmount and an according value type as follows:

  • the interface MonetaryAmount is designed as immutable, the implementation classes must be final and immutable.
  • a MonetaryAmount has a CurrencyUnit attached, each amount instance must have a CurrencyUnit.
  • a MonetaryAmount has a numeric value, which may is NOT exposed.
  • For interoperability MonetaryAmount provides converters to several types similar as defined on java.lang.Number.
  • For additional interoperability the MonetaryAmount defines a method <T> T asType<Class<T>) which allows to extract arbitrary representation types.
    • in a SE environment, it is required that
      • all number types extending java.lang.Number must be supported.
      • java.math.BigDecimal and java.math.BigInteger must be also supported.
      • when passing java.lang.Number.class BigDecimal is returned as result type.
    • in other environments this should be similar. If not possible, alternate types are allowed.
  • MonetaryAmount also provides basic arithmetic functions similar to java.math.BigDecimal. Extended functionality must be modelled using the Java Money extension SPI.
  • the methods String toPlainString() and String toEngineeringString() are supported similarly as in java.math.BigDecimal, whereas in this case the CurrencyUnit is prepended, e.g. ISO-4217:CHF 1234.35
  • Additional arithmetic operations not defined on MonetaryAmount can be applied by passing an AmountAdjuster instance to MonetaryAmount with(AmountAdjuster...).
  • Finally a MonetaryAmount with a different numeric value, but the same currency can be created by calling MonetaryAmount.width(java.lang.Number).

Access

  • MonetaryAmount instances can be created by calling static factory methods on the value type classes directly, e.g.
    • Money m1 = Money.of(1.456,"CHF")
    • Money m2 = Money.of(-234456,Currency.get("USD")





Generated at Tue Jun 02 13:53:53 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.