[JAVAMONEY-164] Bulgarian Lev Wrong Currency Format Created: 16/Jul/16  Updated: 17/Jul/16

Status: Open
Project: javamoney
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: paranoiabla Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hello,

doing this:

monetaryAmountFormatFactory.create(new Locale("bg_BG")).format(source);

produces лв.999.99 which is wrong. The correct display of Bulgarian money must be 999.99 лв..



 Comments   
Comment by keilw [ 17/Jul/16 ]

Thanks for spotting. Did you also try the JDK NumberFormat if that shows the same problem? In many cases aspects of the underlying JDK are used. Could you also share, which Java version you used and whether it was Moneta or Moneta-BP? (for Java 7 or earlier)

Comment by paranoiabla [ 17/Jul/16 ]

Hi,

I'm using org.javamoney:moneta with Java8:

java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)

I also tried this one:

        NumberFormat nf = NumberFormat.getCurrencyInstance(new Locale("bg_BG"));
        System.out.println(nf.format(12.00));

and the result is:

¤ 12.00




[JAVAMONEY-163] Get display name/symbol of a CurrencyUnit Created: 12/Jul/16  Updated: 07/Sep/16

Status: Open
Project: javamoney
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: paranoiabla Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Following this question here:

http://stackoverflow.com/questions/37869617/get-display-name-of-javax-money-currencyunit

I got not answer and I think it is impossible at the moment, that's why I want to propose an improvement. Given I have an instance of `CurrencyUnit` I'd like to know what the name of that currency in a specific locale is (for example "Euro", "Евро", "American US. Dollar", "Japanese Yen", etc). Also I'd like to get the symbol for that currency: $, €, etc..



 Comments   
Comment by keilw [ 12/Jul/16 ]

Other frameworks including the JDK with java.util.Currency, ICU4J or JodaMoney all treat both getDisplayName() and getSymbol() methods where available as Locale-sensitive. Even though a default variant of each method exists it is clearly expressed, those are convenience methods assuming the default Locale to be used.

Locale-sensitive formatting of CurrencyUnit is already done via MonetaryFormats and the RIs offer features like CurrencyStyle. Should we have focussed mostly on the MonetaryAmount then maybe either in the RIs or a future version of the API a separate CurrencyFormat similar to an equivalent in JSR 363 UnitFormat could be of use. I would try to avoid binding Locale directly into CurrencyUnit if possible even for a default or convenience method like getSymbol() though I could live with that, see JSR 363. However the symbol of 363 is more like getCurrencyCode(), the ISO 4217 currency code of a currency, and locale-neutral identifier. Only when you format the JSR 363 Unit another visualization of that unit may come into play, based on a locale in some cases.

Comment by stokito [ 07/Sep/16 ]

I came with the same problem. Absence of <code>name</code> in currency unit makes little bit difficult to implement CurrencyUnit.
Could we make name resolving in the same way as it done for example in java.util.Currncy class where we have getDisplayName() and getDisplayNameLocale inLocale) methods?
Anyway, we need for support of currency name resolving for custom currencies like Bitcoin





[JAVAMONEY-155] make ConvertNumberValue public Created: 25/Sep/15  Updated: 27/Sep/15

Status: Open
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: msgilligan Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours


 Description   

When extending NumberValue, implementing numberValue(Class<T> numberType) and numberValueExact(Class<T> numberType) is non-trivial.

For those willing to add a dependency on the RI, it would be nice to be able to use the ConvertNumberValue enum. Can it be made public?



 Comments   
Comment by otaviojava [ 27/Sep/15 ]

I don't think it's the good idea:

  • This class is not the goal of the API
  • Once this class public we need to take care any refactoring, in other words, any improvements or change in this class it will slower.
  • To remove this class one day if public it will spend more time, one to deprecated it and then to finally remove it.
Comment by keilw [ 27/Sep/15 ]

Well the same goes for other RI elements like MonetaryUtil which was public and has to be restored, or if it was to stay in a similar form MonetaryOperators and other RI level public elements. I don't see if we add all sorts of stuff in a function package why this should not be available the same way.

Comment by msgilligan [ 27/Sep/15 ]

The problem is that any class implementing NumberValue is required to implement

<T extends Number> T numberValue(Class<T> numberType)

which is essentially a requirement to convert to any of the built-in number types. So every implementation is being forced to implement this functionality.

Perhaps making ConvertNumberValue isn't the best API or implementation to make public. But something should be provided by the RI and possibly even specified in a future version of the API. In fact, I'd go so far as to say that an arbitrary Number to Number conversion should be included in the JDK itself.

Comment by msgilligan [ 27/Sep/15 ]

The ideal solution might be something like this:

1. NumberValue (or a provided subclass) would require a no-parameters numberValue() method that would return a Number of the same type that getNumberType() returns. This would be the default or preferred representation of the internal type.

abstract public Number numberValue();

I'm not sure whether there would need to be a no-parameters version of numberValueExact or if we could safely assume that the preferred conversion would always be exact.

2. This provided abstract base class would provide an implementation of numberValue(Class<T> numberType) similar to:

public <T extends Number> T numberValue(Class<T> numberType) {
        return ConvertNumberValue.of(numberType, numberValue());
}

Summary

Implementing classes would provide a method to convert to the optimal standard Number type. The framework itself would provide the method that converts to any of the standard subtypes. This would make creating an implementation of NumberValue much easier as only a conversion to a single type would be required. In most cases I would imagine that type would be Long, BigInteger, or BigDecimal.





[JAVAMONEY-161] Provide a way to change the configuration source Created: 16/Jun/16  Updated: 16/Jun/16

Status: Open
Project: javamoney
Component/s: None
Affects Version/s: None
Fix Version/s: None

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


 Description   

Hello,

I'd like to be able to provide a different source for the configuration, other than a file called javamoney.properties. At the moment this value is hard-coded in the reference implementation:

https://github.com/JavaMoney/jsr354-ri/blob/master/src/main/java/org/javamoney/moneta/spi/MonetaryConfig.java#L46-L47

and I believe this is because the spec doesn't say anything about other sources of configuration. In my particular case I'm building a spring-boot application and I would like all of my configuration to be in one place, so I would love to be able to configure the java money API from the application.properties file of spring boot.



 Comments   
Comment by keilw [ 16/Jun/16 ]

Thanks for the suggestion. We can't take random properties files from an arbitrary "Cool Framework" or "Microservice whatsoever" unless it's either part of the JDK or at least another Java Standard. The JDK itself has SPI hooks to control things like Locale providers or also in a limited way for java.util.Currency. As JSR 354 was outruled for Java 9 inclusion, we did not have a chance or need to tap into that, but either with a new version targetting a future JDK or similar we might offer something, e.g. command line arguments you may configure from SpringBoot, CDIBoot or whatever.

I guess at least for the RIs we'll also discuss with Anatole, how Apache Tamaya (which we demonstrated using Spring Boot or similar tools) could help with that





[JAVAMONEY-142] Define some tests as "integration-test" Created: 27/Jul/15  Updated: 23/Aug/15

Status: Open
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
Fix Version/s: None

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

Issue Links:
Related
is related to JAVAMONEY-125 Add missing tests Resolved
Tags: test

 Description   

Some CI servers like Circle-CI call mvn integration-test by default. For those tests in need of external services by ECB, IMF, Yahoo, etc. we should try to rebrand them into "Integration Tests" and run them separately or optionally where necessary. See http://stackoverflow.com/questions/1399240/how-do-i-get-my-maven-integration-tests-to-run






Generated at Mon Feb 27 08:07:41 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.