Ensure, RI-BP is in sync (JAVAMONEY-124)

[JAVAMONEY-135] Ensure Unit Test coverage and results are comparable Created: 22/Jun/15  Updated: 04/Jun/16

Status: Reopened
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.1
Fix Version/s: 1.2

Type: Sub-task Priority: Critical
Reporter: keilw Assignee: otaviojava
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to JAVAMONEY-104 Make coverage visible on all key arti... Open
Tags: test

 Description   

Currently there is a large difference between Moneta and Moneta-BP when it comes to test-coverage and results:
Moneta (#307: https://travis-ci.org/JavaMoney/jsr354-ri/builds/67812171)
Tests run: 601, Failures: 21, Errors: 0, Skipped: 0
Moneta-BP (#87: https://travis-ci.org/JavaMoney/jsr354-ri-bp/builds/67811489)
Tests run: 440, Failures: 19, Errors: 0, Skipped: 0

The total number of tests differs drastically. The number of failures less, but it should be 0 or close to 0 (or rather a few @Ignore should there be a good reason why it fails) in both cases.



 Comments   
Comment by keilw [ 22/Jun/15 ]

We do have some external dependencies, especially IMF or ECB conversion providers are Integration Tests not just simple "Unit Tests" in their nature, but ideally those should all be green till the 3rd party system changes or breaks something, too

Comment by otaviojava [ 22/Jun/15 ]

The solution to fix JAVA MONEY-131, has broke some tests.
The issue was reopened and the code rollbacked.

Comment by keilw [ 22/Jun/15 ]

I am sure it did not solve the 200 "missing" tests in Moneta-BP?

Comment by otaviojava [ 22/Jun/15 ]

this time you are wrong, I fixed on moneta-bp too.
https://github.com/JavaMoney/jsr354-ri-bp/pull/16

Comment by keilw [ 22/Jun/15 ]

Tests run: 440, Failures: 0
vs.
Tests run: 601, Failures: 2

is not comparable test coverage. Moneta-BP is not a second class citizen, in fact till Java EE 8 gets SE 8 Enterprise ready it is first class.

Comment by keilw [ 08/Feb/16 ]

This https://coveralls.io/github/JavaMoney/jsr354-ri does not even exist for jsr354-bp. It must be set up the same way it was for Moneta.





[JAVAMONEY-137] Make Moneta Modular Created: 16/Jul/15  Updated: 04/Jun/16

Status: In Progress
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.1
Fix Version/s: 1.2

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

Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVAMONEY-138 Core Module Sub-task Resolved keilw  
JAVAMONEY-139 Format Module Sub-task Resolved  
JAVAMONEY-140 Convert Module Sub-task Resolved keilw  
JAVAMONEY-141 Pass TCK Sub-task Resolved keilw  
JAVAMONEY-148 Analyze Dependencies Sub-task Resolved keilw  
Tags: modules

 Description   

Anticipating future Java versions beyond 9 (Jigsaw) Moneta (and Moneta BP which will be required as "standalone" RI even if some day one could be added to platform umbrella) we plan to break Moneta into smaller modules.

Especially the "convert" package, likely "format" and at least a "core" module underneath. Some of these modules may have companion modules, e.g. "convert" with default providers for ECB and IMF.






[JAVAMONEY-143] JavaMoney TCK Usage Example results differ from TCKRunner Created: 29/Jul/15  Updated: 04/Jun/16

Status: Open
Project: javamoney
Component/s: Test: TCK
Affects Version/s: 1.0
Fix Version/s: 1.2

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

Issue Links:
Blocks
blocks JAVAMONEY-141 Pass TCK Resolved
Tags: tck-red, test, testing

 Description   

When trying to run the SE 8 variant of TCK Usage Example (https://github.com/JavaMoney/javamoney-tck-usage-example) against different approaches to modularizing the RI, it occured the example project always keeps running just one version of the TCK and (probably worse) also does not seem to switch the TCK from Moneta-BP to Moneta.

Running java org.javamoney.tck.TCKRunner as suggested directly from the TCK produces a different result than running the TCK Example.

It feels changing

<impl.version>1.0</impl.version>

or other aspects of the implementation details in the POM has no effect on which implementation is actually used. The TCK 1.0 deployed to MavenCentral/JCenter (or a copy in your local Maven repo) seems to be used regardless of implementation details. Even if another TCK version (like "1.0.1-SNAPSHOT" or similar) is available in the local Maven repo and "org.javamoney.tck.version" adjusted accordingly the TCK Usage example seems to ignore that and shows all tests pass, while running java org.javamoney.tck.TCKRunner against the same implementation produces different results.



 Comments   
Comment by keilw [ 29/Jul/15 ]

Adjusting dependencies to a version of Moneta with sub-modules, Maven dependencies look like the version is picked up correctly, and there all 233 TCK tests pass. Running TCKRunner from the TCK project directly causes 11 tests to fail when Moneta is not in a single JAR.
That discrepancy should be resolved, The test does in fact simply call

 TCKRunner.main(new String[0]);

so it looks like a difference in class-loading of relevant modules through Maven starting unit tests and a command line or batch calling TCKRunner. Even though at compile-time there is no error or missing dependency.

Another key difference to analyze is TCKTestSetup.getMonetaryOperators4Test() which only references 2 instead of 10 instances of MonetaryOperator. Tweaking that within the TCK should show, if this difference in test configuration affects the result or it's mainly the way TCKRunnner is called.

Comment by keilw [ 31/Jul/15 ]

Similar to https://github.com/unitsofmeasurement/uom-tools TCKRunner might implement javax.tools.Tool instead of the main method.

/* (non-Javadoc)
 * @see javax.tools.Tool#run(java.io.InputStream, java.io.OutputStream, java.io.OutputStream, java.lang.String[])
 */
@Override
public int run(InputStream in, OutputStream out, OutputStream err,
			String... arguments) {

Allowing it to be called like

Tool tckRunner = new TCKRunner();
int errorCode = tckRunner.run(System.in, System.out, System.err, args);
if (errorCode == 0) {
    System.out.println("Success.");
} else {
    System.err.println("Error.");
}




[JAVAMONEY-144] Resolve License issue with Eclipse Created: 23/Aug/15  Updated: 07/Feb/16

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

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

Issue Links:
Relates
relates to UNITSOFMEASUREMENT-64 Make JSR available to Eclipse Orbit Resolved
Tags: Eclipse, MREL, license

 Description   

Due to a different understanding of what API vs. Implementation is by Eclipse Foundation, there's a blocking issue based on the current LICENSE files in Money-API or Money-API-BP, see https://java.net/jira/browse/UNITSOFMEASUREMENT-64
This Bugzilla ticket lines out the problem for a downstream Eclipse project (SmartHome) wanting to use JSR 363:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=434006

There is no request to add JSR 354 to Orbit at this point, but several business-related projects like Scout may benefit from it quite a lot.

This would require a change in the LICENSE file of both APIs, thus it is impossible to "just throw it in", if done, it must be under a MR.






[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-156] Bootstrap should not sort in getService() Created: 04/Oct/15  Updated: 04/Jun/16

Status: Open
Project: javamoney
Component/s: API
Affects Version/s: 1.0
Fix Version/s: 1.1.1

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

Tags: bootstrap, spi

 Description   

The SPI class Bootstrap currently sorts services by simple name when getService() is called. This is unnecessary, if any sorting was done, the implementation of ServiceProvider would take care of it.
Thus simply calling ServiceProvider.getService() should be enough.






Ensure, RI-BP is in sync (JAVAMONEY-124)

[JAVAMONEY-158] Ensure JApiCmp reports are comparable for Moneta and Moneta-BP Created: 18/Jan/16  Updated: 17/Nov/16

Status: Open
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.1
Fix Version/s: 1.2

Type: Sub-task Priority: Major
Reporter: keilw Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to JAVAMONEY-148 Analyze Dependencies Resolved
Tags: design

 Description   

Using JApiCmp we have to ensure, the reports (including non-critical info or warning e.g. for added methods, etc.) are comparable or identical for Moneta and Moneta-BP.



 Comments   
Comment by stokito [ 07/Sep/16 ]

For those who didn't know what is JApiCmp (like me minute ago)
japicmp is a tool to compare two versions of a jar archive:
https://siom79.github.io/japicmp/
https://github.com/siom79/japicmp





[JAVAMONEY-160] equal can return false for the same CurrencyUnits Created: 19/Feb/16  Updated: 05/Jun/16

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

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


 Description   

I have one currency unit created from jackson-datatype-money deserialization and the other one from Monetary.getCurrency(locale). Both refer to USD but when I try to compare them using equal I get false.

This behavior is very surprising. The reason for this was that one MonetaryUnit was a BuildableCurrencyUnit and the other one was a JDKCurrencyAdapter and their equals implementations are not symmetrical.

JDKCurrencyAdapter has
if (obj instanceof CurrencyUnit) { ...

BuildableCurrencyUnit has
if (obj instanceof BuildableCurrencyUnit) { ...
this is wrong and it should be implemented as in JDKCurrencyAdapter



 Comments   
Comment by keilw [ 19/Feb/16 ]

Interesting, we may have a look into it (given both RIs are currently working on a maintenance pack it sounds like good timing) but keep in mind, e.g. Java's own Integer and BigInteger both created with the same value 1, 2 or any number never return true on equals() either. So it could be a "works as Java intended" case, but if there's a domain specific deviation we may accomplish here we'll give it a try.

Comment by tommy_ludwig [ 16/Mar/16 ]

I also have run into this problem comparing MonetaryAmount objects deserialized from JSON using jackson-datatype-money with ones instantiated using Money.of(number, currency). You can see a demonstration of this in JUnit tests in this gist. I understand the precedent of the Number classes, but two Money objects being compared should not return different values depending on the order of the equality check. The equals method states that it should be symmetric.

I think it is mostly a problem of usability and consistency. There are workarounds (Money#compareTo), but they make things a bit ugly and it is just too easy to use "the wrong thing" (in this case equals). Money#isEqualTo works if you know the currencies are the same or are okay handling the MonetaryException in case of mismatched currencies, but I don't know that and want to compare equality in a stream.

Comment by keilw [ 04/Jun/16 ]

@tommy_ludwig Please add a separate ticket for equals() and instances of MonetaryAmount we can't abuse this one for other classes or types. thanks.

Comment by keilw [ 04/Jun/16 ]

Seems this could also be related: https://github.com/JavaMoney/jsr354-ri/pull/134

Comment by tommy_ludwig [ 05/Jun/16 ]

@keilw I think that pull request may fix all of the mentioned problems, which I believe have the root cause mentioned in the description of this issue. My comment was adding more background/use cases that might run into this problem. I will be glad to test my use case once the pull request has been merged. If I find remaining/additional problems after that pull request change, I'll be sure to open new tickets. Thank you for looking into this.





[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-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-166] MonetaryAmountFormat should expose regular expression that will match the format Created: 19/Oct/16  Updated: 13/Nov/16

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

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


 Description   

It would be cool if a MonetaryAmountFormat exposed a regular expression that'd allow clients to verify a potential input value for MAF.format(…).

The concrete use case is that a REST API might want to support Locale specific representations based on an Accept-Language header present in the request. The Locale derived from that can be used to obtain the corresponding format. However, if you'd like to expose e.g. a JSON schema for the based on that header, there's currently no way to obtain that format from the MonetaryAmountFormat.



 Comments   
Comment by keilw [ 19/Oct/16 ]

Sounds interesting, but an API change can't be done without at least a MR1.

There is at least one other issue similar to https://github.com/jsr107/jsr107spec/issues/333 (recently solved by JSR 107, still pending a MR, but the Spec Leads agreed on doing it) which a MR of JSR 354 could help solve.

It looks like Credit Suisse hasn't had much luck finding a Maintenance Lead, so any change to the API or license could be problematic.
I don't suppose VMware (Pivotal is not a JCP member, but Oliver represented VMware in JPA 2.1 and a colleague was in the JBatch EG) or a successor as JCP Member would consider helping with that, e,g. as Co Maintenance Lead? (either with CS, Trivadis or both)

Comment by Oliver Gierke [ 21/Oct/16 ]

Actually I thought about suggesting it for the reference implementation first, but I couldn't find a tracker to file issues for that on the GitHub repository.

Comment by otaviojava [ 12/Nov/16 ]

Hello Oliver.

What do you think of MonetaryAmountDecimalFormatBuilder class?
Is that enough to you?
https://github.com/JavaMoney/jsr354-ri/blob/master/moneta-core/src/main/java/org/javamoney/moneta/format/MonetaryAmountDecimalFormatBuilder.java
https://github.com/JavaMoney/jsr354-ri/blob/master/moneta-core/src/test/java/org/javamoney/moneta/format/MonetaryAmountDecimalFormatBuilderTest.java

Comment by otaviojava [ 13/Nov/16 ]

I created this PR: https://github.com/JavaMoney/jsr354-ri/pull/139

Comment by Oliver Gierke [ 13/Nov/16 ]

That's a nice start but it lacks two important things: it's not a regular expression (so it's not universally useful) and it doesn't include the currency.

Comment by otaviojava [ 13/Nov/16 ]

Oliver once it's a DecimalFormat's wrapper.
We can use currency any way with ¤ (\u00A4)

Ref: https://docs.oracle.com/javase/8/docs/api/java/text/DecimalFormat.html

Comment by Oliver Gierke [ 13/Nov/16 ]

Well, I don't think that takes the concrete setup (symbol VS three-digit code) into account. I think the ideal way'd be to just expose a real regular expression rather than letting the client doing some arbitrary post processing. A `DecimalFormat` pattern would be useful if I wanted to do some formatting on my own but that's not what I want to do and actually what the formatting API already does OOTB.





[JAVAMONEY-104] Make coverage visible on all key artifacts Created: 13/May/15  Updated: 04/Jun/16

Status: Open
Project: javamoney
Component/s: API, General: Build and quality management, Impl: RI, Test: TCK
Affects Version/s: 1.0
Fix Version/s: 1.0.1, 1.2

Type: Task Priority: Minor
Reporter: keilw Assignee: atsticks
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
Relates
relates to JAVAMONEY-135 Ensure Unit Test coverage and results... Reopened
Tags: coverage, test

 Description   

Considerable effort was spent on increasing code coverage recently. Similar to the public API: https://github.com/JavaMoney/jsr354-api (showing 76% that's not bad, unless you're into safety critical software even corporate projects often don't insist on more than 60 or 70%) its BP and all other major artifacts (RI+RI-BP as well as TCK where applicable) should present theirs, too. API-BP has a badge, but no Coveralls profile seems to exist. Where missing, those should be created.






[JAVAMONEY-106] Clarify and document RI on JavaMoney page Created: 13/May/15  Updated: 04/Jun/16

Status: In Progress
Project: javamoney
Component/s: General: Build and quality management, Impl: RI
Affects Version/s: 1.0
Fix Version/s: 1.2

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

Tags: documentation, website

 Description   

While jcp.org will provide download links to official releases, many people likely will either use Maven settings or visit JavaMoney.org.

There http://javamoney.github.io/ri.html RI/Moneta is still presented as "1.0-RC1" and there's no clarification about 2 flavors of the RI for Java SE 8 or above and the still more widely expected one running SE 6/7, Android or Java ME.

This should be clarified and explained in the Readme.



 Comments   
Comment by keilw [ 08/Feb/16 ]

There's a need to update this page whenever 1.(0.)1 goes live.





[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






[JAVAMONEY-146] RoundedMoney not immutable Created: 27/Aug/15  Updated: 17/Nov/16

Status: Reopened
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
Fix Version/s: 1.2

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

Tags: test

 Description   

There's a warning by the TCK seemingly since 1.0 about RoundedMoney not being immutable:

Warning: found non immutable MonetaryAmountType: org.javamoney.moneta.RoundedMoney, details: 
Expected: org.javamoney.moneta.RoundedMoney to be IMMUTABLE
     but: org.javamoney.moneta.RoundedMoney is actually NOT_IMMUTABLE
    Reasons:
        Field can have an abstract type (javax.money.MonetaryRounding) assigned to it. [Field: rounding, Class: org.javamoney.moneta.RoundedMoney]
        The 'this' reference is passed outwith the constructor. [Class: org.javamoney.moneta.RoundedMoney]
        The 'this' reference is passed outwith the constructor. [Class: org.javamoney.moneta.RoundedMoney]
        The 'this' reference is passed outwith the constructor. [Class: org.javamoney.moneta.RoundedMoney]
        The 'this' reference is passed outwith the constructor. [Class: org.javamoney.moneta.RoundedMoney]
    Allowed reasons:
        Field can have an abstract type (javax.money.CurrencyUnit) assigned to it. [Field: currency, Class: org.javamoney.moneta.RoundedMoney]
        Field can have an abstract type (javax.money.CurrencyUnit) assigned to it. [Field: currency, Class: org.javamoney.moneta.RoundedMoney]
        Field can have an abstract type (javax.money.MonetaryOperator) assigned to it. [Field: rounding, Class: org.javamoney.moneta.RoundedMoney]

Is there a reason for it being not immutable, or can this be addressed?



 Comments   
Comment by otaviojava [ 27/Aug/15 ]

It's talking of the Monetary Operator that could be a mutable type, it's looking just to the interface.
But don't worry, the implementations are immutables and I checked again the RoundedMoney. It's immutable.

Comment by keilw [ 28/Aug/15 ]

The message refers to other issues, especially this used outside the constructor of RoundedMoney in places the add() method:

MoneyUtils.checkAmountParameter(amount, this.currency);

Let's fix it so hopefully all warnings go away.

Comment by otaviojava [ 28/Aug/15 ]

Thanks Werner by the information.
I am looking it so or do you are fixing it?





[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-154] NumberValue.getNumberType() should return a type that extends Number. Created: 25/Sep/15  Updated: 23/Nov/16

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

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


 Description   

See PR #52 on Github

NumberValue.getNumberType() should provide an explicit guarantee that
the type returned extends Number. So it should be:

public abstract Class<? extends Number> getNumberType();

instead of

public abstract Class<?> getNumberType();


 Comments   
Comment by otaviojava [ 27/Sep/15 ]

I totally agree with you, I did this suggestion the problem is: We cannot change the API, because it is in final release. To change it we need to either create a maintenance JSR or create a new JSR to update a JAR (1.0.1).
But it absolutely gonna to 1.0.1 version.

Comment by keilw [ 27/Sep/15 ]

No at most 1.1, which could be a MR1. The API must not be changed on the fly without an actual MR.

Comment by otaviojava [ 27/Sep/15 ]

Werner, do you mind explain more what is MR?

Comment by keilw [ 27/Sep/15 ]

Maintenance Release. Guess you haven't represented SouJava in the EC that long to vote on one, did you?

Comment by otaviojava [ 27/Sep/15 ]

Yes, I did.
But I know how we can do it.

Comment by msgilligan [ 28/Sep/15 ]

I just noticed that the Spec says, in Section 4.2.3 "Externalizing the Numeric Value of an Amount":

getNumberType() provides information about the numeric representation used internally. It explicitly does not constrain the type returned to be a subtype of java.lang.Number to allow alternate implementations to be used.

So I think that means that this issue should be closed as "won't fix".

(Although it sure would be handy if every NumberValue could return a standard type and with arbitrary-precision types available I don't see that it would be too difficult of a requirement.)

Comment by msgilligan [ 23/Nov/16 ]

As I mentioned above, the spec says:

It explicitly does not constrain the type returned to be a subtype of java.lang.Number to allow alternate implementations to be used.

I think this issue can be closed as won't fix.





[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





Generated at Sun Mar 26 10:43:02 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.