[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: 12/Jul/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: 0
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.





[JAVAMONEY-162] ServiceLoader fail in Servlet Container Tomcat Created: 17/Jun/16  Updated: 18/Jun/16  Resolved: 18/Jun/16

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: LeoLux Assignee: Unassigned
Resolution: Works as designed Votes: 0
Labels: ServletContainer
Remaining Estimate: 4 days
Time Spent: Not Specified
Original Estimate: 4 days
Environment:

Servlet Container Apache Tomcat/8.0.24 on Windows 10.
Put the following jars into apache-tomcat-8.0.24\lib directory:

  • money-api-1.0.1.jar
  • moneta-1.1.jar

Tags: Bootstrap, DefaultMonetaryCurrenciesSingletonSpi, SPI, ServiceLoader

 Description   

Both libraries for the API (1.0.1) and the implementation (1.1) are present in the lib directory of a tomcat 8.0.24. My web application makes use of the these libraries in the provided scope and it is running fine until the runtime hits this the first API call which is "Monetary.getCurrency("EUR")". It produces the following error:

java.util.ServiceConfigurationError: javax.money.spi.MonetaryCurrenciesSingletonSpi: Provider org.javamoney.moneta.internal.DefaultMonetaryCurrenciesSingletonSpi not a subtype
at java.util.ServiceLoader.fail(ServiceLoader.java:239)
at java.util.ServiceLoader.access$300(ServiceLoader.java:185)
at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:376)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
at org.javamoney.moneta.internal.PriorityAwareServiceProvider.loadServices(PriorityAwareServiceProvider.java:98)
at org.javamoney.moneta.internal.PriorityAwareServiceProvider.getServices(PriorityAwareServiceProvider.java:65)
at javax.money.spi.Bootstrap.getService(Bootstrap.java:115)
at javax.money.Monetary.loadMonetaryCurrenciesSingletonSpi(Monetary.java:100)
at javax.money.Monetary.<clinit>(Monetary.java:44)
at my.util.MoneyUtil.<clinit>(MoneyUtil.java:15)



 Comments   
Comment by keilw [ 17/Jun/16 ]

Did the same work with API and RI 1.0 or did you first try it now?

Comment by LeoLux [ 17/Jun/16 ]

I first tried it now. Should I try with RI 1.0?
It works if I remove the libraries from the tomcat folder and deploy them with the webapp (just for a test). But in my case the jars should not be part of the .war files.

Comment by keilw [ 17/Jun/16 ]

Yes that would help to see, if the problem existed in 1.0 or was recently introduced as a side-effect?

Comment by LeoLux [ 18/Jun/16 ]

It turns out that I had a mistake in my setup: I deployed the libraries in the war file AND in tomcat/lib because the web application depends on a common project which exports the libraries unexpectatly. When I remove the libraries from the common project everything works as expected. However, with the correct setup I tested again with both 1.0+1.0 and 1.0.1+1.1 without any issues. So the issue only occurs when the libraries are deployed redundantly in the Servlet Container.

Since the cause of the error is related to the classpath the issue can be closed.

Comment by keilw [ 18/Jun/16 ]

Thanks, Having more than one implementation of a JSR or other API often causes great trubles.
I helped solving a similar problem with different JSF implementations in a client's app once through classpath isolation.
Hopefully with true modularization from Java SE 9 on this might improve. Otherwise OSGi can help, but it's not an issue specific to this JSR.
Will close it.





[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-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-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 Open keilw  
JAVAMONEY-139 Format Module Sub-task Resolved  
JAVAMONEY-140 Convert Module Sub-task Open keilw  
JAVAMONEY-141 Pass TCK Sub-task Resolved keilw  
JAVAMONEY-148 Analyze Dependencies Sub-task Open 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-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.






[JAVAMONEY-103] Create JEP for Java 10+ Created: 12/May/15  Updated: 04/Jun/16

Status: Open
Project: javamoney
Component/s: API, Impl: RI, Misc: JCP Administration
Affects Version/s: 1.0, 1.1
Fix Version/s: 2.x

Type: Task 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:
Cloners
clones JAVAMONEY-73 Create JEP for Java 9+ Closed
Tags: java10, jdk

 Description   

As discussed, it seems like a good idea to have an OpenJDK committer file a JEP for monetary improvements in a future Java version. Whether that's 10 or later should be determined by Oracle and the OpenJDK program. but without filing it, that's never going to happen.






[JAVAMONEY-124] Ensure, RI-BP is in sync Created: 18/May/15  Updated: 04/Jun/16  Resolved: 04/Jun/16

Status: Resolved
Project: javamoney
Component/s: Impl: RI, Library: JavaMoney Extensions
Affects Version/s: 1.1
Fix Version/s: 1.1

Type: Task Priority: Critical
Reporter: keilw Assignee: keilw
Resolution: Fixed 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-126 Remove MonetaryRoundedFactory unless ... Sub-task Closed  
JAVAMONEY-127 Remove HistoricConversionQueryBuilder... Sub-task Resolved  
JAVAMONEY-129 Add ofMinor to all affected *Money c... Sub-task Resolved otaviojava  
JAVAMONEY-130 Remove ExchangeRateException Sub-task Resolved keilw  
JAVAMONEY-133 Align naming of RI and RI-BP elements Sub-task Resolved otaviojava  
JAVAMONEY-134 Apply SigTest to ensure, Moneta and M... Sub-task Resolved keilw  
JAVAMONEY-135 Ensure Unit Test coverage and results... Sub-task Reopened otaviojava  
JAVAMONEY-145 TCK Tests fail in Moneta which pass M... Sub-task Resolved otaviojava  
JAVAMONEY-158 Ensure JApiCmp reports are comparable... Sub-task Open  
Tags: backport, design

 Description   

There's a significant number of elements like
HistoricConversionQueryBuilder, MonetaryRoundedFactory, etc. all recently added to Moneta without a proper BP equivalent.

Nothing should be in the (Java SE 8) RI that does not exist in the BP either. Especially some "API like" elements along the lines of MonetaryRoundedFactory should probably best go to a module of javamoney-lib instead.






[JAVAMONEY-136] Broken compatibility with 1.0 Created: 23/Jun/15  Updated: 04/Jun/16  Resolved: 04/Jun/16

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

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

Issue Links:
Blocks
is blocked by JAVAMONEY-152 Explore API consistency tools like Re... Resolved
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-417 javadoc since annotations missing Closed

 Description   

I did a clirr report comparing with 1.0 of the RI: The findings are as follows:

Method 'public javax.money.MonetaryQuery majorUnits()' was removed from org.javamoney.moneta.function.MonetaryOperators
Method 'public javax.money.MonetaryQuery minorUnits()' was removed from org.javamoney.moneta.function.MonetaryOperators

These two methods must be readded (we can deprecate them with links to the new locations on MonetaryQueries).

Maybe acceptable are:

org.javamoney.moneta.internal.convert.AbstractECBRateProvider isnt anymore a superclass of	org.javamoney.moneta.internal.convert.ECBCurrentRateProvider	
org.javamoney.moneta.internal.convert.AbstractECBRateProvider isnt anymore a superclass of		org.javamoney.moneta.internal.convert.ECBHistoric90RateProvider	
org.javamoney.moneta.internal.convert.AbstractECBRateProvider isnt anymore a superclass of	org.javamoney.moneta.internal.convert.ECBHistoricRateProvider


 Comments   
Comment by keilw [ 23/Jun/15 ]

As this was only run against Moneta-BP (SE 8 breaks the tool ) please ensure, to keep both in sync when fixing.

Comment by otaviojava [ 06/Jul/15 ]

Resolved on:
https://github.com/JavaMoney/jsr354-ri/pull/117
https://github.com/JavaMoney/jsr354-ri-bp/pull/18

Comment by keilw [ 06/Jul/15 ]

Was the clirr report run again where possible?

Comment by keilw [ 11/Sep/15 ]

Entire MonetaryUtil was deleted without warning or deprecation. It breaks compatibility with Moneta 1.0, so we have to bring it back even if @deprecated.

Comment by keilw [ 11/Sep/15 ]

Refers to Clirr or JDiff, too.

Comment by otaviojava [ 04/Nov/15 ]

`MonetaryUtil` returned as @deprecated.

Comment by keilw [ 04/Nov/15 ]

It's OK to deprecate one class as long as it remains there for some time (see Oracle's plans for deprecation in Java 9, we might use that at a later point like "supercedes", etc. )

Comment by keilw [ 02/Dec/15 ]

As of now, revapi Maven plugin looks like it may have issues prior to Java 8. Hence both builds are broken.
Aside from configuration and customization of revapi to gracefully ignore some of its errors, we may have to look into Travis-CI build-triggers: https://docs.travis-ci.com/user/triggering-builds/
As the only way to run revapi after a Java 7 based build job could be via such trigger.

Comment by keilw [ 04/Jun/16 ]

Hopefully resolved. If there's any TCK problem with 1.1 we'd have to reopen





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-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 Open
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-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-146] RoundedMoney not immutable Created: 27/Aug/15  Updated: 04/Jun/16

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

Type: Improvement Priority: Major
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?





Make Moneta Modular (JAVAMONEY-137)

[JAVAMONEY-148] Analyze Dependencies Created: 27/Aug/15  Updated: 04/Jun/16

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

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

Tags: dependencies, dependency

 Description   

To verify progress of the modularized code and compare it to the monolithic version, one or several dependency analysis tools shall be applied like:






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: 04/Jun/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

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.






[JAVAMONEY-159] API-BP 1.0 built with Java 8 Created: 07/Feb/16  Updated: 10/Mar/16  Resolved: 10/Mar/16

Status: Resolved
Project: javamoney
Component/s: API
Affects Version/s: 1.0
Fix Version/s: 1.0.1

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

Tags: compiler, java7, java8

 Description   

Testing the proposed Moneta-BP 1.1 against a genuine Java 7 setup, it turned out, Money-API-BP 1.0 JAR deployed to MavenCentral is incompatible with Java 7 or before as it was compiled with Java 8, too.

Manifest-Version: 1.0
Bnd-LastModified: 1431977045490
Build-Jdk: 1.8.0
Built-By: Anatole
...

Causing a Java SE 7 console app to fail:

Exception in thread "main" java.lang.UnsupportedClassVersionError: javax/money/MonetaryAmount : Unsupported major.minor version 52.0
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2625)
	at java.lang.Class.getMethod0(Class.java:2866)
	at java.lang.Class.getMethod(Class.java:1676)
	at sun.launcher.LauncherHelper.getMainMethod(LauncherHelper.java:494)
	at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:486)


 Comments   
Comment by keilw [ 07/Feb/16 ]

Seems there's a way to get the console app working in SE 7, but two different JARs exist for Moneta-BP, one (on JCenter/Bintray) compiled with Java 7, the other one against Java 8. That alone should be cleaned up as soon as possible.

Comment by otaviojava [ 08/Feb/16 ]

Werner, just compile the new version with Java 7,

Comment by keilw [ 08/Feb/16 ]

That does not solve above problem. The Binary JARs were built with different JDKs, something that can only be solved with a whole new delivery of the API to (one of) those repositories.

Comment by keilw [ 10/Mar/16 ]

OpenJDK at least under Travis-SI seems rather buggy and unstable
See https://github.com/travis-ci/travis-ci/issues/5227 The money-api-bp build faced exactly the same BufferOverflow problems. Now running OracleJDK7 it works again.





[JAVAMONEY-125] Add missing tests Created: 27/May/15  Updated: 09/Feb/16

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

Type: Improvement Priority: Minor
Reporter: znurgl 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-142 Define some tests as "integration-test" Open
is related to JAVAMONEY-104 Make coverage visible on all key arti... Open

 Description   

Test coverage is 76% at the moment. It needs to make sure every function has its test.



 Comments   
Comment by keilw [ 09/Feb/16 ]

This also applies to RIs, but the 76% refers to the API code coverage.





[JAVAMONEY-157] Moneta-BP should use JIRA (in POM) Created: 19/Nov/15  Updated: 07/Feb/16  Resolved: 07/Feb/16

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
Fix Version/s: 1.1

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

Tags: Maven, website

 Description   

Right now, jsr-354-ri-bp in the POM file states

<issueManagement>
		<system>GITHUB</system>
		<url>https://github.com/JavaMoney/javamoney-moneta-bp/issues</url>
	</issueManagement>

That was from a time, when it was assumed to be a separate backport independent of the RI. Not only is the URL wrong/old, it should simply point to this JIRA as it does for Moneta:

<issueManagement>
		<system>JIRA</system>
		<url>http://java.net/jira/browse/JAVAMONEY</url>
	</issueManagement>





[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-151] Does the asType method on RoundedMoney make sense? Created: 28/Aug/15  Updated: 18/Jan/16  Resolved: 18/Jan/16

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

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

Tags: api, design, format

 Description   

Looking to RoundedMoney class there is a method: asType.
This method isn't of interface and nobody on RI is using this method.



 Comments   
Comment by keilw [ 28/Aug/15 ]

Given the comment

   /*
     * }(non-Javadoc)
     * @see javax.money.MonetaryAmount#asType(java.lang.Class, javax.money.Rounding)
     */

it looks like an older API method. So probably a leftover.

The correct way to do this nevertheless is to mark the method as @deprecated now, remove the misleading JavaDoc reference. And remove it from a future version (possibly 1.0.2 already).
It is a public method of a public class. Apps or even other frameworks using Moneta might be calling it (just look at the "sun.misc.Unsafe" tragedy )

Comment by otaviojava [ 28/Aug/15 ]

Yeah.
I believe the version 1.0.2 will the modularized and cleaner version.

Comment by keilw [ 28/Aug/15 ]

Sure, the point is except for an obvious typo (strictly speaking you'd have to keep the wrong version @deprecated there, too ) we should not rename or delete public methods in API (there it's a NO-GO anyway) or RI.

tck-examples I recently stumbled over one package being called "text" instead of "test", but that is an example or blueprint, not a reusable piece of code, so fixing it there is fairly unproblematic. You call it from the outside via Maven anyway.





[JAVAMONEY-149] Why pseudo-API in the RI? Created: 28/Aug/15  Updated: 18/Jan/16  Resolved: 18/Jan/16

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

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

Issue Links:
Blocks
is blocked by JAVAMONEY-150 Mutability of MonetaryAmountSymbols Resolved
Tags: api, design, format

 Description   

As we were pushed to this package because it currently breaks in Moneta-BP, a valid question must be raised, if pseudo-API by extending (not implementing) an API interface in the RI is desired at this stage.
MonetaryAmountFormatSymbols extends MonetaryFormat referring to a (highly mutable but there's going to be another issue for that) class MonetaryAmountSymbols.

Actual demand for it has to be revisited and (like a proper JSR) possibly just added as feature request for a future version of the API.



 Comments   
Comment by otaviojava [ 28/Aug/15 ]

This guy is from stackoverflow and money list.
On this way the design put a pseudo-design, I will working to fix it.

Comment by keilw [ 28/Aug/15 ]

Could you quote the stackoverflow link here please?

Comment by otaviojava [ 18/Jan/16 ]

These class was removed.





[JAVAMONEY-150] Mutability of MonetaryAmountSymbols Created: 28/Aug/15  Updated: 18/Jan/16  Resolved: 18/Jan/16

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

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

Issue Links:
Blocks
blocks JAVAMONEY-149 Why pseudo-API in the RI? Resolved
Tags: builder, design, format, patterns

 Description   

The class MonetaryAmountSymbols while declared final is extremely mutable. It simply wraps around a (also mutable, but as far back as Java 1 or 2 this was not seen as an issue then) JDK class.

With many "old" JDK classes getting "new" Builder extensions these days, it is highly recommended to revisit the design (aside from the overall need and purpose) of this class and related elements.



 Comments   
Comment by otaviojava [ 28/Aug/15 ]

You are right, I will put a new design working with mutable way.

Comment by otaviojava [ 18/Jan/16 ]

This class does not exist anymore.





Make Moneta Modular (JAVAMONEY-137)

[JAVAMONEY-140] Convert Module Created: 16/Jul/15  Updated: 18/Jan/16

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

Type: Sub-task 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:
Related
is related to JAVAMONEY-141 Pass TCK Resolved

 Comments   
Comment by keilw [ 28/Jul/15 ]

Something went wrong here recently
A lot of good changes were "merged away" somehow. And convert-related classes in core again.
Need to fix otherwise true modularization won't work.

Comment by otaviojava [ 28/Jul/15 ]

@keliw
All changes proposed to modularization by public list was made and the TCK passed.
I believe it`s ok.

Comment by keilw [ 28/Jul/15 ]

No, the proposal was not about creating some rudimentary conversion providers, it was about true modularization of the conversion sub-system.
And "moneta" contains stuff that does not belong there.

Comment by keilw [ 28/Jul/15 ]

The mailing list was clear about

moneta-core (primarily root package, spi, loader and likely functional package which is also reused)
moneta-convert
moneta-convert-ecb
moneta-convert-imf
moneta-format

And moneta-convert did not mean just an "umbrella" POM, it means everything that lies under "moneta.internal.convert" and similar packages with dependency to javax.money.convert

Sorry for possible misconception, but that is true modularization, not just cutting a few pieces out.

Comment by otaviojava [ 28/Jul/15 ]

Please, check again.
There isn't this on email list.
There is a picture about it.
The main goal of this issue is split the exchange-rate.
I know it because I send the email and create the proposal.

Comment by keilw [ 28/Jul/15 ]

That was exactly from the mailing list.
And modularization means more than this. There will be more (even for too bloated parts like java.time, they might be thrown into some giant "core") of that in Jigsaw, and the aim was to create a jigsaw capable fully modular convert, meaning no dependency to javax.money.convert in core, allowing the conversion as a whole to be optional. Everything else makes no sense and would require to do it all again.

Comment by otaviojava [ 28/Jul/15 ]

Werner, this proposal was sent as first step.
If you want do this, please create a new proposal with these modification.

Comment by keilw [ 28/Jul/15 ]

Btw. this is wrong (also have chance to fix it) initializing a mandatory variable in a separate @Test

    @Test
    public void init() {
        provider = new ExchangeRateProviderMock();
    }

JUnit or TestNG don't guarantee in what order tests are executed, they may happen on separate threads in parallel which would cause NPEs.
Will move it to @Before or similar to fix this.

Comment by otaviojava [ 28/Jul/15 ]

Thanks, but don't worry I did it.

Comment by keilw [ 28/Jul/15 ]

Please do not commit to that branch while I'm fixing it

Comment by keilw [ 28/Jul/15 ]

The TCK gave errors because of circular dependencies e.g. the moneta "JAR" module defining convert stuff while then using convert again. Only one of the biggest problems.

Comment by otaviojava [ 28/Jul/15 ]

Werner, again
Don't commit in this branch, please, create own branch with your proposal.
There isn't circular dependency.

Comment by keilw [ 28/Jul/15 ]

The proper branch already exists. with clean modularization.
Tests in some "core" module show clearly they refer to ECBconversion or IMFConversion. As soon as dependencies are clarified and resolved these show what was wrong.

Last but not least each module must be an OSGi bundle, otherwise they are worthless for Jigsaw when it comes (there are already bridging projects, so a proper OSGi bundle will work as proper Jigsaw module, too)

Comment by otaviojava [ 28/Jul/15 ]

You can create a new branch using this branch as base.
To do this you can use the command:

git chechout -b new_branch
Comment by keilw [ 28/Jul/15 ]

long done

But the 2 branches must not build into the same snapshot, this way the dependencies are mixed up on JFrog

Comment by keilw [ 01/Aug/15 ]

@otavio your concerns about ECB or IMF may have good intentions, but they are without reason. These organizations bail out entire countries. Should Brazil due to current economic crisis go bankrupt like its neighbor Argentinia did before, the IMF will help them. Apache Foundation, Eclipse Foundation, Linux Foundation or even Oracle's Open Source efforts like OpenJDK are NGOs funded by a few big corporate donors (often to save taxes at least in the US ) Being ApacheCon speaker again this year, there similar to EclipseCon these NGOs report transparently on their budget, but usually we're talking in the range of 1 Mio. $ or a 7 digit amount at most. That's less than the interest IMF or ECB gets by large "problem children" like Greece each month!

They normally do this as transparent as possible. And public APIs like the ones we consume are part of that transparency. So it's in their DNA and highest interest to provide them. Occasional hacks by the likes of Anonymous, well, everyone who is exposed gets these today, even the White House or Pentagon.

Glassfish was practically disintegrated by Oracle, so the amount of donation both time and money by a few or just one big corporate donor is much more volatile than either of these economic institutions. Larry alone could pull the plug on OpenJDK at any time if he wanted, but there is not a single country that could destroy or stop the IMF, neither Greece nor the USA, though they probably have a certain stake bigger than others

Comment by otaviojava [ 01/Aug/15 ]

Werner, the proposal of one service be working. I know, but its not change the fact of we cannot provide the support to their service.

Comment by otaviojava [ 01/Aug/15 ]

Just moving this argument to here. once I believe it's important:

Werner.
Maybe you did a little confusion with physical module with logical module.

Example:
The Swing module is together physically, in the same folder (java.desktop), but on different logical module, in different package.

If you look to swing module, all classes are on the same physical module:

But we have different packages, in other words, different logical module:

  • javax.swing.border
  • javax.swing.colorchooser

The same thing will happen with javax.money, it stay together, all core, just there is logic module, it will split by package.
The initial proposal to split the core to the exchange rate is because neither we and OpenJDK team can't provide, support, ensure availability, perform maintenance, etc. on third service such IMF or ECB service.
So we will propose just the core to him, following the openjdk standard, using logical modules, in other words, just the core modularized by packages.

Referencies:

Comment by keilw [ 01/Aug/15 ]

Yes, so our "java.desktop" in Moneta is "moneta.convert". Which consists of

  • org.javamoney.moneta.convert
  • org.javamoney.moneta.internal.convert
  • org.javamoney.moneta.convert.ecb
  • org.javamoney.moneta.convert.imf

Plus a few classes e.g. in "spi" that in the near future should be moved to a proper package (since packages also allow version control like OSGi bundles if Jigsaw becomes usable reality)

like "java.desktop" can be used or not in Java 9, the whole conversion can be either used or left away.
In fact, since java.desktop also has AWT under the hood, moneta-convert is much more like AWT and the providers similar to Swing on top of that.
Oracle may not offer them separately in Java 9 because the number of pure AWT apps is too small or they just want people to use either Swing or JavaFX, but Swing is an extention to AWT and could be left out while pure "native" AWT apps would still run without it.

So the properly modularized branch does exactly what you mention, it offers 2 logical modules

  • core
  • convert
    Where the latter comes with sub-modules or built-in extensions, which in a future (not before Java 10 as it seems) version some of them could be optional.

As Anatole said, having absolutely none will not make sense, but users may chose between those two or others if we come across viable (Free and offered by an accepted global institution like IMF or ECB) alternatives by then. Maybe the "BRICS" countries do come up with their own system, but until that even provices an API I guess we'd at least see Java 9 Final or even 10

Comment by otaviojava [ 01/Aug/15 ]

Werner,
The logical module happen on split by package, qualified.
If we are submit with this dependency, include the exchange rate provider. The code is already done to it on the master.
I just doubt strongly the Java SE team will accept the implementation whose need internet and third service.

Comment by keilw [ 01/Aug/15 ]

The fully modulariized branch (based on the one you started ) https://github.com/JavaMoney/jsr354-ri/tree/properly_modularized_moneta has moneta-core without a single reference to javax.money.convert.
At least all Money types and their toString() helper refers to javax.money.format, thus it makes less sense to offer that as a module right now. Formatting while there are local specialties (e.g. Indian Cr. or Lkh JavaMoney DOES take care of, while OpenJDK still fails them ) rarely depends on regular updates like conversion. And if conversion was optional on the API level iit might even make it easier for persistent business-denying libraries like JodaMoney to implement JSR 354
JodaTime and JSR 310 are equaly business-denying since they lack basic features like a holiday calendar, something ICU4J got for ages...
This might require occasional updates from the internet, but hey, JodaTime offers updates almost every month for some TZ cosmetics or bug fixes

Comment by otaviojava [ 01/Aug/15 ]

Werner I mean, modularized looking to OpenJDK concert that I showed the code on last comment.
The OpenJDK does not use maven project.

Comment by keilw [ 01/Aug/15 ]

Otavio, I think while browsing the code of Java 9 you still don't get how Oracle aims to distribute and regularly update it .
Over the Internet

Should they have a problem with Convert as a whole, then making that modular and optional solves their problems even more or that of people who may be behind a strong, intrusive firewall (of course they would likely not even get the full Java 9 or 10 this way either )
Nobody bothered creating a JEP, so we talk about some Sci-fi possibility beyond Java 10 (if JEP isn't filed soon, it won't be 10 but 11 or 12!)
The feature branch for 1.0,1 is reality, and meets all requirements to be used either via a SP or at least MR (if Anatole and/or CS were to prefer that)

What's currently in master is broken and polluted anyway. The whole "Conversion Operator" stuff breaks proper modularity, that's why the properly modularized branch is the future and contains both, but cleanly separated into Core and Convert

Comment by keilw [ 01/Aug/15 ]

Gradle is Maven
They use exactly the same dependency mechanism and Mark Reinhold explicitely referred to Maven or MavenCentral, so do the specs for Jigsaw.
It must be compatible with Maven, Gradle and likely some even still use Ant/Ivy, so it's also using that.

Don't worry about Hg either, who knows what Java 10 or 11 will use by 2018 (that's the earliest a "jdk.money" module might be worth a thought from Oracle's perspective)

Comment by otaviojava [ 01/Aug/15 ]

Yes, you are right, we have no idea if the money go and when.
I believe, maybe, we just freeze this issue when it be really necessary.
Just stay the branch alive and rebasing with the master, when it and if be necessary will almost done. Do a code looking to speculation is not good.

Comment by keilw [ 01/Aug/15 ]

We don't have to release a 1.0.1 build any time soon either.
In fact, as it's no secret, Anatole is moving to a new company by the end of this month. And from an administrative point CS is the Spec Lead/Maintenance Lead, so unless there was a transition (similar to what Liferay just took over from Oracle with the Portlet Bridge ) or another company/individual joined as Co ML (that also happened, see Antoine with CDI before V2) we better wait till that is sorted out before even publishing a 1.0.1 version.
Unless there's a critical bug that would prevent users of 1.0 from doing their job.

For that the 1.0 branch is closest to the Final state and critical bug-fixes should be applied there or to a new branch off 1.0

Comment by otaviojava [ 01/Aug/15 ]

That's the point, we have stuff a lot on the master that include bug fixes, etc. I have more time to release the next version than Ubuntu, and Ubuntu is a S.O (the ubuntu release a version each six month).
I believe we need to run this process on parallel, mainly because we need to have a meeting with the OpenJDK team before. And just merge to master when necessary.
Make the monomodule stable is a really good stuff.





Make Moneta Modular (JAVAMONEY-137)

[JAVAMONEY-138] Core Module Created: 16/Jul/15  Updated: 18/Jan/16

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

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





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

[JAVAMONEY-134] Apply SigTest to ensure, Moneta and Moneta-BP match Created: 22/Jun/15  Updated: 18/Jan/16  Resolved: 18/Jan/16

Status: Resolved
Project: javamoney
Component/s: Impl: RI, Test: TCK
Affects Version/s: None
Fix Version/s: 1.1

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

Tags: test

 Description   

Similar to JSR 107 (https://github.com/jsr107/jsr107tck/tree/master/sigtest)
we must apply SigTest, even more important since we got 2 RIs, not just 1 like 107 or most other JSRs

See https://sigtest.java.net/sigtest_docs.html on how to use SigTest.



 Comments   
Comment by otaviojava [ 22/Jun/15 ]

Agree with you, but It could be on version 1.0.2, we need to close the version 1.0.1 on Moneta.

Comment by keilw [ 22/Jun/15 ]

They are totally inconsistent right now, and unless we are pushed onto an obvious mismatch like this recent bug (where are tests in both Moneta and BP to demonstrate it was fixed?) nobody really knows if they match or not.

Comment by otaviojava [ 22/Jun/15 ]

In this case of bug about the over configuration, as I told on the issue, was on line that was removed one test there, does not make sense to me.

Comment by keilw [ 22/Jun/15 ]

That does not spare us the need to ensure both RIs are in sync from an API/signature point of view.

Comment by otaviojava [ 22/Jun/15 ]

Could you read again my first comment?
I agreed with you, but we could use the iterative and incremental development software.

Comment by keilw [ 22/Jun/15 ]

This JSR is special, there is no JSR I recall with 2 functionally identical parallel RIs. Hence we need to take extra care to preserve their integrity and consistency.

Comment by keilw [ 18/Jan/16 ]

Seems a duplicate of the "broken compatibility" issue family.





[JAVAMONEY-152] Explore API consistency tools like Revapi and others Created: 11/Sep/15  Updated: 18/Jan/16  Resolved: 18/Jan/16

Status: Resolved
Project: javamoney
Component/s: API, Impl: RI
Affects Version/s: 1.1
Fix Version/s: 1.1

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

Issue Links:
Blocks
blocks JAVAMONEY-136 Broken compatibility with 1.0 Resolved
Tags: api, check, version

 Description   

While Clirr seems to have issues with some Java versions (8?) this tool that also refers to almost every major tool with a similar purpose looks like it's a bit more recent: http://revapi.org/

It also got a Maven plugin, so maybe it could work across the necessary environments more easily.



 Comments   
Comment by keilw [ 29/Dec/15 ]

JApiCmp is another tool which seems a bit more active and with more configuration options, exclude lists, etc.: https://siom79.github.io/japicmp/

Comment by keilw [ 18/Jan/16 ]

Seems done as we identified JAPICmp as best solution.





[JAVAMONEY-154] NumberValue.getNumberType() should return a type that extends Number. Created: 25/Sep/15  Updated: 28/Sep/15

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.)





[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-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.)





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

[JAVAMONEY-145] TCK Tests fail in Moneta which pass Moneta-BP Created: 23/Aug/15  Updated: 27/Aug/15  Resolved: 26/Aug/15

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

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

Tags: tck-red, test

 Description   

After recent changes primarily to Moneta, TCK fails in 42 cases, see https://travis-ci.org/JavaMoney/javamoney-tck-usage-example

The same tests agaisnts Moneta-BP 1.0.1 all pass:
https://travis-ci.org/JavaMoney/javamoney-tck-usage-example-bp

This is an absolute showstopper. Not a single test must fail, if necessary "improvements" rolled back, or applied in a compatible way to Moneta-BP without breaking any tests there.



 Comments   
Comment by otaviojava [ 24/Aug/15 ]

There are several problems on TCK:

  • The RI is on Java 8, but the TCK runs on Java 7.
  • The TCK depends of moneta-core
  • The exception talks about, class def not found exception of the class javax.money.convert.MonetaryConversions, that is on the API, and the project hasn't the money-api as dependency.
Comment by keilw [ 24/Aug/15 ]

The RI is on Java 7 and 8, please accept that once and for all. Regardless of PR or declaring Java 7 "End of Life" real users especially in the EE world will keep using Java 7 for at least another 5 to 10 years. And even if a possible new JSR was some day added to Java 10 or 11, the standalone version must then also support the "older" JSR e.g. 8 or 9

The TCK is built against Moneta-BP and Java 7 because there are 2 RIs (for 7 and 8) but only one TCK.
There is no dependency to moneta-core. dependencyManagement would allow to do this in future (in fact, against the modular 1.0.2 branch of Moneta if you run them, only 4 tests fail, not 42) but the current build on Travis compiles the TCK against Moneta-BP 1.0.1-SNAPSHOT, no core there.

The exception says Could not initialize class javax.money.convert.MonetaryConversions that means, the SPI there has a problem created by changes you made in Moneta.
While Moneta-BP works perfectly fine for the same test. So you have to find and fix what breaks conversion SPI in the Java 8 flavor or Moneta to ensure, they behave structurally identical (regardless of their internals)

Spring manages to do that, and since Spring is also among top users of JSR 354, we must not break compatibility by uncoordinated changes.

Comment by keilw [ 24/Aug/15 ]

Just look at
https://github.com/JavaMoney/jsr354-ri-bp/tree/master/src/main/java/org/javamoney/moneta/internal/convert
vs.
https://github.com/JavaMoney/jsr354-ri/tree/master/src/main/java/org/javamoney/moneta/internal/convert

There are at least 5 classes missing in Moneta-BP. Hence, the conversion part is structurally incompatible, which explains why the SPI of MonetaryConversions gets confused and TCK fails in this area. Either add everything correctly to the BP or those changes can't be accepted. They're simply BUGS if they break the TCK.

Comment by otaviojava [ 24/Aug/15 ]

I don't say: "We cannot support the BP", but in the fact there is a problem to put the target on Java 7.
When you put the source and the target to 1.7, the project just will support resources 1.7 or lesser. The resource that the RI uses is lambda, stream, predicate, filter, etc. many stuffs from 1.8. The 1.8 is greater than 1.7, so will not run.

If fixed, but how?

  • I created a new branch on jsr-354-tck, on the pom, I put target and source to 1.8, now resources from 1.8 can run very well, and I just put the RI dependency. Install locally, using the "mvn clean install" command.
  • Then I excuted the javamoney-tck-usage-example and ran very well.

If you want, I can push this new branch.

Comment by keilw [ 24/Aug/15 ]

Sorry but that's totally unnecessary.

The TCK builds against Java 7 and creates a JAR that executes against both Java 7 and 8.
That worked before and must continue to work like that for the entire lifecycle of JavaMoney 1.x (until some day there could be a new JSR)

This branch is useless. There is just one TCK.

The goal is to fix the RI by aligning both development strains, not "doctor the TCK".

Thanks

Comment by otaviojava [ 24/Aug/15 ]

I just find one way to just run a specific implementation. Could I just put the other implementations as "provided"?
This way, the tck runs very well too.
Like this, on jsr354-tck:

diff --git a/pom.xml b/pom.xml
index 907abca..78af29d 100644
--- a/pom.xml
+++ b/pom.xml
@@ -120,6 +120,7 @@
                                <groupId>org.javamoney</groupId>
                                <artifactId>moneta-bp</artifactId>
                                <version>${ri.version}</version>
+                               <scope>provided</scope>
                                <type>jar</type>
                        </dependency>
 
@@ -127,12 +128,14 @@
                                <groupId>org.javamoney.moneta</groupId>
                                <artifactId>moneta-core</artifactId>
                                <version>${ri.version}</version>
+                               <scope>provided</scope>
                        </dependency>
 
                        <dependency>
                                <groupId>org.javamoney</groupId>
                                <artifactId>moneta-core</artifactId>
                                <version>${ri.version}</version>
+                               <scope>provided</scope>
                        </dependency>
 

Comment by keilw [ 25/Aug/15 ]

Feel free to create a pull request against the tck project, but as running the same TCK against 1.0 artifacts, 1.0.1 or even 1.0.2 Snapshot shows, there is no need to rebuild the TCK once the JAR is available on JFrog.

In fact, I think entries like moneta-core were historic. Moneta-BP is just a single JAR and only at Runtime (in tck-usage-example*) it matters if you chose a JAR or POM for it.

Comment by otaviojava [ 25/Aug/15 ]

I can't create remote branch, I haven't authorization to create remote branch anymore.

Comment by keilw [ 25/Aug/15 ]

No freaking branch please, that's why TCK was better protected (it is also the Spec Lead's duty mostly to create and maintain the TCK) just fork it locally and raise a pull request. Everybody can do that even with API

Comment by keilw [ 25/Aug/15 ]

However, please don't waste your time "fixing" something that isn't broken.
If we have dependencyManagement for say JUnit or any other artifact that currently isn't used, that is not your concern. What matters are the actually used dependencies and these work as TCK on master builds fine.

So if you think a 1.0.1-SNAPSHOT of Moneta was worth releasing some day, please fix that to pass the TCK.

Comment by keilw [ 25/Aug/15 ]

In fact "provided" is absolutely wrong here for Moneta ;-/
http://stackoverflow.com/questions/6646959/difference-between-maven-scope-compile-and-provided-for-jar-packaging explains:
This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.

Neither moneta-bp nor moneta are "provided" by the TCK or the JDK (until Java 10 or beyond there is no Money RI being part of the JDK ) they must be retrieved from either the local or shared Maven repos when building the TCK. So forget about ANYTHING in the TCK. It works, and we'll clean up some of dependencyManagement when there's time, it isn't used right now.

Comment by otaviojava [ 25/Aug/15 ]

Werner, feel free to neither put "provided" on jsr354-tck or remove from javamoney-tck-usage-example.

But I really prefer the first one, because It's don't make sense to me, test a JSR-354 implementation with other implementation inside. it's smell code.
How will we test a car X with a car Y also in the test?
JSR354-TCK, for me, just need have the RI to compile, the provided scope, and than when you test your implementation, you put it, the implementation, here to run. It's the easier way.

Comment by keilw [ 25/Aug/15 ]

How often, it has the RI. Moneta-BP is the RI. Both Moneta (which should be called "moneta-java8" as we do in JSR 363 downstream projects now) and Moneta-BP (which should ideally have been called "Moneta" or "Moneta-java7") are the RI, they are structurally identical. Which is why Jadira works with both, see this discussion I had with Chris https://github.com/JadiraOrg/jadira/issues/44 and so do other frameworks. You must not break that by introducing something like "car z" with just 3 wheels to stay with your analogy

Comment by otaviojava [ 25/Aug/15 ]

Werner I did a question the about the color and you answered me with the size , it's really not make sense this conversation.
Fine, I will fix looking to javamoney-tck-usage-example.

Comment by keilw [ 25/Aug/15 ]

You're losing me here, what "color"? Anyway, the whole idea with "provided" was wrong. Unless you have a multi-module Maven project where module A, B and C are built, with C having a dependency on A, "provided" will not work for standalone libraries. Moneta is not "provided" with the JDK (and won't be for at least another 3-5 years or more) and compiling the TCK it isn't there if you set this to "provided".

When executing TCKRunner the "SUT" is say moneta-1.0.1-SNAPSHOT and the TCK verifies the signature of that SUT at runtime, it's not compiling the TCK JAR again.

The only place you can fix this is Moneta 1.0.1-SNAPSHOT, TCK and usage examples are perfectly fine. 1.0 passes and 1.0.1-SNAPSHOT BP does, so manipulations to Moneta 1.0.1-SNAPSHOT caused the TCK to break. And also several demos in "javamoney-examples".

Comment by keilw [ 26/Aug/15 ]

It is still fairly bizarre why the problem only started with (also single JAR) moneta 1.0.1 and never hit 1.0 but excluding just moneta-bp seems to solve it for EVERY SR branch of moneta

The whole core exclusion was bogus and unnecessary, since a proper BOM for (modular) 1.0.2-SNAPSHOT requires none of them directly. Nor should they be excluded, on the contrary.

Comment by keilw [ 26/Aug/15 ]

And Otavio, please try to avoid all the verbose branches. Use Git as it's intended and FORK into your personal GitHub user. Then create a pull-request from there. The only branch that's justified is the "modular feature" branch right now for parallel development of 1.0.1 (in master) and 1.0.2. Everything else use forks (especially since Travis-CI has a permanent memory and lists all those branches, whether broken builds or not)

Comment by otaviojava [ 26/Aug/15 ]

The fact is, there is not modularization on 1.0.1 yet.
But ok, you finally understand what I was saying the problem was fixed.

Comment by keilw [ 27/Aug/15 ]

It doesn't explain why 1.0 was fine without that?
Since the "core" and other parts were not even used for a good reason, there was no need to uncomment that or exclude. Your diagram mixed up the modularized 1.0.2 and earlier releases by showing "core" with "moneta-bp". That makes no sense.

While TCK passes at the moment, the structural differences must be resolved anyway. SigTest has to pass, too.

Comment by otaviojava [ 27/Aug/15 ]

Werner, don't worry...
The important thing is the Java understand me and the code passed.
If you see the discussion, I spend too much time to explain what the problem and how the maven works.
And you just saying: "The problem is on moneta and not on TCK".
The next time, I will not explain nothing, just fix the problem.

Comment by keilw [ 27/Aug/15 ]

I understand Maven and used it for over 12 years. In fact, I gave talks to the Eclipse community 10 years ago about Maven and Eclipse before they even thought about writing something like M2E or M2WTP. Getting confused between a modularized version and one with a single JAR was what probably took you a bit of time. Especially drawings that do not describe how it really works. E.g. the Maven BOM.

The fact that it worked without any tweaks to the POM remains. As it failed only Moneta "1.0.1-SNAPSHOT" in master.
As well as a structural deficit created by changes to Moneta that were not yet applied to Moneta-BP (3 or more classes simply missing in just one package alone)
Every public class an application finds in Moneta must exist in Moneta-BP in the same place (there could be slight deviations once modularized, but ideally the package structure should be the same even in a single JAR before that)

Comment by otaviojava [ 27/Aug/15 ]

"The fact of you eat bread everyday, don't make you a baker." Unknown.
Just sorry, I just expect something like "I am wrong sorry", but ok the most important think is the Java code understand me.

Comment by keilw [ 27/Aug/15 ]

I bake software for a long time. Or more importantly design recipes for it. You can put bread into an oven on a conveyor belt and think you're a baker, but more or less do manual labour without knowing what's in it

Part of the change was helpful, but the "core" stuff being bothered with in the proposed PR showed, you did not fully understand the way the TCK and its example work. The part that matters (moneta / moneta-bp) was helpful, so thanks for that.





Make Moneta Modular (JAVAMONEY-137)

[JAVAMONEY-141] Pass TCK Created: 27/Jul/15  Updated: 27/Aug/15  Resolved: 27/Aug/15

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

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

Attachments: PNG File result_test.png     PNG File tck_example_diff.png     PNG File tck_example_result.png     PNG File update_version_diff.png     PNG File update_version_result.png    
Issue Links:
Blocks
is blocked by JAVAMONEY-143 JavaMoney TCK Usage Example results d... Open
Related
is related to JAVAMONEY-140 Convert Module Open
Tags: test

 Description   

Ensure, a modular RI still passes the TCK.
At least https://github.com/JavaMoney/javamoney-tck-usage-example contains a POM entry like

<impl.groupId>org.javamoney</impl.groupId>
<impl.artifactId>moneta</impl.artifactId>
<impl.version>1.0</impl.version>
<impl.packageType>jar</impl.packageType>

Which is not going to work if "moneta" is now a "BOM"/POM rather than a JAR artifact. At the very least the TCK Guideline must be updated, potentially the TCK itself, too. Since JSR 107 published an on-the-fly update 1.0.1 of its TCK: http://mvnrepository.com/artifact/javax.cache/tck-parent/1.0.1 it looks like this is generally possible without an official MR, as long as the RI and other implementations still pass the TCK



 Comments   
Comment by otaviojava [ 27/Jul/15 ]

Werner, I ran the test and everything goes ok.
The moneta is a pom that has all code as dependency, so the behavior doesn't changed just the architecture.

I just ran the command on tck:

mvn test 

Do I need to do more anything?

Comment by keilw [ 27/Jul/15 ]

Did you use the TCK example for that?

Comment by otaviojava [ 27/Jul/15 ]

No, this one:
https://github.com/JavaMoney/jsr354-tck

Comment by keilw [ 27/Jul/15 ]

Though it seems legitimate, please try the Moneta (Java 8) version of that TCK demo to see, if it works. "jar" as artifact sounds fishy, so maybe a few adjustments could be necessary (and a 1.0.1-SNAPSHOT, too)

Comment by otaviojava [ 27/Jul/15 ]

This way?

Comment by keilw [ 27/Jul/15 ]

Also the version of the actual test. Strange, the

<type>${impl.packageType}</type> 

seems to be ignored or irrelevant? Maybe it's optional anyway, then it would be better to leave it than call a POM JAR?

Comment by otaviojava [ 27/Jul/15 ]

I believe the type is irrelevant.

Comment by keilw [ 28/Jul/15 ]

Then let's try to remove it. I can't run it here now, but happy to try as a 2nd opinion. For now best adjusting master of those TCK tests and run them to verify if it still works
I would not forget a "format" modularization, but if everything else was sound we may postpone that step till a 1.0.2+ build.

Comment by keilw [ 28/Jul/15 ]

Actually there is one error message (though it doesn't cause the build or TCK to fail)

Jul 28, 2015 7:36:22 PM org.javamoney.moneta.spi.MonetaryConfig <init>
SCHWERWIEGEND: Error loading javamoney.properties, ignoring jar:file:/C:/Users/Werner/.m2/repository/org/javamoney/moneta/moneta-convert/1.0.1-SNAPSHOT/moneta-convert-1.0.1-SNAPSHOT.jar!/javamoney.properties
java.lang.IllegalStateException: AmbiguousConfiguration detected for 'conversion.default-chain'.
	at org.javamoney.moneta.spi.MonetaryConfig.updateConfig(MonetaryConfig.java:90)
	at org.javamoney.moneta.spi.MonetaryConfig.<init>(MonetaryConfig.java:53)
	at org.javamoney.moneta.spi.MonetaryConfig.<clinit>(MonetaryConfig.java:39)
	at org.javamoney.moneta.internal.DefaultMonetaryCurrenciesSingletonSpi.getDefaultProviderChain(DefaultMonetaryCurrenciesSingletonSpi.java:99)
	at org.javamoney.moneta.internal.DefaultMonetaryCurrenciesSingletonSpi.collectProviders(DefaultMonetaryCurrenciesSingletonSpi.java:69)
	at org.javamoney.moneta.internal.DefaultMonetaryCurrenciesSingletonSpi.getCurrencies(DefaultMonetaryCurrenciesSingletonSpi.java:42)
	at javax.money.spi.MonetaryCurrenciesSingletonSpi.getCurrency(MonetaryCurrenciesSingletonSpi.java:72)
	at javax.money.Monetary.getCurrency(Monetary.java:420)
	at org.javamoney.tck.tests.ModellingCurrenciesTest.testCurrencyClassesComparable(ModellingCurrenciesTest.java:138)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)
	at org.javamoney.test.tck.RunTCKTest.runTCK(RunTCKTest.java:25)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:69)
	at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeSingleClass(TestNGDirectoryTestSuite.java:120)
	at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:104)
	at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:113)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

Looks like the same properties file is in 2 JARs now. On one hand it is used by SPI/core, but logically it belongs to "convert".

Comment by keilw [ 28/Jul/15 ]

The cause is, because a proper dissection of "core" and "convert" was somehow lost (or undone) so a whole "common convert" module is missing and stuff that should be there got into core. See https://java.net/jira/browse/JAVAMONEY-140

Comment by otaviojava [ 28/Jul/15 ]

Werner, are you using the modularized_money_ri branch?
it`s fine.

Comment by keilw [ 28/Jul/15 ]

No it's not
There are still improper things in core that belong to the convert module.
It is not just about making ECB or IMF optional/modular, it's about making the entire convert subsystem modular.
Through some changes or merges this was lost

Somehow "moneta" turned from pure POM to a chimera between "convert-shared" (I'm recreating that) and core, holding primarily conversion-related stuff. That makes no sense.

Comment by otaviojava [ 28/Jul/15 ]

@werner.
it`s following the email list, if you want do other changes about this history, please rollback to email list.
Please, don`t commit directly on modularized_money_ri branch.
This branch follows the issue on email list.

Comment by keilw [ 28/Jul/15 ]

It is incomplete and wrong. Especially that misplaced moneta/convert/core.

Something got very messed up, as it it the branch doesn't add value over the 2 separate lib modules

Comment by otaviojava [ 28/Jul/15 ]

You tould about the Jigsaw, but did you look to Jigsaw on OpenJDK?
http://hg.openjdk.java.net/jdk9/jdk9
If you look to the pach:
jdk9/jdk/src
You will see:

  • java.base
  • java.corba
  • java.datatransfer
  • java.desktop
  • java.instrument
  • java.logging
  • java.management
  • java.naming
  • java.prefs
  • java.rmi
  • java.scripting
  • java.security.jgss
  • java.security.sasl
  • java.smartcardio
  • java.sql
  • ...

So the modularization is by feature, so the javax.money is the same feature, isn't? So they will stay together. This modules doesn't make sense to OpenJDK.

you need the mercurial installed then execute this command:

hg clone http://hg.openjdk.java.net/jdk9/jdk9 jdk_1_9
Comment by keilw [ 28/Jul/15 ]

I know what Mark told us, that's enough.

E.g. you should be able to use Swing without JavaFX and vice versa.
The Circular dependencies make that impossible. Hence, you would always get Swing (except for a particular L&F like "Metal") even if you don't need it.

That is the purpose of clean modularity

Comment by otaviojava [ 28/Jul/15 ]

I really don't understand how.
We have the core code, and the exchange-rate splitted, so three modules.
The exchange rate depends the core, but the core does not depend of the exchange-rate modules.

Comment by keilw [ 28/Jul/15 ]

So if you do not need currency conversion you'll only use
-moneta.core (at the moment that includes formatting)

but not
-moneta-convert-shared
-moneta-convert-ecb
or
-moneta-convert-imf

The API is cleanly separated, too, even if it comes in a single JAR.
Except for the SPI package (which has similar dependencies in JSR 363)
"convert" and "format" are completely independent of each other and there are no circular dependencies from javax.money elements to javax.money.convert, just the other way round

This is what the RI must also accomplish, at least for "convert" and ideally "format", too.

Comment by otaviojava [ 28/Jul/15 ]

There isn't proposal to remove format to the core.
The circular dependencies is when a module A depends of a module B and the B depends of module A.
If the convert depends of core but the core doen's depends of the module convert, so there isn't circular dependencies.

Comment by keilw [ 28/Jul/15 ]

There is a sub-task, and it's possible, but you first gotta cleanly separate core from convert and downstream modules

core -> convert-shared ->
convert-ecb
convert-imf

And no circular dependencies back into core.
Only the "BOM" moneta artifact pulls all of them together

Comment by keilw [ 28/Jul/15 ]

In the incomplete branch you got lots of conversion stuff in moneta, which is not part of convert, so you have a circular dependency (back from ECB/IMF, that's where the tests fail if you do this properly)

Comment by otaviojava [ 28/Jul/15 ]

Werner, there isn't convert on moneta, just the ExchangeRateProvider,
The ExchangeRateProvider is an interface on money-api.
Does the moneta-core depend of the money-api?
So, there isn't circular dependency.
Please, check it again.

This class is on api:
https://github.com/JavaMoney/jsr354-api/blob/master/src/main/java/javax/money/convert/ExchangeRateProvider.java

The moneta-core depends of the money-api, but the money-api does not depend of the moneta-core, still not circular dependency.

BTW: If you find circular dependency just tell me the class, because I will propose this branch on Wednesday to master and send an email to public list. But until now the branch modularized_money_ri is working, with all TCK tests passed, without circular dependency and really complete.

Comment by keilw [ 28/Jul/15 ]

I'm not talking about ExchangeRateProvider, but this
https://github.com/JavaMoney/jsr354-ri/blob/modularized_money_ri/moneta/src/main/java/org/javamoney/moneta/ExchangeRateType.java
It does not belong there, because the "moneta" artifact has dependencies

<dependencies>
<dependency>
<groupId>org.javamoney</groupId>
<artifactId>moneta-convert-imf</artifactId>
<version>$

{project.version}</version>
</dependency>
<dependency>
<groupId>org.javamoney</groupId>
<artifactId>moneta-convert-ecb</artifactId>
<version>${project.version}

</version>
</dependency>

Other stuff that belongs to "convert-shared" was left in "core" so the content of "moneta" JAR is a chimera and doesn't really make sense since one or two enums were randomly removed from "core" instead of properly moving all of it into a reusable convert module.

Gotta go to bed now, will have to continue later. As of now, it is quite likely TCK picked up the single JAR which is all over the place. therefore a unique version number is necessary to really test it. As soon as the version number is distinct and not a snapshot that's been deployed 100 times from a single JAR moneta under the same version, both the TCK and examples are missing some classes.

Comment by otaviojava [ 28/Jul/15 ]

The moneta project has all dependencies and this class still there to keep the compatibility.
moneta is different of the moneta-core, so still compatible.

Comment by keilw [ 28/Jul/15 ]

I'm afraid not. Just ran both against the actual TCK and it fails all but 20 tests.

tck-example even if you select a totally different RI version number (I built them as 1.0.1-RC0 for the "old" attempt and 1.0.1-RC1 for the new untangled onne) always passes, but it doesn't even seem to care about the TCK version, always calls TCK 1.0.
The 233 tests are said to pass, but they run against "god knows what". In fact the original TCK being built against the Java 7 Moneta-BP, so chances are very high you always run those 233 passing tests against Moneta-BP and not even the Java 8 version

That is exactly why the two variations must remain consistent and compatible. Disecting one will not work if the other isn't .

Comment by keilw [ 29/Jul/15 ]

Running TCKRunner is actually best inside the actual TCk module.
Against 1.0.1-SNAPSHOT (most likely Moneta-BP in that case ) results already look bad
------------------------------------------

TOTAL TESTS EXECUTED : 233
TOTAL TESTS SKIPPED : 0
TOTAL TESTS SUCCESS : 222
TOTAL TESTS FAILED : 11

– JSR 354 TCK finished –

Against the 1.0.1-RC0

JSR 354 TCK, version 1.0 Summary
------------------------------------------

TOTAL TESTS EXECUTED : 233
TOTAL TESTS SKIPPED : 0
TOTAL TESTS SUCCESS : 10
TOTAL TESTS FAILED : 223

– JSR 354 TCK finished –

Comment by otaviojava [ 29/Jul/15 ]

I updated the version and still working.

Comment by keilw [ 29/Jul/15 ]

Then it's been running against Moneta-BP all the time
When the TCK is truly run against a modularized Moneta (regardless of the branch) it fails as outlined
TOTAL TESTS EXECUTED : 233
TOTAL TESTS SKIPPED : 0
TOTAL TESTS SUCCESS : 10
TOTAL TESTS FAILED : 223

Both the modularized and semi-modularized versions show the same result here.

Comment by otaviojava [ 29/Jul/15 ]

Wener probaly you broke the local branch, please try download the remote one.
I did all necessary modifications on the pom.

Comment by keilw [ 29/Jul/15 ]

That's exactly the one run against the TCK. RC0 which is the remote one. You may have to do a clean before running TCKRunner, otherwise you're just running against a previous result.
The TCK tests it shows failing (will attach the exact Maven log some time later)
In any case the flawed branch contains a convert-relic like https://github.com/JavaMoney/jsr354-ri/tree/modularized_money_ri/moneta/src/main/java/org/javamoney/moneta/convert for no other reason than providing a pseudo-JAR. That's not the right way to do it, these are classes that have no place there, they must be in "convert"
And all of these imports

import org.javamoney.moneta.convert.ecb.ECBCurrentRateProvider;
import org.javamoney.moneta.convert.ecb.ECBHistoric90RateProvider;
import org.javamoney.moneta.convert.ecb.ECBHistoricRateProvider;
import org.javamoney.moneta.convert.imf.IMFHistoricRateProvider;
import org.javamoney.moneta.convert.imf.IMFRateProvider;

are unused, and given this is a "shared convert" class, also won't work this way.

Probably tricking Maven into pulling stuff from other modules but that's a dirty hack. As a matter of fact, the enum will require splitting up because it refers to stuff in different modules.
And getting the dependency chain right without an empty shell that contains just 2 classes that don't fit there.

Comment by keilw [ 29/Jul/15 ]

In fact nobody needs to check out all of OpenJDK or use Hg to see how the Jigsaw modules are dependent on each other.
Looking at this 2000 line "Uber POM" http://hg.openjdk.java.net/jdk9/jdk9/file/887a2657adef/modules.xml is more than enough.

It contains all details of packages or "bundles" that make up larger feature modules like "java.base".
We discussed in great detail on the mailing list that the "Sins of our fathers" in the JDK all the way up to Java 8 and further bloating like "java.time" made it almost impossible to break it down further. Developers who use only java.util.Date or Calendar won't care about "java.time" but they were tied to each other in some ways (or as Stephen mentioned share underlying TZ data in a shared but clumsy fashion) so they were molded together in an inseparable manner. Similar in many other cases where short-sighted or insignificant API design caused a big mess. That's why Jigsaw was delayed for so many years. "java.desktop" clearly does not contain the JavaFX codebase. That is a very separate module which has dependencies at least to "java.base" maybe a few other modules but is not required for any of them java.desktop (with AWT and Swing) can be completely taken away for smaller devices.

What you propose and drafted in the earlier branch is no more than taking these away out of "java.desktop"

<export>
      <name>javax.swing.plaf.basic</name>
    </export>
    <export>
      <name>javax.swing.plaf.metal</name>
    </export>
    <export>
      <name>javax.swing.plaf.multi</name>
    </export>
    <export>
      <name>javax.swing.plaf.nimbus</name>
    </export>
    <export>
      <name>javax.swing.plaf.synth</name>
    </export>

(L 739ff in the current modules.xml)

Leaving the rest of it in there. These providers are no more than Swing PLAF extensions, they barely mean any footprint and don't bring benefit to users e.g. if they don't care about foreign exchange but just need to do rounding and calculations in their own local currency.

HTH

Comment by keilw [ 29/Jul/15 ]

So this is the entire Maven console running against the old branch (1.0.1-RC0, everything in sync with GitHub, just check it)

-- JSR 354 TCK started --
Writing to file C:\Users\Werner\git\jsr354-tck\.\target\tck-results.txt ...
[TestNG] Running:
  Command line suite

Jul 29, 2015 8:17:59 PM org.javamoney.moneta.DefaultMonetaryContextFactory createMonetaryContextNonNullConfig
INFORMATION: Using custom MathContext: precision=256, roundingMode=HALF_EVEN
Jul 29, 2015 8:18:00 PM org.javamoney.moneta.internal.loader.LoadRemoteDataLoaderService execute
INFORMATION: The exchange rate with resourceId IMFHistoricRateProvider was started remotely
Jul 29, 2015 8:18:00 PM org.javamoney.moneta.internal.loader.LoadRemoteDataLoaderService execute
INFORMATION: The exchange rate with resourceId IMFRateProvider was started remotely
Jul 29, 2015 8:18:00 PM org.javamoney.moneta.internal.loader.LoadRemoteDataLoaderService execute
INFORMATION: The exchange rate with resourceId ECBCurrentRateProvider was started remotely
Jul 29, 2015 8:18:01 PM org.javamoney.moneta.convert.ecb.ECBAbstractRateProvider newDataLoaded
INFORMATION: Loaded ECBCurrentRateProvider exchange rates for days:1
Jul 29, 2015 8:18:01 PM org.javamoney.moneta.spi.CompoundRateProvider getExchangeRate
WARNUNG: Rate Provider did not return data though at check before data was flagged as available, provider=ECB, query=ConversionQuery (
{Query.termCurrency=org.javamoney.tck.tests.internal.TestCurrencyUnit@4c40b76e, Query.baseCurrency=CHF})
Jul 29, 2015 8:18:01 PM org.javamoney.moneta.convert.ecb.ECBAbstractRateProvider newDataLoaded
INFORMATION: Loaded ECBHistoric90RateProvider exchange rates for days:63

===============================================
JSR354-TCK, version 1.0
Total tests run: 233, Failures: 11, Skips: 0
===============================================


********************************************************************************
**** JSR 354 - Money & Currency, Technical Compatibility Kit, version 1.0.
********************************************************************************

Executed on Wed Jul 29 20:17:57 CEST 2015

[FAILED]  4.2.1 Ensure registered CurrencyUnit classes are Comparable.(ModellingCurrenciesTest#testCurrencyClassesComparable):
java.lang.ExceptionInInitializerError
	at org.javamoney.tck.tests.ModellingCurrenciesTest.testCurrencyClassesComparable(ModellingCurrenciesTest.java:134)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)
Caused by: java.lang.IllegalStateException: No valid implementation of org.javamoney.tck.JSR354TestConfiguration is registered with the ServiceLoader.
	at org.javamoney.tck.TCKTestSetup.loadTestConfiguration(TCKTestSetup.java:33)
	at org.javamoney.tck.TCKTestSetup.<clinit>(TCKTestSetup.java:19)
	... 23 more

[FAILED]  4.2.1 Ensure registered CurrencyUnit classes implement hashCode.(ModellingCurrenciesTest#testCurrencyClassesEqualsHashcode):
java.lang.NoClassDefFoundError: Could not initialize class org.javamoney.tck.TCKTestSetup
	at org.javamoney.tck.tests.ModellingCurrenciesTest.testCurrencyClassesEqualsHashcode(ModellingCurrenciesTest.java:93)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)

[SUCCESS] 4.2.1 Test currencies provided have correct ISO 3-letter currency codes.(ModellingCurrenciesTest#testEnforce3LetterCode4ISO)
[FAILED]  4.2.1 Ensure TCK has CurrencyUnit classes configured.(ModellingCurrenciesTest#testEnsureCurrencyUnit):
java.lang.NoClassDefFoundError: Could not initialize class org.javamoney.tck.TCKTestSetup
	at org.javamoney.tck.tests.ModellingCurrenciesTest.testEnsureCurrencyUnit(ModellingCurrenciesTest.java:36)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)

[SUCCESS] 4.2.1 Test currencies provided equal at least currencies from java.util.Currency.(ModellingCurrenciesTest#testEqualISOCurrencies)
[SUCCESS] 4.2.1 Test currencies provided have correct default fraction digits and numeric code.(ModellingCurrenciesTest#testISOCodes)
[SUCCESS] 4.2.1 Ensure registered CurrencyUnit classes implement equals.(ModellingCurrenciesTest#testImplementsEquals)
[FAILED]  4.2.1 Ensure registered CurrencyUnit classes are serializable.(ModellingCurrenciesTest#testImplementsSerializable):
java.lang.NoClassDefFoundError: Could not initialize class org.javamoney.tck.TCKTestSetup
	at org.javamoney.tck.tests.ModellingCurrenciesTest.testImplementsSerializable(ModellingCurrenciesTest.java:164)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)

[FAILED]  4.2.1 Ensure registered CurrencyUnit classes are immutable.(ModellingCurrenciesTest#testIsImmutable):
java.lang.NoClassDefFoundError: Could not initialize class org.javamoney.tck.TCKTestSetup
	at org.javamoney.tck.tests.ModellingCurrenciesTest.testIsImmutable(ModellingCurrenciesTest.java:149)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)

[SUCCESS] 4.2.2 For each amount class, test absolute().(ModellingMonetaryAmountsTest#testAbsolute)
[SUCCESS] 4.2.2 For each amount class, check m1.add(m2), m1, m2 = mixed fractions.(ModellingMonetaryAmountsTest#testAddMixedFractions)
[SUCCESS] 4.2.2 For each amount class, check m1.add(m2), m1, m2 = mixed ints.(ModellingMonetaryAmountsTest#testAddMixedIntegers)
[SUCCESS] 4.2.2 For each amount class, check m1.add(m2), m1 <0, m2<0.(ModellingMonetaryAmountsTest#testAddNegativeIntegers)
[SUCCESS] 4.2.2 For each amount class, check m1.add(m2), m2 is fraction.(ModellingMonetaryAmountsTest#testAddPositiveFractions)
[SUCCESS] 4.2.2 For each amount class, check m1.add(m2), m1 >0, m2>0.(ModellingMonetaryAmountsTest#testAddPositiveIntegers)
[SUCCESS] 4.2.2 For each amount class, ensure ArithemticException is thrown when adding exceeding values.(ModellingMonetaryAmountsTest#testAdd_ExceedsCapabilities)
[SUCCESS] 4.2.2 For each amount class, ensure currency compatibility is working.(ModellingMonetaryAmountsTest#testAdd_IncompatibleCurrencies)
[SUCCESS] 4.2.2 For each amount class, ensure NullPointerException is thrown when calling m.add(null).(ModellingMonetaryAmountsTest#testAdd_Null)
[SUCCESS] 4.2.2 For each amount class, ensure m2 = m1,add(0) -> m1==m2.(ModellingMonetaryAmountsTest#testAdd_Zero)
[SUCCESS] 4.2.2 Ensure amount can be created with all default currencies.(ModellingMonetaryAmountsTest#testCurrencyCode)
[SUCCESS] 4.2.2 For each amount class, ensure correct division.(ModellingMonetaryAmountsTest#testDivide)
[SUCCESS] 4.2.2 For each amount class, ensure correct divideAndRemainder().(ModellingMonetaryAmountsTest#testDivideAndRemainder)
[SUCCESS] 4.2.2 For each amount class, ensure divideAndRemainder(Double.NEGATIVE_INFINITY) returns ZERO amount.(ModellingMonetaryAmountsTest#testDivideAndRemainderDoubleNEGATIVE_INFINITY)
[SUCCESS] 4.2.2 For each amount class, ensure divideAndRemainder(Double.NaN) throws a ArithmeticException.(ModellingMonetaryAmountsTest#testDivideAndRemainderDoubleNaN)
[SUCCESS] 4.2.2 For each amount class, ensure divideAndRemainder(Double.POSITIVE_INFINITY) returns ZERO amount.(ModellingMonetaryAmountsTest#testDivideAndRemainderDoublePOSITIVE_INFINITY)
[SUCCESS] 4.2.2 For each amount class, ensure divideAndRemainder(null) throws a NullPointerException.(ModellingMonetaryAmountsTest#testDivideAndRemainderNull)
[SUCCESS] 4.2.2 For each amount class, ensure divideAndRemainder(1) returns same instance.(ModellingMonetaryAmountsTest#testDivideAndRemainderOne)
[SUCCESS] 4.2.2 For each amount class, ensure correct divideAndRemainderZero().(ModellingMonetaryAmountsTest#testDivideAndRemainderZero)
[SUCCESS] 4.2.2 For each amount class, ensure divide(Double.NEGATIVE_INFINITY) return ZERO amount.(ModellingMonetaryAmountsTest#testDivideDoubleNEGATIVE_INFINITY)
[SUCCESS] 4.2.2 For each amount class, ensure divide(Double.NaN) throws ArithmeticException.(ModellingMonetaryAmountsTest#testDivideDoubleNaN)
[SUCCESS] 4.2.2 For each amount class, ensure divide(Double.POSITIVE_INFINITY) return ZERO amount.(ModellingMonetaryAmountsTest#testDivideDoublePOSITIVE_INFINITY)
[SUCCESS] 4.2.2 For each amount class, ensure divide by null throws NullPointerException.(ModellingMonetaryAmountsTest#testDivideNull)
[SUCCESS] 4.2.2 For each amount class, ensure divide 1 returns same instance.(ModellingMonetaryAmountsTest#testDivideOne)
[SUCCESS] 4.2.2 For each amount class, ensure correct division with int values.(ModellingMonetaryAmountsTest#testDivideToIntegralValue)
[SUCCESS] 4.2.2 For each amount class, ensure divide(0) throws ArithmeticException.(ModellingMonetaryAmountsTest#testDivideZero)
[SUCCESS] 4.2.2 Ensure Monetary.getAmountTypes() is not null and not empty.(ModellingMonetaryAmountsTest#testEnsureMonetaryAmount)
[SUCCESS] 4.2.2 Ensure amounts created return correct getContext().(ModellingMonetaryAmountsTest#testGetMonetaryContext)
[SUCCESS] 4.2.2 Ensure amounts created return correct getNumber().(ModellingMonetaryAmountsTest#testGetNumber)
[FAILED]  4.2.2 For each amount class, test iis immutable.(ModellingMonetaryAmountsTest#testImmutable):
java.lang.NoClassDefFoundError: Could not initialize class org.javamoney.tck.TCKTestSetup
	at org.javamoney.tck.tests.ModellingMonetaryAmountsTest.testImmutable(ModellingMonetaryAmountsTest.java:2543)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)

[SUCCESS] 4.2.2 For each amount class, test is Comparable.(ModellingMonetaryAmountsTest#testImplementComparable)
[SUCCESS] 4.2.2 For each amount class, test implements equals().(ModellingMonetaryAmountsTest#testImplementsEquals)
[SUCCESS] 4.2.2 For each amount class, test implements hashCode().(ModellingMonetaryAmountsTest#testImplementsHashCode)
[SUCCESS] 4.2.2 For each amount class, test isNegative().(ModellingMonetaryAmountsTest#testIsNegative)
[SUCCESS] 4.2.2 For each amount class, test isNegativeOrZero().(ModellingMonetaryAmountsTest#testIsNegativeOrZero)
[SUCCESS] 4.2.2 For each amount class, test isPositive().(ModellingMonetaryAmountsTest#testIsPositive)
[SUCCESS] 4.2.2 For each amount class, test isPositiveOrZero().(ModellingMonetaryAmountsTest#testIsPositiveOrZero)
[SUCCESS] 4.2.2 For each amount class, test isZero().(ModellingMonetaryAmountsTest#testIsZero)
[SUCCESS] 4.2.2 For each amount class, test isZero(), advanced.(ModellingMonetaryAmountsTest#testIsZeroAdvanced)
[SUCCESS] 4.2.2 For each amount class, access factory and of amounts.(ModellingMonetaryAmountsTest#testMonetaryAmountFactories)
[SUCCESS] 4.2.2 For each amount class, check multiple instances are not equal.(ModellingMonetaryAmountsTest#testMonetaryAmountFactories_CreateWithCurrencies)
[SUCCESS] 4.2.2 For each amount class, check new amounts with explcit MonetaryContext.(ModellingMonetaryAmountsTest#testMonetaryAmountFactories_CreateWithMonetaryContext)
[SUCCESS] 4.2.2 For each amount class, check new amounts are not equal for different currencies and contexts.(ModellingMonetaryAmountsTest#testMonetaryAmountFactories_CreateWithMonetaryContextNumberAndCurrency)
[SUCCESS] 4.2.2 For each amount class, access factory and of amounts, ensure amounts are equal if theyshould.(ModellingMonetaryAmountsTest#testMonetaryAmountFactories_InstancesMustBeEqual)
[SUCCESS] 4.2.2 For each amount class, check new amounts are not equal.(ModellingMonetaryAmountsTest#testMonetaryAmountFactories_InstantesMustBeNotEqual)
[SUCCESS] 4.2.2 For each amount class, check isEqualTo().(ModellingMonetaryAmountsTest#testMonetaryAmount_isEqualTo)
[SUCCESS] 4.2.2 For each amount class, check isEqualTo(), regardless different MonetaryContext instances.(ModellingMonetaryAmountsTest#testMonetaryAmount_isEqualToRegardlessMonetaryContext)
[SUCCESS] 4.2.2 For each amount class, check isEqualTo(), regardless implementation type.(ModellingMonetaryAmountsTest#testMonetaryAmount_isEqualToRegardlessType)
[SUCCESS] 4.2.2 For each amount class, check isGreaterThan().(ModellingMonetaryAmountsTest#testMonetaryAmount_isGreaterThan)
[SUCCESS] 4.2.2 For each amount class, check isGreaterThanOrEquals().(ModellingMonetaryAmountsTest#testMonetaryAmount_isGreaterThanOrEquals)
[SUCCESS] 4.2.2 For each amount class, check isLessThan().(ModellingMonetaryAmountsTest#testMonetaryAmount_isLessThan)
[SUCCESS] 4.2.2 For each amount class, check isLessThanOrEqualTo().(ModellingMonetaryAmountsTest#testMonetaryAmount_isLessThanOrEqualTo)
[SUCCESS] 4.2.2 For each amount class, ensure multiplication with exceeding values throws ArithmeticException.(ModellingMonetaryAmountsTest#testMultiplyExceedsCapabilities)
[SUCCESS] 4.2.2 For each amount class, ensure multiplication of null throws NullPointerException.(ModellingMonetaryAmountsTest#testMultiplyNull)
[SUCCESS] 4.2.2 For each amount class, ensure multiplication by one returns same instance.(ModellingMonetaryAmountsTest#testMultiplyOne)
[SUCCESS] 4.2.2 For each amount class, ensure correct multiplication of decimal values.(ModellingMonetaryAmountsTest#testMultiply_Decimals)
[SUCCESS] 4.2.2 For each amount class, ensure multiplication of Double.NEGATIVE_INFINITY throws ArithmeticException.(ModellingMonetaryAmountsTest#testMultiply_DoubleNEGATIVE_INFINITY)
[SUCCESS] 4.2.2 For each amount class, ensure multiplication of Double.NaN throws ArithmeticException.(ModellingMonetaryAmountsTest#testMultiply_DoubleNaN)
[SUCCESS] 4.2.2 For each amount class, ensure multiplication of Double.POSITIVE_INFINITY throws ArithmeticException.(ModellingMonetaryAmountsTest#testMultiply_DoublePOSITIVE_INFINITY)
[SUCCESS] 4.2.2 For each amount class, ensure correct multiplication of int values.(ModellingMonetaryAmountsTest#testMultiply_Integral)
[SUCCESS] 4.2.2 For each amount class, test negate().(ModellingMonetaryAmountsTest#testNegate)
[SUCCESS] 4.2.2 For each amount class, test query().(ModellingMonetaryAmountsTest#testQuery)
[SUCCESS] 4.2.2 For each amount class, test query(), MonetaryQuery throws exception, MonetaryException expected.(ModellingMonetaryAmountsTest#testQueryInvalidQuery)
[SUCCESS] 4.2.2 For each amount class, test query(null), NullPointerException expected.(ModellingMonetaryAmountsTest#testQueryNull)
[SUCCESS] 4.2.2 For each amount class, ensure correct results for remainder.(ModellingMonetaryAmountsTest#testRemainder)
[SUCCESS] 4.2.2 For each amount class, ensure remainder(null), throws NullPointerException.(ModellingMonetaryAmountsTest#testRemainderNull)
[SUCCESS] 4.2.2 For each amount class, ensure remainder(0), double, throws ArithmeticException.(ModellingMonetaryAmountsTest#testRemainderZero_Double)
[SUCCESS] 4.2.2 For each amount class, ensure remainder(0), long, throws ArithmeticException.(ModellingMonetaryAmountsTest#testRemainderZero_Long)
[SUCCESS] 4.2.2 For each amount class, ensure remainder(0), Number, throws ArithmeticException.(ModellingMonetaryAmountsTest#testRemainderZero_Number)
[SUCCESS] 4.2.2 For each amount class, ensure remainder(Double.NEGATIVE_INFINITY), throws ArithmeticException.(ModellingMonetaryAmountsTest#testRemainder_DoubleNEGATIVE_INFINITY)
[SUCCESS] 4.2.2 For each amount class, ensure remainder(Double.NaN), throws ArithmeticException.(ModellingMonetaryAmountsTest#testRemainder_DoubleNaN)
[SUCCESS] 4.2.2 For each amount class, ensure remainder(Double.POSITIVE_INFINITY), throws ArithmeticException.(ModellingMonetaryAmountsTest#testRemainder_DoublePOSITIVE_INFINITY)
[SUCCESS] 4.2.2 For each amount class, ensure scaleByPowerOfTen(1) returns correct results.(ModellingMonetaryAmountsTest#testScaleByPowerOfTen)
[SUCCESS] 4.2.2 For each amount class, test signum().(ModellingMonetaryAmountsTest#testSignum)
[SUCCESS] 4.2.2 For each amount class, ensure correct subtraction of mixed fractions.(ModellingMonetaryAmountsTest#testSubtractMixedFractions)
[SUCCESS] 4.2.2 For each amount class, ensure correct subtraction of mixed ints.(ModellingMonetaryAmountsTest#testSubtractMixedIntegers)
[SUCCESS] 4.2.2 For each amount class, ensure correct subtraction of negative ints.(ModellingMonetaryAmountsTest#testSubtractNegativeIntegers)
[SUCCESS] 4.2.2 For each amount class, ensure correct subtraction of positive fractions.(ModellingMonetaryAmountsTest#testSubtractPositiveFractions)
[SUCCESS] 4.2.2 For each amount class, ensure correct subtraction of positive ints.(ModellingMonetaryAmountsTest#testSubtractPositiveIntegers)
[SUCCESS] 4.2.2 For each amount class, ensure subtraction with exceeding capabilities throws ArithmeticException.(ModellingMonetaryAmountsTest#testSubtract_ExceedsCapabilities)
[SUCCESS] 4.2.2 For each amount class, ensure subtraction with invalid currency throws MonetaryException.(ModellingMonetaryAmountsTest#testSubtract_IncompatibleCurrencies)
[SUCCESS] 4.2.2 For each amount class, ensure subtraction with null throws NullPointerException.(ModellingMonetaryAmountsTest#testSubtract_Null)
[SUCCESS] 4.2.2 For each amount class, ensure subtraction of 0 returns same instance.(ModellingMonetaryAmountsTest#testSubtract_Zero)
[SUCCESS] 4.2.2 For each amount class, test with().(ModellingMonetaryAmountsTest#testWith)
[FAILED]  4.2.2 For each amount class, test with().(ModellingMonetaryAmountsTest#testWith4ProvidedOperators):
java.lang.NoClassDefFoundError: Could not initialize class org.javamoney.tck.TCKTestSetup
	at org.javamoney.tck.tests.ModellingMonetaryAmountsTest.testWith4ProvidedOperators(ModellingMonetaryAmountsTest.java:2285)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)

[SUCCESS] 4.2.2 Bad case: For each amount class, test with(), operator throws exception.(ModellingMonetaryAmountsTest#testWithInvalidOperator)
[SUCCESS] 4.2.2 Bad case: For each amount class, test with(null), expected NullPointerException.(ModellingMonetaryAmountsTest#testWithNull)
[FAILED]  4.2.2 Bad case: For each amount class, test with(), operator throws exception.(ModellingMonetaryAmountsTest#testWithNull4ProvidedOperators):
java.lang.NoClassDefFoundError: Could not initialize class org.javamoney.tck.TCKTestSetup
	at org.javamoney.tck.tests.ModellingMonetaryAmountsTest.testWithNull4ProvidedOperators(ModellingMonetaryAmountsTest.java:2366)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)

[SUCCESS] 4.2.6 Ensure MonetaryAmountFactory instances are accessible for all amount types under test.(CreatingMonetaryAmountsTest#testAccessToMonetaryAmountFactory)
[SUCCESS] 4.2.6 Bad case: For each MonetaryAmount Factory: Create zero amounts from a factory with an invalid currency.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreateAmountsWithInvalidCurrency)
[SUCCESS] 4.2.6 Bad case: For each MonetaryAmount Factory: Create zero amounts from a factory with an invalid MonetaryContext.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreateAmountsWithInvalidMonetaryContext)
[SUCCESS] 4.2.6 Bad case: For each MonetaryAmount Factory: Create negative amounts, with no currency, expect MonetaryException.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreateNegativeInvalidContext_BadCase)
[SUCCESS] 4.2.6 Bad case: For each MonetaryAmount Factory: Create negative amounts, with invalid currency, expect MonetaryException.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreateNegativeInvalidCurrency_BadCase)
[SUCCESS] 4.2.6 Bad case: For each MonetaryAmount Factory: Create negative amounts, with no currency, expect MonetaryException.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreateNegativeNoCurrency_BadCase)
[SUCCESS] 4.2.6 For each MonetaryAmount Factory: Create positive amounts.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreatePositiveAmountsWitCurrencies)
[SUCCESS] 4.2.6 For each MonetaryAmount Factory: Create positive amounts with explicit MonetaryContext.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreatePositiveAmountsWithContexts)
[SUCCESS] 4.2.6 For each MonetaryAmount Factory: Create positive amounts using doubles with explicit MonetaryContext (precision/scale).(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreatePositiveAmountsWithContexts2)
[SUCCESS] 4.2.6 For each MonetaryAmount Factory: Create positive amounts using BigDecimal with explicit MonetaryContext (precision/scale).(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreatePositiveAmountsWithContexts3)
[SUCCESS] 4.2.6 Bad case: For each MonetaryAmount Factory: Create positive amounts using invalid numbers, expecting ArithemticException thrown.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreatePositiveAmountsWithInvalidNumber)
[SUCCESS] 4.2.6 Bad case: For each MonetaryAmount Factory: Create negative amounts with an invalid currency, expecting MonetaryException thrown.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreatePositiveInvalidContext_BadCase)
[SUCCESS] 4.2.6 Bad case: For each MonetaryAmount Factory: Create negative amounts with an invalid currency, expecting MonetaryException thrown.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreatePositiveInvalidCurrency_BadCase)
[SUCCESS] 4.2.6 Bad case: For each MonetaryAmount Factory: Create negative amounts without currency, expecting MonetaryException thrown.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreatePositiveNoCurrency_BadCase)
[SUCCESS] 4.2.6 Ensure MonetaryAmountFactory instances support creation of 0 amounts, with explicit MonetaryContext.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreateZeroAmountsWithDiffContexts)
[SUCCESS] 4.2.6 Ensure MonetaryAmountFactory instances support creation of 0 amounts, with different explicit MonetaryContext.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreateZeroAmountsWithDiffContexts2)
[SUCCESS] 4.2.6 Ensure MonetaryAmountFactory instances support creation of 0 amounts, with different explicit MonetaryContext (precision, scale).(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreateZeroAmountsWithDiffContexts3)
[SUCCESS] 4.2.6 Ensure MonetaryAmountFactory instances support creation of 0 amounts.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreateZeroAmountsWithDiffCurrencies)
[SUCCESS] 4.2.6 Ensure MonetaryAmountFactory instances accessible for all amount types under test return correct min/max MonetaryContext.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryMinMaxCapabilities)
[SUCCESS] 4.2.6 Ensure MonetaryAmountFactory instances accessible for all amount types under test return correct min/max MonetaryContext (min <= max).(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryMinMaxCapabilities_Compare)
[SUCCESS] 4.2.6 For each MonetaryAmount Factory: Create negative amounts.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryNegativePositiveAmountsWitCurrencies)
[SUCCESS] 4.2.6 For each MonetaryAmount Factory: Create negative amounts, with explicit MonetaryContext.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryNegativePositiveAmountsWithContexts)
[SUCCESS] 4.2.6 For each MonetaryAmount Factory: Create negative amounts, with explicit MonetaryContext.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryNegativePositiveAmountsWithContexts2)
[SUCCESS] 4.2.6 For each MonetaryAmount Factory: Create negative amounts, with explicit MonetaryContext.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryNegativePositiveAmountsWithContexts3)
[SUCCESS] 4.2.6 Bad case: For each MonetaryAmount Factory: Create negative amounts, with invalid numeric value, expect ArithmeticException.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryNegativePositiveAmountsWithInvalidNumber)
[SUCCESS] 4.2.6 Ensure MonetaryAmountFactory instances accessible for all amount types under test return correct amount type.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryReturnsCorrectType)
[SUCCESS] 4.2.7 Ensure the types available, must be at least one type.(CreatingMonetaryAmountsTest#testMonetaryAmountTypes_Available)
[SUCCESS] 4.2.3 Checks if a correct Double value is returned, no truncation is allowed to be performed.(ExternalizingNumericValueTest#testDoubleNegative)
[SUCCESS] 4.2.3 Check if a correct double value is returned, truncation is allowed to be performed (but is not necessary).(ExternalizingNumericValueTest#testDoubleValueWithTruncationZero)
[SUCCESS] 4.2.3 Checks if a correct double value is returned, truncation is allowed to be performed.(ExternalizingNumericValueTest#testDoubleWithTruncationNegative)
[SUCCESS] 4.2.3 Checks if a correct Integer value is returned, no truncation is allowed to be performed.(ExternalizingNumericValueTest#testIntegerNegative)
[SUCCESS] 4.2.3 Check if a correct integer value is returned, truncation is allowed to be performed. Check should be done for every JDK type supported.(ExternalizingNumericValueTest#testIntegerValueWithTruncationZero)
[SUCCESS] 4.2.3 Check if a correct integer value is returned, truncation is allowed to be performed..(ExternalizingNumericValueTest#testIntegerWithTruncationNegative)
[SUCCESS] 4.2.3 Check if a correct integer value is returned, no truncation is  allowed to be performed.(ExternalizingNumericValueTest#testIntegerZero)
[SUCCESS] 4.2.3 Checks if a correct negative long value is returned, no truncation is allowed to be performed.(ExternalizingNumericValueTest#testLongNegative)
[SUCCESS] 4.2.3 Check if a correct long value is returned, truncation is allowed to be performed. Check should be done for every JDK type supported.(ExternalizingNumericValueTest#testLongValueWithTruncationZero)
[SUCCESS] 4.2.3 Checks if a correct long value is returned, truncation is allowed to be performed.(ExternalizingNumericValueTest#testLongWithTruncationNegative)
[SUCCESS] 4.2.3 Check if a correct long zero value is returned, no truncation is  allowed to be performed.(ExternalizingNumericValueTest#testLongZero)
[SUCCESS] 4.2.3 Ensure NumberValue numberValue() works correnctly.(ExternalizingNumericValueTest#testNumberTypeNegative)
[SUCCESS] 4.2.3 Checks if number type is not null and returning a concrete (no abstract class or interface).(ExternalizingNumericValueTest#testNumberTypeZero)
[SUCCESS] 4.2.3 Checks if a correct long value is returned, truncation is allowed to be performed. Check should be done for every JDK type.(ExternalizingNumericValueTest#testNumberValueWithTruncationNegative)
[SUCCESS] 4.2.3 Checks if a correct double value is returned, truncation is allowed to be performed. Check should be done for every JDK type.(ExternalizingNumericValueTest#testNumberValueWithTruncationNegative_Double)
[SUCCESS] 4.2.3 Checks if a correct double value is returned, truncation is allowed to be performed. Check should be done for every JDK type.(ExternalizingNumericValueTest#testNumberValueWithTruncationNegative_Float)
[SUCCESS] 4.2.3 Checks if a correct int value is returned, truncation is allowed to be performed. Check should be done for every JDK type.(ExternalizingNumericValueTest#testNumberValueWithTruncationNegative_Integer)
[SUCCESS] 4.2.3 Checks if a correct Number value is returned, truncation is allowed to be performed. Check should be done for every JDK type.(ExternalizingNumericValueTest#testNumberValueWithTruncationNegative_Long)
[SUCCESS] 4.2.3 Checks if a correct double value is returned, truncation is allowed to be performed. Check should be done for every JDK type.(ExternalizingNumericValueTest#testNumberValueWithTruncationNegative_Short)
[SUCCESS] 4.2.3 Check if a correct Number value is returned, truncation is allowed to be performed. Check should be done for every JDK type supported.(ExternalizingNumericValueTest#testNumberValueWithTruncationZero)
[SUCCESS] 4.2.3 Check if a correct long zero value is returned, no truncation is  allowed to be performed.(ExternalizingNumericValueTest#testNumberValueZero)
[SUCCESS] 4.2.3 Check if a correct number value is returned, truncation is  allowed to be performed. Check should be done for every JDK type supported.(ExternalizingNumericValueTest#testNumberWithTruncationNegative)
[SUCCESS] 4.2.3 Test correct precision values, including border cases.(ExternalizingNumericValueTest#testPrecisionNegative)
[SUCCESS] 4.2.3 Ensure NumberValue getPrecision() works correctly.(ExternalizingNumericValueTest#testPrecisionValues)
[SUCCESS] 4.2.3 Check if a correct precision value is returned. Check should be done for every JDK type supported.(ExternalizingNumericValueTest#testPrecisionZero)
[SUCCESS] 4.2.3 Amount types do not return a NumberValue of null.(ExternalizingNumericValueTest#testReturningNumberValueIsNotNull)
[SUCCESS] 4.2.3 Test correct scale values, including border cases.(ExternalizingNumericValueTest#testScaleNegative)
[SUCCESS] 4.2.3 Ensure NumberValue getScale() works correctly.(ExternalizingNumericValueTest#testScaleValues)
[SUCCESS] 4.2.3 Check if a correct scale value is returned. Check should be done for every JDK type supported.(ExternalizingNumericValueTest#testScaleZero)
[SUCCESS] 4.2.3 Ensure NumberValue doubleValue(), doubleValueExact() provide correct values.(ExternalizingNumericValueTest#testValidDouble)
[SUCCESS] 4.2.3 Ensure NumberValue doubleValue() is truncated.(ExternalizingNumericValueTest#testValidDoubleWithTruncation)
[SUCCESS] 4.2.3 Ensure NumberValue intValue(), intValueExact() provide correct values.(ExternalizingNumericValueTest#testValidInteger)
[SUCCESS] 4.2.3 Ensure NumberValue intValue() is truncated.(ExternalizingNumericValueTest#testValidIntegerWithTruncation)
[SUCCESS] 4.2.3 Ensure NumberValue longValue(), longValueExact() provide correct values.(ExternalizingNumericValueTest#testValidLong)
[SUCCESS] 4.2.3 Ensure NumberValue longValue() is truncated.(ExternalizingNumericValueTest#testValidLongWithTruncation)
[SUCCESS] 4.2.3 Ensure NumberValue asType(BigDecimal.class) provides correct values.(ExternalizingNumericValueTest#testValidNumberBD)
[SUCCESS] 4.2.3 Ensure NumberValue asType(BigInteger.class) provides correct values.(ExternalizingNumericValueTest#testValidNumberBI)
[SUCCESS] 4.2.3 Ensure NumberValue byteValue() is truncated.(ExternalizingNumericValueTest#testValidNumberWithTruncation_Byte)
[SUCCESS] 4.2.3 Ensure NumberValue doubleValue() is truncated.(ExternalizingNumericValueTest#testValidNumberWithTruncation_Double)
[SUCCESS] 4.2.3 Ensure NumberValue floatValue() is truncated.(ExternalizingNumericValueTest#testValidNumberWithTruncation_Float)
[SUCCESS] 4.2.3 Ensure NumberValue intValue() is truncated correctly.(ExternalizingNumericValueTest#testValidNumberWithTruncation_Integer)
[SUCCESS] 4.2.3 Ensure NumberValue shortValue() is truncated.(ExternalizingNumericValueTest#testValidNumberWithTruncation_Short)
[FAILED]  4.2.4 Ensures the result of all operators under test is of the same class as the input.(FunctionalExtensionPointsTest#testOperatorReturnTypeEqualsParameter):
java.lang.NoClassDefFoundError: Could not initialize class org.javamoney.tck.TCKTestSetup
	at org.javamoney.tck.tests.FunctionalExtensionPointsTest.testOperatorReturnTypeEqualsParameter(FunctionalExtensionPointsTest.java:43)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)

[SUCCESS] 4.2.7 Access named roundings and ensure TCK named roundings are registered.(AccessingCurrenciesAmountsRoundingsTest#testAccessCustomRoundings)
[SUCCESS] 4.2.7 Ensure Monetary instances are available, for all registered currencies.(AccessingCurrenciesAmountsRoundingsTest#testAccessRoundingsForCustomCurrencies_Default)
[SUCCESS] 4.2.7 Ensure Monetary instances are available, also for any custom currency (not registered).(AccessingCurrenciesAmountsRoundingsTest#testAccessRoundingsForCustomCurrencies_Explicit)
[SUCCESS] 4.2.7 Expected NullPointerException accessing a rounding with 'Monetary.getRounding(null)'.(AccessingCurrenciesAmountsRoundingsTest#testAccessRoundingsForCustomCurrencies_Explicit_Null)
[SUCCESS] 4.2.7 Ensure NullPointerException is thrown for 'Monetary.getRounding((RoundingContext) null)'.(AccessingCurrenciesAmountsRoundingsTest#testAccessRoundingsWithMonetaryContext_Null)
[SUCCESS] 4.2.7 Ensure correct MonetaryRounding returned for a mathematical RoundingQuery.(AccessingCurrenciesAmountsRoundingsTest#testAccessRoundingsWithRoundingContext)
[SUCCESS] 4.2.7 Test if Monetary provides all ISO related entries similar to java.util.Currency.(AccessingCurrenciesAmountsRoundingsTest#testAllISOCurrenciesAvailable)
[SUCCESS] 4.2.7 Test if Monetary provides all locale related entries similar to java.util.Currency.(AccessingCurrenciesAmountsRoundingsTest#testAllLocaleCurrenciesAvailable)
[SUCCESS] 4.2.7 Ensure a default MonetaryAmountFactory is available.(AccessingCurrenciesAmountsRoundingsTest#testAmountDefaultType)
[SUCCESS] 4.2.7 Ensure correct query function, Monetary.getAmountFactories should return factoryfor explicit acquired amount types.(AccessingCurrenciesAmountsRoundingsTest#testAmountQueryType)
[FAILED]  4.2.7 Ensure amount factories are accessible for all types available in Monetary.(AccessingCurrenciesAmountsRoundingsTest#testAmountTypesInstantiatable):
java.lang.NoClassDefFoundError: Could not initialize class org.javamoney.tck.TCKTestSetup
	at org.javamoney.tck.tests.AccessingCurrenciesAmountsRoundingsTest.testAmountTypesInstantiatable(AccessingCurrenciesAmountsRoundingsTest.java:260)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)

[FAILED]  4.2.7 Ensure amount classes to test are setup and registered/available in Monetary.(AccessingCurrenciesAmountsRoundingsTest#testAmountTypesProvided):
java.lang.NoClassDefFoundError: Could not initialize class org.javamoney.tck.TCKTestSetup
	at org.javamoney.tck.tests.AccessingCurrenciesAmountsRoundingsTest.testAmountTypesProvided(AccessingCurrenciesAmountsRoundingsTest.java:235)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)

[SUCCESS] 4.2.7 Test if Monetary provides correct ISO related entries similar to java.util.Currency.(AccessingCurrenciesAmountsRoundingsTest#testCorrectISOCodes)
[SUCCESS] 4.2.7 Test if Monetary provides correct locale related entries similar to java.util.Currency.(AccessingCurrenciesAmountsRoundingsTest#testCorrectLocales)
[SUCCESS] 4.2.7 Test if Monetary provides customized locale identified currencies.(AccessingCurrenciesAmountsRoundingsTest#testCustomCurrencies)
[SUCCESS] 4.2.7 Access custom roundings and ensure correct functionality.(AccessingCurrenciesAmountsRoundingsTest#testCustomRoundings)
[SUCCESS] 4.2.7 Ensure MonetaryException is thrown for accessing invalid named rounding.(AccessingCurrenciesAmountsRoundingsTest#testCustomRoundings_Foo)
[SUCCESS] 4.2.7 Ensure NullPointerException is thrown for Monetary.getRounding((String) null).(AccessingCurrenciesAmountsRoundingsTest#testCustomRoundings_Null)
[SUCCESS] 4.3.1 Access Conversion to term currency code XXX for all providers that support according conversion, ifavailable a non-null CurrencyConversion must be provided.(MonetaryConversionsTest#testConversionsAreAvailable)
[SUCCESS] 4.3.1 Access Conversion by query to term currency XXX for all providers that support according conversion, ifavailable a non-null CurrencyConversion must be provided.(MonetaryConversionsTest#testConversionsAreAvailableWithQuery)
[SUCCESS] 4.3.1 Access and test conversion using the default provider chain.(MonetaryConversionsTest#testDefaultConversion)
[SUCCESS] 4.3.1 Access and test the default conversion provider chain.(MonetaryConversionsTest#testDefaultProviderChainIsDefined)
[SUCCESS] 4.3.1 Access and test the default conversion provider chain, by accessing a defaultCurrencyConversion for term CurrencyUnit CHF.(MonetaryConversionsTest#testDefaultProviderChainIsDefinedDefault)
[SUCCESS] 4.3.1 Access and test the default conversion provider chain, by accessing a defaultCurrencyConversion for term currency code CHF.(MonetaryConversionsTest#testDefaultProviderChainIsDefinedDefault2)
[SUCCESS] 4.3.1 Access and test the default conversion provider chain, by accessing a defaultCurrencyConversion for ConversionQuery.(MonetaryConversionsTest#testDefaultProviderChainIsDefinedDefaultWithContext)
[SUCCESS] 4.3.1 Test if all ExchangeRateProvider instances returns valid ProviderContext.(MonetaryConversionsTest#testProviderMetadata)
[SUCCESS] 4.3.1 Test if all CurrencyConversion instances returns valid ConversionContext, accessed by currency code.(MonetaryConversionsTest#testProviderMetadata2)
[SUCCESS] 4.3.1 Test if all CurrencyConversion instances returns valid ConversionContext, accessed by ConversionQuery/currency code.(MonetaryConversionsTest#testProviderMetadata2WithContext)
[SUCCESS] 4.3.1 Test if all CurrencyConversion instances returns valid ConversionContext, accessed by CurrencyUnit.(MonetaryConversionsTest#testProviderMetadata3)
[SUCCESS] 4.3.1 Test if all CurrencyConversion instances returns valid ConversionContext, accessed by ConversionQuery/CurrencyUnit.(MonetaryConversionsTest#testProviderMetadata3WithContext)
[SUCCESS] 4.3.1 Ensure at least one conversion provider is available, TestRateProvider must be present.(MonetaryConversionsTest#testProvidersAvailable)
[SUCCESS] 4.3.1 Bad case: Access invalid ExchangeRateProvider, expect MonetaryException thrown, using default provider chain.(MonetaryConversionsTest#testUseInvalidProvider)
[SUCCESS] 4.3.1 Bad case: Access invalid ExchangeRateProvider, expect MonetaryException thrown, using explicit provider.(MonetaryConversionsTest#testUseInvalidProviderWithinChain)
[SUCCESS] 4.3.3 Test access of Conversion Rates, using TCK provided rate provider.(ExchangeRatesAndRateProvidersTest#testAccessKnownRates)
[SUCCESS] 4.3.3 Test access to exchange rates from TestRateProvider, using target CUrrencyUnit.(ExchangeRatesAndRateProvidersTest#testAccessKnownRatesAndContext)
[SUCCESS] 4.3.3 Test access to exchange rates from TestRateProvider, using target currency code.(ExchangeRatesAndRateProvidersTest#testAccessKnownRatesWithCodes)
[SUCCESS] 4.3.3  Test access to conversion rates, including known factor, using TestRateProvider.(ExchangeRatesAndRateProvidersTest#testAccessKnownRatesWithCodesAndContext)
[SUCCESS] 4.3.3 Test access to conversion rate for currency codes, using default provider.(ExchangeRatesAndRateProvidersTest#testAccessRates_IdentityRatesWithCodes)
[SUCCESS] 4.3.3 Test access to identity conversion rate for CurrencyUnits, using default provider(ExchangeRatesAndRateProvidersTest#testAccessRates_IdentityRatesWithUnits)
[SUCCESS] 4.3.3 Test access to conversion rate for CurrencyQuery, using default provider.(ExchangeRatesAndRateProvidersTest#testAccessRates_IdentityRatesWithUnitsAndContext)
[SUCCESS] 4.3.3 Bad case: try accessing exchange rates with invalid base currency code.(ExchangeRatesAndRateProvidersTest#testInvalidUsage_InvalidSourceCurrency)
[SUCCESS] 4.3.3 Bad case: try accessing exchange rates with null ConversionQuery.(ExchangeRatesAndRateProvidersTest#testInvalidUsage_InvalidSourceCurrencyAndContext)
[SUCCESS] 4.3.3 Bad case: try accessing exchange rates with invalid term currency code.(ExchangeRatesAndRateProvidersTest#testInvalidUsage_InvalidTargetCurrency)
[SUCCESS] 4.3.3 Bad case: try accessing exchange rates with null base currency code.(ExchangeRatesAndRateProvidersTest#testInvalidUsage_NullSourceCurrency)
[SUCCESS] 4.3.3 Bad case: try accessing exchange rates with null base CurrencyUnit.(ExchangeRatesAndRateProvidersTest#testInvalidUsage_NullSourceCurrencyUnit)
[SUCCESS] 4.3.3 Bad case: try accessing exchange rates with null term currency code.(ExchangeRatesAndRateProvidersTest#testInvalidUsage_NullTargetCurrency)
[SUCCESS] 4.3.3 Bad case: try accessing exchange rates with null term CurrencyUnit.(ExchangeRatesAndRateProvidersTest#testInvalidUsage_NullTargetCurrencyUnit)
[SUCCESS] 4.3.3 Ensure additional ConversionQuery data is passed correctly to SPIs.(ExchangeRatesAndRateProvidersTest#testPassingOverConversionContextToSPIs)
[SUCCESS] 4.3.2 Test successful conversion for CHF -> FOO, using TestRateProvider.(ConvertingAmountsTest#testConversion)
[SUCCESS] 4.3.2 Test correct ExchangeRate is returned for CHF -> FOO, using TestRateProvider.(ConvertingAmountsTest#testConversionComparedWithRate)
[SUCCESS] 4.3.2 Bad case: Access CurrencyConversion with a CurrencyUnit==null, ensure NullPointerException is thrown.(ConvertingAmountsTest#testNullConversion1)
[SUCCESS] 4.3.2 Bad case: Access CurrencyConversion with a currency code==null, ensure NullPointerException is thrown.(ConvertingAmountsTest#testNullConversion2)
[SUCCESS] 4.3.2 Bad case: Try CurrencyConversion to an inconvertible (custom) currency (FOOANY), ensure CurrencyConversionException is thrown.(ConvertingAmountsTest#testUnsupportedConversion)
[SUCCESS] 4.3.4 Test correct rate evaluation for different conversion provider chains, with historic rates.(ProviderChainsTest#testCorrectRateEvaluationInChainHistoric)
[SUCCESS] 4.3.4 Test correct rate evaluation for different conversion provider chains.(ProviderChainsTest#testCorrectRateEvaluationInChain_diffProviders)
[SUCCESS] 4.3.4 Test correct rate evaluation for different conversion provider chains, with duplicate provider entries.(ProviderChainsTest#testCorrectRateEvaluationInChain_sameProviders)
[SUCCESS] 4.3.4 Test availability of TCK provided providers.(ProviderChainsTest#testTCKRateChainAvailability)
[SUCCESS] 4.4.3 Ensures for each locale defined by DecimalFormat.getAvailableLocales() a MonetaryFormats.getAmountFormat(AmountFormatQuery) returns a formatter.(FormattingMonetaryAmountsTest#testAmountStyleOf)
[SUCCESS] 4.4.1 Formats amounts using all available locales.(FormattingMonetaryAmountsTest#testFormattingIsIndependentOfImplementation)
[SUCCESS] 4.4.3 Ensures for each locale defined by DecimalFormat.getAvailableLocales() a MonetaryAmountFormat instance is provided.(FormattingMonetaryAmountsTest#testGetAmountFormat)
[SUCCESS] 4.4.3 Ensures for each locale defined by DecimalFormat.getAvailableLocales() a MonetaryFormats.isAvailable(Locale) is true.(FormattingMonetaryAmountsTest#testGetAvailableLocales)
[SUCCESS] 4.4.3 Ensures all Locales defined by DecimalFormat.getAvailableLocales() are available for monetary formatting.(FormattingMonetaryAmountsTest#testLocalesSupported)
[SUCCESS] 4.4.1 Ensures the system.s default locale is supported for MonetaryAmountFormat.(FormattingMonetaryAmountsTest#testNoDepOnAmountImplementation)
[SUCCESS] 4.4.2 Test formats and parses (round-trip) any supported amount type for each supported Locale, using different format queries.(FormattingMonetaryAmountsTest#testParseDifferentStyles)
[SUCCESS] 4.4.1 Test formats and parses (round-trip) any supported amount type for each supported Locale.(FormattingMonetaryAmountsTest#testParseIsIndependentOfImplementation)
[SUCCESS] 4.4.1 Test formats and parses (round-trip) any supported amount type for each supported Locale, checks results for different currencies(FormattingMonetaryAmountsTest#testParseWithDifferentCurrencies)

JSR 354 TCK, version 1.0 Summary
------------------------------------------

TOTAL TESTS EXECUTED : 233
TOTAL TESTS SKIPPED  : 0
TOTAL TESTS SUCCESS  : 222
TOTAL TESTS FAILED   : 11

-- JSR 354 TCK  finished --

All dependencies show the 1.0.1-RC0 versions of the moneta, moneta-core, moneta-convert-ecb and moneta-convert-imf are used.

Comment by otaviojava [ 31/Jul/15 ]

Werner.
Maybe you did a little confusion with physical module with logical module.

Example:
The Swing module is together physically, in the same folder (java.desktop), but on different logical module, in different package.

If you look to swing module, all classes are on the same physical module:

But we have different packages, in other words, different logical module:

  • javax.swing.border
  • javax.swing.colorchooser

The same thing will happen with javax.money, it stay together, all core, just there is logic module, it will split by package.
The initial proposal to split the core to the exchange rate is because neither we and OpenJDK team can't provide, support, ensure availability, perform maintenance, etc. on third service such IMF or ECB service.
So we will propose just the core to him, following the openjdk standard, using logical modules, in other words, just the core modularized by packages.

Referencies:

Comment by keilw [ 31/Jul/15 ]

Conversion is a logical module. Its need is determined if an application requires multiple currencies or just one.
ECB and IMF providers are not "Third Party", they are developed by us, the EG. We don't provide the rates, but with currency codes, timezones, etc. that keeps happening all the time in JDK. Java also checks for new versions every time you call it on the web, so "Update Checks" are the daily bread of the JDK for a long time. Convert without at least one or two default providers is worthless, thus you can either chose to use conversion or not.

Java SE (as of 8) comes in 3 different profiles. With Java 9 while it's still a while till the final release there will be more such profiles.
And a Modular Moneta will offer at least 2 profiles, too. "Minimal" (essentially moneta-core) and "Full" including the convert feature.

And in future versions of the API similar to pioneers (JSR 361, 363) some packages like "javax.money.convert" could well be optional, but compared to Moneta (~700kb for the 1.0 JAR) the API JAR is only around 10% in size.

The Minimal profile of Moneta is only around 200kb while the Full profile is comparable to 1.0 in size.

Comment by otaviojava [ 31/Jul/15 ]

Are you sure about this?
Did the EC make the service or the client side of the IMF and ECB?
I believe just the client, isn't?
I means, if the either site of IMF or ECB down, how do you will give support to it, do you have available guarantee?
Do you have guarantee of this service will never change the serialization?
If the IMF or ECB give a wrong rate how do we will fix it?

Comment by keilw [ 31/Jul/15 ]

The EC is not making anything but vote on it
And since both IMF and ECB providers are part of the RI, of course the EG

Both IMF and ECB are international institutions. Exchange rates are used by Millions of business transactions around the globe. While not necessarily real time (that's where Third Party commercial providers may come into play, just like people with special demands may buy Azul's JVM rather than using the free Oracle or OpenJDK versions) they are business-critical, so don't worry about them going away. Both institutions are involved in say keeping Greece from bankruptcy. Should a country like Greece do go bust then the JDK had to be updated in the past to handle new currencies. Same if new states arise like Kosovo, South Sudan or East Timor.

Similar to Unicode CLDR which is updated on a regular basis and used by every Java version, their services have to be reliable. In the unlikely event any of them changed something drastically, we should have CI servers running such Integration tests (as opposed to simply calling them Unit Tests right now) on a daily basis, even if there is no Git push. If a test fails, we'll get notified and may offer a fix pack.
It certainly won't happen as often as new critical security flaws in Java or other languages are found

Similar to ECB (being composed of most EU countries and their National Banks) IMF is an International body, related to the UN: http://www.ngohandbook.org/index.php?title=International_Monetary_Fund_(IMF)_and_NGOs
The UN may sometimes be easy to block by just one veto member (somewhat similar to Oracle in the JCP ) but it won't just "go away" nor do its websites or services.

Comment by otaviojava [ 01/Aug/15 ]

I have never told different stuff about it, both IMF and ECB are respected institution in all the world.
But Does it mean their software can't take a bug, infrastructure problem, etc.?
Java, linux is also are a respected in the all world, so I can say: do they cannot have a bug or problem?
The fact is, if there is a problem on MonetaryAmount implementation either we or the openjdk team can fix it.
But when it there a problem on the third service, how do we can fix it?

Comment by keilw [ 01/Aug/15 ]

This entire thread belonged to https://java.net/jira/browse/JAVAMONEY-140 because it has nothing to do with the TCK itself, so I'll answer there and if you have any more feedback please do there, too

Comment by keilw [ 01/Aug/15 ]

Most arguments and comments actually belong to the Conversion module





[JAVAMONEY-147] Fix broken Unit tests in RI Created: 27/Aug/15  Updated: 27/Aug/15  Resolved: 27/Aug/15

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

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

Tags: implementation, test, test_issue

 Description   

Two unit tests fail for some time building Moneta (and Moneta-BP)

Failed tests: 
  DefaultMonetaryAmountFormatSymbolsTest.shouldPrintMonetaryAmount:66 expected [R$ 10,00] but found [R$10,00]
  DefaultMonetaryAmountFormatSymbolsTest.shouldQueryFromMonetaryAmount:77 expected [R$ 10,00] but found [R$10,00]

Needs to be fixed in both.



 Comments   
Comment by otaviojava [ 27/Aug/15 ]

Fixed





[JAVAMONEY-120] Inconsistency of "convert" elements in RI Created: 15/May/15  Updated: 23/Aug/15  Resolved: 23/Aug/15

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

Type: Task Priority: Minor
Reporter: keilw Assignee: otaviojava
Resolution: Fixed 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-122 "Clone" conversion classes currently ... Sub-task Resolved otaviojava  
Tags: design, inconsistency, naming, package

 Description   

I noticed, ExchangeRateType, DefaultExchangeRate (though not a public class) or ExchangeRateBuilder are all in the top "moneta" package,
while a new class HistoricConversionQueryBuilder was created in a "convert" package of the RIs.

All of them refer to API elements like javax.money.convert.ConversionContext. For simplification "internal.convert" classes were put to the root package, but at least one was newly created in its own package. This is confusing and should be resolved.

Either by removing HistoricConversionQueryBuilder and "convert" (by making it @deprecated and putting a copy to the other place except for non-public elements) or moving the mentioned classes to "convert" instead (also treating them the same at least for an SP or two)



 Comments   
Comment by otaviojava [ 15/May/15 ]

I did: https://github.com/JavaMoney/jsr354-ri/pull/104

I moved this class to the root of moneta, if you have advise, please let me know by PR.

Comment by keilw [ 15/May/15 ]

This should be properly discussed, please don't RUSH anything before a consensus is reached where to locate ALL conversion-relevant classes.
As internal also contains a convert sub-package, there is some reason behind adding this to the root package, too and relocate classes previously in a wrong place.

Those MUST however be kept in both places so code that's using Moneta 1.0 doesn't break (deprecated it at least for several versions, if it was already part of the JDK we'd be in a bigger pickle here )

Comment by otaviojava [ 23/Aug/15 ]

Done





Inconsistency of "convert" elements in RI (JAVAMONEY-120)

[JAVAMONEY-122] "Clone" conversion classes currently in Moneta root package Created: 15/May/15  Updated: 23/Aug/15  Resolved: 23/Aug/15

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

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

Tags: conversion, design, modules

 Description   

To improve modularization of RI elements, the following classes in the root package of Moneta should be "cloned" into convert

  • ExchangeRateType
  • ExchangeRateBuilder
  • DefaultExchangeRate (though not a public class, but it goes with above)

To avoid breaking existing code, they must remain in their original location at least till some versions (if we wait for the first MR or not has to be discussed) down the road, but be @deprecated pointing to the new types to use.



 Comments   
Comment by keilw [ 17/May/15 ]

ExchangeRateType is practically unused. Mostly by JUnit tests (which are in fact already in the "convert" sub-package ) so started by cloning it, but leaving old version @deprecated for the time being.

Comment by keilw [ 23/Aug/15 ]

@otaviojava do you know what to do here?
It's mainly a transition task to get them out of the core package where they never belonged, but keep them there @deprecated (to give users time to migrate before they'll be purged from the wrong place in a future version)

Comment by otaviojava [ 23/Aug/15 ]

Yes, I got it.
clone and deprecated:

  • ExchangeRateType
  • ExchangeRateBuilder
  • DefaultExchangeRate

There is not unitary test on ExchangeRateBuilder, so I will spend a little more time to create in this history.

Comment by otaviojava [ 23/Aug/15 ]

Merged on RI and RI-BP





[JAVAMONEY-128] Mark any structural change with @since Created: 29/May/15  Updated: 23/Aug/15  Resolved: 23/Aug/15

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
Fix Version/s: 1.1

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

Tags: javadoc

 Description   

Any structural changes like new methods or classes in the RIs beyond 1.0 must be clearly marked with a @since JavaDoc tag.

JUnit tests could be the only exception, but operative code shall be tagged properly.



 Comments   
Comment by otaviojava [ 23/Aug/15 ]

Merged in the master

Comment by keilw [ 23/Aug/15 ]

Hasn't been done for Moneta-BP

Comment by otaviojava [ 23/Aug/15 ]

working in that.

Comment by otaviojava [ 23/Aug/15 ]

Done on Moneta-BP





[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 Open
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-123] QueryConfig for MonetaryAmount does not honor params. Created: 15/May/15  Updated: 20/Aug/15  Resolved: 20/Aug/15

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
Fix Version/s: 1.1

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


 Description   

Looking at the following test:

MonetaryAmount am = Monetary.getAmountFactory(
                MonetaryAmountFactoryQueryBuilder.of()
                .set(RoundingMode.DOWN)
                .setPrecision(256).build()
        ).setCurrency("CHF").setNumber(1234.5678).create();
        assertEquals(256, am.getContext().getPrecision());
        assertEquals(RoundingMode.DOWN, am.getContext().get(RoundingMode.class));

The MonetaryContext should return a precision = 256 and RoundingMode = RoundingMode.DOWN. This must be the case, since it is a Money instance to be created. The behaviour should be similar for all the following cases:

  • Money is set explicitly or implicitly as target type
  • Also if RoundingMode is set only, it should be honored by the Money factory
  • Also if precision is set it should honored by the Money factory

We have to think about the behaviour, if a factory is taken that may not honor all params. For optimal transparency I would suggest to add all uninterpretable para:ms with a special prefiye such as .ignored, e.g.

myFoo=fooValue -> ignored.myFoo=fooValue

This may also allow us to enable additional mechanisms as identified by the customers using the RI.



 Comments   
Comment by otaviojava [ 20/Aug/15 ]

Fixed on:
https://github.com/JavaMoney/jsr354-ri/pull/121





Make Moneta Modular (JAVAMONEY-137)

[JAVAMONEY-139] Format Module Created: 16/Jul/15  Updated: 31/Jul/15  Resolved: 31/Jul/15

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

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


 Comments   
Comment by keilw [ 31/Jul/15 ]

For 1.x this seems unreasonable. Core RI classes like Money directly reference MonetaryAmountFormat so a default format is quite baked into the heart of Moneta. (unlike "convert" which has no top level dependencies )
Additional Format providers may of course be created in extension modules like javamoney-lib, etc. but breaking "format" out of the core module seems harder and unlike conversion (which some use cases just won't require) display of amounts is required in almost every case.





[JAVAMONEY-131] Fail to override load-properties for ExchangeRateProviders in javamoney.properties. Created: 22/Jun/15  Updated: 22/Jun/15  Resolved: 22/Jun/15

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
Fix Version/s: 1.1

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

Windows 7


Issue Links:
Relates
relates to JAVAMONEY-133 Align naming of RI and RI-BP elements Resolved

 Description   

The constructor of AbstractECBRateProvider contains loader.loadDataAsync(...). This is the same method-call as in DefaultLoaderService case ONSTARTUP: loadDataAsync. Hence when trying to override this property in javamoney.properties by setting

{1}

load.AbstractECBRateProvider=NEVER
it will still run loadDataAsync.

This might also be the case for the other ExchangeRateProviders.

See http://stackoverflow.com/questions/30931631/overriding-properties-in-javamoney-properties for more details.



 Comments   
Comment by otaviojava [ 22/Jun/15 ]

PR created to solve this problem:
https://github.com/JavaMoney/jsr354-ri/pull/113
Just waiting all tests run to merge it.

Comment by keilw [ 22/Jun/15 ]

It's nice, to fix it in Moneta, but ensure, to solve exactly the same way in Moneta-BP (and where necessary create tests in both )

Comment by otaviojava [ 22/Jun/15 ]

The solution was just remove a configuration that was wrongly put on constructor.
The code was merged.

Comment by otaviojava [ 22/Jun/15 ]

I found the problem on the class LoadableResource.
https://github.com/JavaMoney/jsr354-ri/pull/116
The class is difficult to create test, maybe we should create an issues to refactor the class and create a testable design.

Comment by otaviojava [ 22/Jun/15 ]

Finally fixed:
https://github.com/JavaMoney/jsr354-ri/pull/116
https://github.com/JavaMoney/jsr354-ri-bp/pull/17





[JAVAMONEY-132] Misplaced *Producer interfaces in SPI Created: 22/Jun/15  Updated: 22/Jun/15  Resolved: 22/Jun/15

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

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

Tags: design

 Description   

The @FunctionalInterface (in the SE 8+ RI) MonetaryAmountProducer and implementing types were mis-placed in SPI, but similar to such elements in JDK 8 they should be in the function package.



 Comments   
Comment by otaviojava [ 22/Jun/15 ]

Merged to the two implementation.





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

[JAVAMONEY-133] Align naming of RI and RI-BP elements Created: 22/Jun/15  Updated: 22/Jun/15  Resolved: 22/Jun/15

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

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

Issue Links:
Relates
relates to JAVAMONEY-131 Fail to override load-properties for ... Resolved
Tags: design, naming, namingconvention

 Description   

The bug raised for AbstractECBRateProvider highlights an even bigger problem. Moneta has multiple classes like ECBAbstractRateProvider while Moneta-BP only contains one AbstractECBRateProvider.
Although being package local, people use and review them or file bugs, so the names should match both each other and an agreed naming scheme.



 Comments   
Comment by otaviojava [ 22/Jun/15 ]

PR created, https://github.com/JavaMoney/jsr354-ri-bp/pull/13
Just waiting all tests run to merge it.

Comment by otaviojava [ 22/Jun/15 ]

Merged





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

[JAVAMONEY-130] Remove ExchangeRateException Created: 29/May/15  Updated: 30/May/15  Resolved: 30/May/15

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

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

Two private methods in "internal.convert" use a newly created ExchangeRateException. This looks like an overkill. MonetaryException looks sufficient to communicate with the outside.



 Comments   
Comment by otaviojava [ 29/May/15 ]

You are right. I am creating a PR to do that.

Comment by otaviojava [ 30/May/15 ]

removed





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

[JAVAMONEY-126] Remove MonetaryRoundedFactory unless BP is possible/feasible Created: 29/May/15  Updated: 30/May/15  Resolved: 30/May/15

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

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


 Description   

Unless porting it to Moneta-BP is both doable and feasible, the additional type MonetaryRoundedFactory (and helper elements like MonetaryRoundedFactory shall be removed to another module, e.g. javamoney-lib or "shelter".

Furthermore, the name looks wrong. It says "this interface is used to create

{@link RoundedMoney}

using the

{@link MonetaryOperator}

as rounding."
RoundedMoney has plenty of() factory methods already, so why complicate things by adding some pseudo API into the RI?
Maybe RoundedMonetary needs further arguments or functionality to its of() methods, looking at patterns we see in other places (both JSR 354 and the JDK) potentially even a RoundedMoney.Builder was imaginable, if that really adds benefit over what the RI offers today, but a whole new API in the RI sounds disruptive.

So if it really returns nothing but RoundedMoney it should either go into RoundedMoney like a builder pattern, or at least be called RoundedMoneyFactory not MonetaryRoundedFactory. Furthermore what's currently called MonetaryRoundedFactory as interface contains static methods, that's incompatible with Java 6/7 and the BP.
In the end DefaultMonetaryRoundedFactory returns

RoundedMoney.of(requireNonNull(number), requireNonNull(currencyUnit), roundingOperator);

so adding requireNonNull() etc. to its of() static factory is probably best instead of overengineering the RI here.



 Comments   
Comment by keilw [ 29/May/15 ]

Almost every type like MonetaryRoundedFactory and helper elements like MonetaryRoundedFactory, RoudingMonetaryAmountOperator, etc. should be package-local (fixed that already so they're also not exposed ) even if they remained in the RI(s).
MonetaryOperators and methods like round() shall be the only publicly visible addition to Moneta and Moneta-BP.

Similar in javamoney-lib, though there it could be more visible if there's a need for it.

Comment by otaviojava [ 29/May/15 ]

I think I don't understand you, an implementation to Java 8 that hasn't resources to Java 8, does it make sense? If you will avoid exclusive resource to Java 8, why not just have an RI implementation whose the minimum resource is Java 7? And what the real sense about this?
Once I told to you, we already had this discussion and the only reason to we have two implementation is to reach all targets. If not what is the goal to have two projects with:

  • Two different code
  • Two points to fix bugs
  • Two points to improve the code

For a developer who uses Java 7, just use the BP implementation, because the Java 8 resource doesn't make sense to him. But if the developer want use the Java 8 with resource of Java 7, to it just use the Java 7, the Java 7 code runs on Java 8. But for who want to use Java 8 with Java 8 resoures we have the RI implementation that gonna to OpenJDK some day.

The other problem is explain to Java community why we removed the Java 8 resources because cannot remove on Java 7, once we have two different projects.

http://java.dzone.com/articles/looking-java-9-money-and

And Yes Java 7 is different of Java 8 on to many aspects.

Comment by otaviojava [ 29/May/15 ]

If you really want it, I think we should to reopen our discussion to havê two implementations to just have one.

Comment by keilw [ 29/May/15 ]

Sorry but that train's gone, there are 2 RIs with 1.0 Final, can't rewrite history. And e.g. a project I'm helping in the financial sector relies on Java 7. They won't migrate to Java 8 either until maybe Java EE 8 is out. And so do Thousands of clients and solutions around the world. Not to forget Android.

Neither of this needs to be in the RI. Only to add a method MonetaryOperators.round() that simply wraps RoundedMoney.of() adds little value. If one needed this, just make it available in "javamoney-lib" or similar. Both RI and RI-BP are to implement and demonstrate aspects of the API. Not every single implementation of either of these has to go into the RI.

Comment by otaviojava [ 29/May/15 ]

Werner:
First: Android is not Java
Second: I understand your case, but just use the BP. Sorry but once it was already added is not fair to remove it once we have two project.

Comment by keilw [ 29/May/15 ]

There is no release since 1.0, so nothing was properly added.
Fixing a bug in existing classes, even say a fromMinor method is OK, but throwing in stuff that belongs to a "sandbox" or "incubator" is not correct and detremental to an official standard people wish to trust. It undermines compatibility.

Comment by otaviojava [ 29/May/15 ]

The compatibility is a old version run on new version and not new version on old version. It's not happen even on OpenJDK. If you try run Java 8 code compiled on Java 7 will throw the UnsupportedClassVersionError

Comment by keilw [ 29/May/15 ]

There's nothing in this issue that is incompatible with the BP or Java 7 However, just look at every JSR, there is no RI that throws random new things that have nothing to do with implementing the API (which is done) into a "update" of the RI. See 107 that's what they got EHCache for or commercial Hazelcast products Almost every element in "function" is properly hidden now, so we have to decide if MonetaryOperator.rounding() makes sense there or not.
different for the other issue that was purely SE 8 and standalone nor used by anything outside unit tests.

Hence that is subject to lib-incubator. If this shows a proper use-case it may graduate to javamoney-lib. Don't think there's a need in the RI, but it clearly isn't before 2.0 or a MR of the actual JSR.

Comment by otaviojava [ 29/May/15 ]

There is just test because all new improvement should have test, but there are people on community that are using this improvement. Your motivation is just about the back part. Peoples like Brazilian government start to using this resource.
I believe more people will use it after a good cookbook.

if it is random stuff why the community like it?
If you want to remove, maybe open form to vote it.

Comment by keilw [ 29/May/15 ]

It's not about removing, there should have been a vote about adding stuff like that in the first place.
By properly hiding internals they may use MonetaryOperators.* (with "Snapshot" methods at their own risk, they may change at any time before a proper release, what isn't on JCenter or MavenCentral does not exist ) but the HistoricStuff is in a proper place now, the Shelter, from where it may be used and if there's true demand it may become part of javamoney-lib.

Comment by otaviojava [ 29/May/15 ]

Werner all PR that I did represents SouJava, was accepted to other Java Expert Group, almost always you. Once to remove I believe we can do the same strategy or just talk to vote.

Comment by keilw [ 29/May/15 ]

Every JSR not just this one is about compatibility. The package-space "org.javamoney.moneta" is equally shared between both RIs. this is how the JSR was submitted and approved by the EC. Neither SouJava nor JUG-Chennai or any single JUG, country or company can "throw things into the RI" just because they feel they need it (probably just for a project or two ;-O) I'm confident, OpenJDK won't just let you add a new class to Java 8 or 9 for a single company or country. It has to comply with compatibility requirements by the JCP and wider Java Community. And adding something in a single place does not comply with this compatibility requirement. E.g. Stephen keeps updating JodaTime on a regular basis, but I don't recall a change like even adding a single convenience method (say ofDecade() since Java SE 8 was released there. So any other JavaMoney proect (like lib, shelter, etc.) is perfectly fine for regular changes, as long as they are also propagated to public repos now and then. RI and API cannot just be updated on a daily or weekly basis.

Comment by otaviojava [ 29/May/15 ]

Reading the title "Remove MonetaryRoundedFactory unless BP is possible/feasible" if I put it on BP, it can stay right?

Comment by keilw [ 29/May/15 ]

The RI also must not expose unnecessary things. All prior {MonetaryOperator}} implementations in the Moneta package were local, so should be everything there that does not come out of MonetaryOperators, if the same is applied to the BP and the EG/Spec Lead approves this new method on MonetaryOperators, it may be added.

Comment by otaviojava [ 30/May/15 ]

Werner removed this class





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

[JAVAMONEY-127] Remove HistoricConversionQueryBuilder unless BP is possible/feasible Created: 29/May/15  Updated: 30/May/15  Resolved: 29/May/15

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: None
Fix Version/s: 1.1

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


 Description   

Same here, HistoricConversionQueryBuilder should either be migrated to Moneta-BP or removed from Moneta into another module, e.g. javamoney-lib and its child modules or javamoney-shelter.



 Comments   
Comment by keilw [ 29/May/15 ]

HistoricConversionQueryBuilder contains almost 90% of the code based on java.time elements in Java SE 8.
So the first decision and most important decision is what sense it made for the RI.

Either moving it to "javamoney-calc" or a new module like "javamoney-convert" under https://github.com/JavaMoney/javamoney-lib would solve the issue. The minimum requirement for such module is Java SE 8 (right now the "jdkVersion" of the parent POM is "1.8", so Java 8 is the default unless a "BP" module diverted from that) anyway.

The only way to keep this in Moneta* (if there was a consensus it makes sense for the RI ) would be to add a complete set of methods with java.util.Date (a mandatory part of Java SE 8, it won't go away and is even ME 8 Embedded compliant ) offering exactly the same results. Then this sub-set (which offers backward compatibility in Moneta) could be transferred into Moneta-BP. Otherwise the class shall go to javamoney-lib.

Comment by otaviojava [ 29/May/15 ]

@werner this discussion is not finished, please rollback your code.
Other point, how in all project open source, you should open the pull request to other people merge it.

There is nothing to roll back, but actually such ideas should be discussed in the Incubator/shelter first, not thrown into the RI. Similar to above they add no value to the current RI nor are they compatible with the BP. Moneta and Moneta-BP are drop-in replacements with an identical signature. So before anything gets added, the TCK should have a proper signature checker similar to JSR 107, etc.

Comment by keilw [ 29/May/15 ]

Moved (unused) elements to new module lib-incubator.
They may graduate there for the right place, either javamoney-lib or other.

Comment by otaviojava [ 29/May/15 ]

Werner we need to have one way to find out exchange rate from historical, so why we have implementation with historic? I believe the best strategy is to have on both implementation if not ECB-HIST or ECB-90 no make sense.

Comment by keilw [ 29/May/15 ]

Well the thing is, ConversionQueryBuilder belongs to API.
Adding some convenience methods to RIs is one thing, that could hide under a SP of the RIs without a full MR of the JSR, but a change to API or SPI elements is more sensitive. We also didn't just "throw" Bitcoin into the RI despite many people like to use it around the world
So these ideas should improve in the Shelter, maybe both Digital Currencies and other conversion-related improvements could next graduate to javamoney-lib.

Comment by otaviojava [ 29/May/15 ]

It's the problem, the get on ConversionQueryBuilder accept Object, anything, using this class, I know what class I should use to find out on historic.

Comment by keilw [ 29/May/15 ]

One would not do this without interfering with the SPI and that's a no-go without a full change to the JSR via MR or another JSR.
See java.util,locale or even Currency, extension mechanisms may be thought of later, but at the moment this is not some minor cosmetic thing.
The lib-incubator class works without tampering with the API.

Comment by otaviojava [ 29/May/15 ]

Once we accept the Object in the method, we need to say to user which object we take care to find out by historic. The best strategy that I thought was this wrapper class to make the API more friendly. This way we know the class that works on implementation.
Or this or we need to take all objects possible or throw an exception when we don't work with one specific class.

Comment by keilw [ 30/May/15 ]

Wrapper seems OK, but it does not belong to RI. lib-incubator is where I moved the class. Until a new type of javamoney-lib may arise. (javamoney-calc may not be the right module based on what's there)





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

[JAVAMONEY-129] Add ofMinor to all affected *Money classes of Moneta-BP Created: 29/May/15  Updated: 29/May/15  Resolved: 29/May/15

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: None
Fix Version/s: 1.1

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

Tags: backport, java7

 Description   

While it's "only" a convenience method around

return of(BigDecimal.valueOf(amountMinor, factionDigits), currency);

the ofMinor() methods are currently missing from Moneta-BP.
Please add them, there is no SE 8 dependendy here.

Keep in mind, both implementations share exactly the same package namespace "org.javamoney.moneta" so what happens in this package must behave identical even for "convenience methods" like this one.



 Comments   
Comment by otaviojava [ 29/May/15 ]

PR created: https://github.com/JavaMoney/jsr354-ri-bp/pull/7





[JAVAMONEY-121] Relocate new classes implementing MonetaryOperator to "function" Created: 15/May/15  Updated: 15/May/15  Resolved: 15/May/15

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.1
Fix Version/s: None

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

Tags: design, inconsistency, naming, package

 Description   

DefaultMonetaryOperatorFactory, PrecisionContextRoundedOperator, PrecisionScaleRoundedOperator or ScaleRoundedOperator were all thrown into the top level "moneta" package after 1.0 (they're therefore not in the Final release)

Similar to other *Operator types already in 1.0 (and to match the similar package in JDK) please move them into function and don't create new ones in the root package of Moneta.

Since there's just one API element, javax.money has this on a root level, but with several functions already there, we should use and respect this package structure in the RI.



 Comments   
Comment by otaviojava [ 15/May/15 ]

Werner, the DefaultMonetaryOperatorFactory is just used on DefaultMonetaryOperatorFactory and it is default package. I prefer to keep in on the root, maybe rename it to RoundedMoneyMonetaryOperatorFactory.

Comment by otaviojava [ 15/May/15 ]

I created the PR: https://github.com/JavaMoney/jsr354-ri/pull/105





[JAVAMONEY-119] Java 8 RI is not fully backward compatible. Created: 14/May/15  Updated: 15/May/15  Resolved: 14/May/15

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
Fix Version/s: 1.1

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

Java 8 RI is not fully backward compatible, since the spi.base subpackage is not contained. Though the functionality is moved into the default methods of the Java 8 API, removing the artifacts in the Java 8 RI breaks compatibility. So the base package should be added in the 8 RI as well, but should be deprecated to prevent future use of it.



 Comments   
Comment by otaviojava [ 14/May/15 ]

Anatole,
I really don't understand why this.
You created class that should not use on RI, and just on BP.
We have a new classes that are deprecated.
If you need it on back part, just put it on BP, make sense this way.
It's like a machine with auto-destruction button.

Comment by otaviojava [ 14/May/15 ]

@anatole
I really belive the best strategy is put it on a library.
WDYT?

Comment by atsticks [ 15/May/15 ]

Then the customer moving from 7 to 8 typically has to add an additional compatibility library. I do not know any framework that does it that way, because it is cumbersome and not customer-friendly.

+1

Especially extension points like BaseMonetaryAmount look very useful and nobody would expect or look for them in "some library". IMHO they belong to at least RI SPI if not even (in future versions or MR ) the actual API.

Comment by atsticks [ 15/May/15 ]

Just adding a comment and then removing the things I have committed is not the way I suppose things should work. There are reasonable aspects here to be considered and this is still a community project, When there is no consensus more discussions are needed. That was obvious in this case...

Comment by otaviojava [ 15/May/15 ]

Sorry Anatole.
I just created the PR, https://github.com/JavaMoney/jsr354-ri/pull/103 and said it is on discussion, so it's not to merget now just after the discussion, on this ticket.
Really sorry, I expressed myself very badly.





[JAVAMONEY-105] Moneta not building as Bundle Created: 13/May/15  Updated: 14/May/15  Resolved: 14/May/15

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

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: Maven, osgi

 Description   

Moneta after switching to 1.0.1-SNAPSHOT would no longer build as (OSGi) "bundle". So I briefly adjusted the POM to <packaging>jar</packaging>.
This is a temporary workaround, and since OSGi will become even more important for Java 9 and Jigsaw (the two are supposed to be compatible in some way) plus every OSGi container (Eclipse, Apache,...) relies on a proper bundle signature of not just the API but all artifacts, this must be resolved before 1.0.1 can be wrapped-up.

Strangely it works perfectly well for moneta-bp meaning, their POMs must differ not just for the JVM or artifactIds...



 Comments   
Comment by otaviojava [ 13/May/15 ]

The fact the OpenJDK explore OSGI as study doesn't mean it will use the same behavior of OSGI.
http://openjdk.java.net/projects/penrose/
http://openjdk.java.net/projects/jigsaw/
The fact of the project doesn't run without OSGI not means it will not run with JIGSAWS.
So it isn't high priority.

Comment by keilw [ 13/May/15 ]

Regardless Moneta must continue what 1.0 already provided. That version was fully OSGi compliant, so the likes of Spring/Pivotal or others don't have to do this themselves (with those weird "com.springsource.log4j" or similar bundles ) We care about Jigsaw modularization of the RI when the time comes. If you find a Java 9 preview version stable and reliable enough, feel free to test it, but in a separate branch/fork please.

Comment by keilw [ 14/May/15 ]

Applied proper bundle plugin config





[JAVAMONEY-114] DefaultMonetaryCurrenciesSingletonSpi does nopt honor explicit provider list. Created: 14/May/15  Updated: 14/May/15  Resolved: 14/May/15

Status: Resolved
Project: javamoney
Component/s: API
Affects Version/s: 1.0
Fix Version/s: None

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   

The DefaultMonetaryCurrenciesSingletonSpi class registered by default does not honor any explicit provider list passed when accessing currencies, e.g.

getCurrencies(CurrencyQuery) with a query containing an explicit provider name, will nevertheless return all currencies from all providers.

Since it is part of the API it can be mitigated by providing an overriding implementation as part of the RIs.






[JAVAMONEY-118] Use ordering of Bootstrap component if no conversion default chain is configured Created: 14/May/15  Updated: 14/May/15  Resolved: 14/May/15

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
Fix Version/s: 1.1

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

Use ordering of Bootstrap component if no conversion default chain is configured. The spec defines how a default chain can be configured, but does not define, what should be done, if no such config is available. Basically it is useful to fallback on the default order provided by the BootStrap mechanism. Fortunately this mechanism can implement a priority ordering based on the @Priority annotations, which is a far better and more flexible approach.






[JAVAMONEY-117] CompoundRateProvider returns null and may be more robust Created: 14/May/15  Updated: 14/May/15  Resolved: 14/May/15

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
Fix Version/s: 1.1

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   

The current implementation of compound providers has several deficiencies:

  • it returns null, if no rate was found, though the API requires to throw a ConversionException.
  • malbehaving providers may stop evaluation of the provider chain.

The code should be corrected to the solution below:

for (ExchangeRateProvider prov : this.providers) {
            try {
                if (prov.isAvailable(conversionQuery)) {
                    ExchangeRate rate = prov.getExchangeRate(conversionQuery);
                    if (Objects.nonNull(rate)) {
                        return rate;
                    }
                }
            } catch (Exception e) {
                Logger.getLogger(getClass().getName()).log(Level.WARNING,
                        "Rate Provider did not return data though at check before data was flagged as available," +
                                " provider=" + prov.getContext().getProviderName() + ", query=" + conversionQuery);
            }
        }
        throw new CurrencyConversionException(conversionQuery.getBaseCurrency(), conversionQuery.getCurrency(), null,
                "All delegate prov iders failed to deliver rate, providers=" + this.providers +
                        ", query=" + conversionQuery);





[JAVAMONEY-116] ConversionProviders do not work for historic data Created: 14/May/15  Updated: 14/May/15  Resolved: 14/May/15

Status: Closed
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
Fix Version/s: 1.1

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   

E.g. see at the following example:

provider = MonetaryConversions.getExchangeRateProvider("IDENT", "ECB", "ECB-HIST");
        System.out.println("CHF -> EUR (today) -> " + provider.getExchangeRate(ConversionQueryBuilder.of()
                .setBaseCurrency("EUR").setTermCurrency("CHF")
                .set(LocalDate.of(2008, 1, 8)).build()));
        System.out.println("CHF -> EUR (1.8.2008) -> " + provider.getExchangeRate(ConversionQueryBuilder.of()
                .setBaseCurrency("EUR").setTermCurrency("CHF")
                .set(LocalDate.of(2008, 1, 8)).build()));

Seems that the whole mapping of LocalDate to historic data items does not work. Both ECB-HIST, as well as IMF-HIST providers are affected.



 Comments   
Comment by otaviojava [ 14/May/15 ]

@anatole it's not wrong.
Look the error:

org.javamoney.moneta.internal.convert.ExchangeRateException: There is not exchange on day 2008-01-08 to rate to  rate on ECBRateProvider.

That is right, the ECBRateProvider just has the three recent days, so there is not this date to find.

But when you use just the ECB-HIST it's ok.

ExchangeRateProvider provider = MonetaryConversions.getExchangeRateProvider("ECB-HIST");
Comment by atsticks [ 14/May/15 ]

Sorry, my fault. Wifi was slow and I had to wait longer until the rates are coming back. Thanks for all helping checking this nevertheless





[JAVAMONEY-108] Error when Retrieve information from EBC provider Created: 13/May/15  Updated: 14/May/15  Resolved: 13/May/15

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
Fix Version/s: 1.1

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


 Description   

When the classes that are ECB exchange rate provider (ECBHistoric90RateProvider, ECBCurrentRateProvider, ECBHistoricRateProvider) try recovery information. Returns a NumberFormatException.



 Comments   
Comment by otaviojava [ 13/May/15 ]

This bug was fixed on both RI and BP. It happened because sometime when the currency hasn't information, sometime has NaN, not a number, and sometime is blank. When had a NaN launch the exception.





[JAVAMONEY-109] Error to most recent date on Exchange Rate[ECB] Created: 14/May/15  Updated: 14/May/15  Resolved: 14/May/15

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
Fix Version/s: 1.1

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


 Description   

This error happed when execute any ECB, europe central bank exchange rate provider, and has three days without information about the currency, such a holiday. So when you try find the currency information to this currency will return a NPE.



 Comments   
Comment by otaviojava [ 14/May/15 ]

The solution was find out the currency information most recent.





[JAVAMONEY-111] Error to join currency information and specific data[ECB] Created: 14/May/15  Updated: 14/May/15  Resolved: 14/May/15

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
Fix Version/s: 1.1

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


 Description   

This error happen when executes any ECB, Europe central bank exchange rate provider, when has one day without information, what happened is the day, that should hasn't information, gets the currency information of the day after. For example reading the table the November 10th and 11th, but the 10th hasn't information when read it will join with November 11th resulting on wrong information.



 Comments   
Comment by otaviojava [ 14/May/15 ]

Once splited to a especialist class to read information we create specific test to take and fix this problem.





[JAVAMONEY-112] Problem to find out data from Historic[ECB, IMF] Created: 14/May/15  Updated: 14/May/15  Resolved: 14/May/15

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
Fix Version/s: 1.1

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


 Description   

We have a problem when try find out a specific data from an exchange rate provider. The problem is the data isn't retrieve from query. So all implementation just returns a NPE, without no information what happened exactly.



 Comments   
Comment by otaviojava [ 14/May/15 ]

The solution was read this information about the data to retrieve when there isn't information to specified data get an better exception. So the Java developer will understand that doesn't exist a currency information to the specified data on the query.





[JAVAMONEY-107] Fix bug on toString parser Created: 13/May/15  Updated: 14/May/15  Resolved: 13/May/15

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
Fix Version/s: 1.1

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


 Description   

Fix problem on toString method on all implementations when MonetaryAmount is null.






[JAVAMONEY-110] Error to most recent date on Exchange Rate[IMF] Created: 14/May/15  Updated: 14/May/15  Resolved: 14/May/15

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
Fix Version/s: 1.1

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


 Description   

This error happed when execute any IMF, international monetary fund rate provider, and has three days without information about the currency, such a holiday. So when you try find the currency information to this currency will return a NPE.



 Comments   
Comment by otaviojava [ 14/May/15 ]

Make the IMF found the most recent





[JAVAMONEY-115] DefaultExchangeRate does not include term currency in toString Created: 14/May/15  Updated: 14/May/15  Resolved: 14/May/15

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
Fix Version/s: 1.1

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

DefaultExchangeRate does not include term currency in toString



 Comments   
Comment by otaviojava [ 14/May/15 ]

Fixed on this PR: https://github.com/JavaMoney/jsr354-ri/pull/101





[JAVAMONEY-113] Invalid result for remainder, when passig 1L Created: 14/May/15  Updated: 14/May/15  Resolved: 14/May/15

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
Fix Version/s: 1.1

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   

Assuming any amount with a fraction part, applying remainder(1) will result in returning the same amount, which is invalid, it should return the fraction part in such a case:

MonetaryAmount amnt = ...; // e.g. 1.5
amnt = amnt.remainder(1);  // returns 1.5, instead of 0.5

Problem is an invalid optimazation:

public Money remainder(long divisor) {
        if (divisor == 1L) {
            return this;
        }
        return remainder(BigDecimal.valueOf(divisor));
}

-> FastMoney may be affected as well (to be verified).



 Comments   
Comment by atsticks [ 14/May/15 ]

divideAndRemainder is affected by a similar issues as well, will fix both.





[JAVAMONEY-100] DefaultLoaderService should use Executor with daemon threads Created: 18/Apr/15  Updated: 13/May/15  Resolved: 13/May/15

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
Fix Version/s: 1.1

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


 Description   

Actually the impl uses Executors.newCachedThreadPool() with standard threads causing SE programs not to terminate.

Example:

public static void main(String[] args) {
        MonetaryAmount eur = MonetaryAmounts.getDefaultAmountFactory().setCurrency("EUR").setNumber(BigDecimal.TEN).create();
        System.out.println(eur);
        MonetaryAmount usd = eur.with(MonetaryConversions.getConversion("USD"));
        System.out.println(usd);
    }


 Comments   
Comment by keilw [ 18/Apr/15 ]

We should try to fix this on the 1.0 branch: https://github.com/JavaMoney/jsr354-ri/tree/1.0 and merge via pull-request into master.
Same for ri-bp assuming that's equally affected.

Comment by otaviojava [ 21/Apr/15 ]

Updating the code:


MonetaryAmount eur = Monetary.getDefaultAmountFactory().setCurrency("EUR").setNumber(BigDecimal.TEN).create();
        System.out.println(eur);
        MonetaryAmount usd = eur.with(MonetaryConversions.getConversion("USD"));
        System.out.println(usd);
Comment by keilw [ 21/Apr/15 ]

Would be perfect to do this 1.0 first and merge back into master (though "cherry-picking" or manual merge seems necessary after recent parallel changes) and same for ri-bp.

Comment by otaviojava [ 21/Apr/15 ]

Sorry @keilw.
I did first in master.
When I saw was too late.

https://github.com/JavaMoney/jsr354-ri/pull/78

Comment by otaviojava [ 13/May/15 ]

solved and in the master





[JAVAMONEY-58] Currency data source URL for IsoCurrencyOnlineProvider needs updating Created: 12/Aug/13  Updated: 12/May/15  Resolved: 12/May/15

Status: Closed
Project: javamoney
Component/s: Library: JavaMoney Extensions
Affects Version/s: None
Fix Version/s: 1.1

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


 Description   

The URL which specifies the location of the currency source in net.java.javamoney.ri.ext.provider.iso.IsoCurrencyOnlineProvider#loadCurrencies method is no longer valid. The current source is:

http://www.currency-iso.org/dam/isocy/downloads/dl_iso_table_a1.xml

which results in an Http 404.

I believe the replacement should be:

http://www.currency-iso.org/dam/downloads/table_a1.xml


 Comments   
Comment by keilw [ 12/Aug/13 ]

As a first step I'm fixing the URL to the new version. Where CI server (Jenkins) would also allow us to run Integration Tests there should be some for external services such as this to flag whenever this or another URL changes in future.
Will externalize it into a properties file for easier maintenance, but ultimate customization should be possible similar to Java 7+ Currency class:
>Users can supersede the Java runtime currency data by creating a properties file named <JAVA_HOME>/lib/currency.properties. The contents of the properties file are key/value pairs of the ISO 3166 country codes and the ISO 4217 currency data >respectively. The value part consists of three ISO 4217 values of a currency, i.e., an alphabetic code, a numeric code, and a minor unit. Those three
>ISO 4217 values are separated by commas. The lines which start with '#'s are considered comment lines. For example,...

either we'd use this file or introduce another one or two additional files (not too many, otherwise it gets confusing and we'd have a Spring-like maze of properties

Comment by keilw [ 13/Aug/13 ]

Changed, those URLs are now loaded from a properties file, but neither of the URLs looks like it gets results from parsing
I suppose the 404 error was mainly a browser-based observation, so there may be something left to do.

Debug information (if log level is changed appropriately or System.out/IDE-debugging used) tells currencies is empty, while the list of countries contains 249 of them.

Comment by paulkmoore [ 13/Aug/13 ]

Werner, the mapping also appears to have changed - I guess they did this as part of the "move"...

From the comments in code the previous feed appears to be structured as follows:

// <ISO_CCY_CODES>
// <ISO_CURRENCY>
// <ENTITY>AFGHANISTAN</ENTITY>
// <CURRENCY>Afghani</CURRENCY>
// <ALPHABETIC_CODE>AFN</ALPHABETIC_CODE>
// <NUMERIC_CODE>971</NUMERIC_CODE>
// <MINOR_UNIT>2</MINOR_UNIT>
// </ISO_CURRENCY>
// ...
// </ISO_CCY_CODES>

Whereas the new feed is as follows:

<ISO_4217 Pblshd="">
	<CcyTbl>
		<CcyNtry>
			<CtryNm>AFGHANISTAN</CtryNm>
			<CcyNm>Afghani</CcyNm>
			<Ccy>AFN</Ccy>
			<CcyNbr>971</CcyNbr>
			<CcyMnrUnts>2</CcyMnrUnts>
		</CcyNtry>
		<!--snip-->
	</CcyTbl>
</ISO_4217>
Comment by keilw [ 02/Sep/14 ]

This has been open for a while, does it work now?

Comment by keilw [ 12/May/15 ]

Should be dealt with here: https://github.com/JavaMoney/javamoney-lib/issues

Comment by keilw [ 12/May/15 ]

Delegated to GitHub issues. Not in scope of JSR any more.





[JAVAMONEY-73] Create JEP for Java 9+ Created: 02/Sep/14  Updated: 12/May/15  Resolved: 29/Jan/15

Status: Closed
Project: javamoney
Component/s: API, Impl: RI, Misc: JCP Administration
Affects Version/s: None
Fix Version/s: None

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

Issue Links:
Cloners
is cloned by JAVAMONEY-103 Create JEP for Java 10+ Open
Tags: java9, jdk

 Description   

As discussed, it seems like a good idea to have an OpenJDK committer file a JEP for monetary improvements in a future Java version. Whether that's 9, 10 or later should be determined by Oracle and the OpenJDK program. but without filing it, that's never going to happen.



 Comments   
Comment by atsticks [ 29/Jan/15 ]

Was done. Oracle does not want to add the JSR to JDK 9. With Jigsaw we might end up as a JDK module later...





[JAVAMONEY-85] Tag releases when something is published to repo Created: 06/Feb/15  Updated: 12/May/15  Resolved: 12/May/15

Status: Resolved
Project: javamoney
Component/s: API, Impl: RI, Test: TCK
Affects Version/s: 0.9
Fix Version/s: 1.0

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: deployment, release

 Description   

At least the milestone build 1.0-RC1 was published to MavenCentral, but no corresponding release tags could be found in any of the GitHub repositories.
It would be cumbersome to roll everything back and re-create such tag for 1.0-RC1, but for the current build 1.0-RC2 all necessary tags shall be created ASAP and ideally in future let's try to do this BEFORE publishing



 Comments   
Comment by keilw [ 12/May/15 ]

Was done for 1.0 both as tag and (for possible fixes or maintenance) branch.





[JAVAMONEY-102] Fix inconsistent naming of *ReadingHandler classes Created: 04/May/15  Updated: 04/May/15  Resolved: 04/May/15

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: None
Fix Version/s: 1.1

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

Tags: design, naming, namingconvention

 Description   

While every element related to particular exchange rate providers like IMF, ECB,... look like IMFRateProvider, etc. two new classes

RateECBReadingHandler and RateIMFReadingHandler break that naming scheme. Even for "internal" classes or packages, this causes confusion and makes listing or finding such types harder. Except for a good reason like AbstractIMFRateProvider they should all follow a similar naming scheme like "IMF*" or "ECB*".



 Comments   
Comment by otaviojava [ 04/May/15 ]

Fixed





[JAVAMONEY-101] MonetaryAmount supports Minor and Major part Created: 24/Apr/15  Updated: 04/May/15  Resolved: 04/May/15

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

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

Tags: naming

 Description   

Looking with Joda-money we can work with the minor values, the cents, and the major parts. It`s really simple to do because we already have this information from Currency[1].
http://docs.oracle.com/javase/7/docs/api/java/util/Currency.html#getDefaultFractionDigits()

This information is really useful to many banks and gateways of payment such MOIP and Paypal.

So this issue has the goal to add:

  • getAmountMajor - Gets the amount in major units as an Long.
  • getAmountMinor - Gets the amount in minor units as an Long.
  • getMinorPart - Gets the minor part of the amount.

In the MonetaryAmount interface.

And in the construtor add of implementation:

  • ofMajor - Obtains an instance of Money from an amount in major units.
  • ofMinor - Obtains an instance of Money from an amount in minor units.

obs: obviously the name will be different to a more suitable.



 Comments   
Comment by atsticks [ 25/Apr/15 ]

We already have / can implement such a feature AFAIK as part of MonetaryFunctions implemented as MonetaryQuery. So I dont see any need for extending the MonetaryAmount interface. BTW we also discussed exactly these things in early stage of the JSR and decided to not add every kind of requirement to the already big MonetaryAmount interface.

Comment by otaviojava [ 26/Apr/15 ]

Looking to NIO2, we have a class that extract some information about the interface Path, this way doesn't break the interface with more information.
I will do the same think to extract these information, using a class to extract then, this way, I will not modify the API, just the RI.

https://docs.oracle.com/javase/tutorial/essential/io/fileAttr.html

Comment by keilw [ 26/Apr/15 ]

Well take JSR 310, that's all RI of an anorexic API, so the ofMillis() or similar you see there might be comparable.
I would however not do it in the RI, but start in Shelter, that's what it is there for. To play with new ideas before they are ready and mature to potentially go to another module like Lib or RI

Comment by otaviojava [ 26/Apr/15 ]

@werner, @anatole you are right, this funcionality already exist in MonetaryUtil, I am just put more documentation and example in this code.

Comment by keilw [ 26/Apr/15 ]

OK, so you plan to use this ticket for documentation, otherwise it might be a case of "Won't fix"?

Comment by keilw [ 04/May/15 ]

Only subject to RI

Comment by otaviojava [ 04/May/15 ]

Thank you @werver to remember me.
The solution was create a MonetaryOperator to extract this value.





[JAVAMONEY-99] Mismatch between Name and ID in DefaultRoundingProvider Created: 09/Apr/15  Updated: 24/Apr/15  Resolved: 09/Apr/15

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

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

Tags: naming

 Description   

Moneta's DefaultRoundingProvider exposes a public constant DEFAULT_ROUNDING_ID and the internal collection is also named roundingsIds but the public method is then called getRoundingNames(). This is a slight mismatch, ideally it should be resolved. At the very least by changing the constant to DEFAULT_ROUNDING_NAME, or renaming the getter. (internals that are hidden in the code matter less )






[JAVAMONEY-97] Merge static accessor classes in javax.money package Created: 28/Mar/15  Updated: 09/Apr/15  Resolved: 09/Apr/15

Status: Resolved
Project: javamoney
Component/s: API
Affects Version/s: None
Fix Version/s: 1.0

Type: Task 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: factory, refactoring

 Description   

See https://java.net/projects/javamoney/lists/jcurrency_mail/archive/2015-03/message/35



 Comments   
Comment by keilw [ 09/Apr/15 ]

Is there anything open here?





[JAVAMONEY-98] AbstractAmountBuilder#create() broken error messages Created: 03/Apr/15  Updated: 03/Apr/15  Resolved: 03/Apr/15

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

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

All



 Description   

Calling the create() method with invalid state produces a broken error message.

MonetaryAmountFactory<?> factory = MonetaryAmounts.getDefaultAmountFactory();
factory.create(); // broken
factory.setCurrency(USD).create(); // broken
factory.setNumber(12.99).create(); // broken

In each of the 3 invalid calls to create above, we get a message like:
javax.money.MonetaryException: Cannot of FastMoney instance: missing currency.
at org.javamoney.moneta.spi.AbstractAmountBuilder.create(AbstractAmountBuilder.java:53)

Not only is the grammar incorrect, but the type is hard-coded to FastMoney, even though a correct call to create() ultimately returns an instance of Money.






[JAVAMONEY-96] Backport Created: 20/Mar/15  Updated: 31/Mar/15  Resolved: 31/Mar/15

Status: Resolved
Project: javamoney
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0

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


 Description   

Umbrella Task for Backport






[JAVAMONEY-90] Try to find a workable solution for Snapshots Created: 11/Feb/15  Updated: 31/Mar/15  Resolved: 31/Mar/15

Status: Closed
Project: javamoney
Component/s: General: Build and quality management
Affects Version/s: 0.9
Fix Version/s: None

Type: Task 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: build, snapshot

 Description   

As of now the Snapshot repository formerly at CloudBees is inactive or deleted. The current Travis CI build runs the default Maven job and cannot find a Snapshot version of the API once the "head" of the API project changes:
317[ERROR] Failed to execute goal on project moneta: Could not resolve dependencies for project org.javamoney:moneta:jar:1.0-SNAPSHOT: Could not find artifact javax.money:money-api:jar:1.0-SNAPSHOT in sonatype-snapshots (https://oss.sonatype.org/content/repositories/snapshots/) -> [Help 1]

Ideally whenever at least API, RI and TCK change, a Snapshot repo like https://oss.sonatype.org/content/repositories/snapshots/ shall be automatically deployed to, otherwise some substitute like Cloudbees, as long as POM settings allow Maven to find it.



 Comments   
Comment by atsticks [ 31/Mar/15 ]

Changed to jfrog/BintrAY build.





[JAVAMONEY-84] Consolidate license files in API Created: 06/Feb/15  Updated: 31/Mar/15  Resolved: 31/Mar/15

Status: Resolved
Project: javamoney
Component/s: API
Affects Version/s: 0.9
Fix Version/s: 1.0

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

Tags: documentation

 Description   

The API repo currently contains 2 license HTML files, while the readme text says (see LICENCE.html)
This should be addressed, ideally renaming the applicable one to LICENSE.html or otherwise changing readme.



 Comments   
Comment by atsticks [ 11/Feb/15 ]

when going final we need both licences an evaluation licence and an implementation licence. If to check the details with heather. For comparison you can looks at other JSRs...

Comment by keilw [ 11/Feb/15 ]

So aside from leaving "Public Review" in that file, why did JSR 107 only have 1 LICENSE.txt https://github.com/jsr107/jsr107spec
The detail page points to just 1 license https://jcp.org/en/jsr/detail?id=107
Under "Specification", that PDF has the correct "Final" stage btw, which ideally should also be in the GitHub repo. No 2nd PDF here either, so why would 354 require 2 PDFs?

This template https://jcp.org/aboutJava/communityprocess/speclead/final-license.txt also mentioned on JCP.org is applicable to the Final release of the JSR. We just mentioned that one
>2.18 Please provide a description of the business terms for the Specification
which is why I'm wondering why there should be 2 in the repo. Aside from a very unuseful format that never renders properly in any browser. TXT seemed far easier to read here.

Even special cases like CDI have exceptional "dual-licensing" of everything including the Spec, it contains 2 Maven tool-chains to create a license PDF either for the Spec or Apache License, but aside from that it's always just one, not two license files per distribution.

Comment by atsticks [ 31/Mar/15 ]

Readme adapted.





[JAVAMONEY-95] Check headers for license, etc. Created: 05/Mar/15  Updated: 07/Mar/15  Resolved: 07/Mar/15

Status: Resolved
Project: javamoney
Component/s: API
Affects Version/s: 0.9
Fix Version/s: 1.0

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

Tags: license

 Description   

Some headers of sources shifted between RI and API occasionally refer to the RI license. Try to review and where possible change it
(there are of course other JSRs that don't care about this at all, thus it is of minor priority )






[JAVAMONEY-94] Avoid "magic strings" when building MonetaryAmountFormat Created: 13/Feb/15  Updated: 05/Mar/15  Resolved: 05/Mar/15

Status: Resolved
Project: javamoney
Component/s: API, Impl: RI
Affects Version/s: 0.9
Fix Version/s: 1.0

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

Issue Links:
Related
is related to JAVAMONEY-92 Format pattern for decimal digits is ... Resolved
Tags: format

 Description   

A recently mentioned case about formatting

MonetaryAmountFormat format = MonetaryFormats.getAmountFormat(
    AmountFormatQueryBuilder.of(Locale.GERMANY)
       .set(CurrencyStyle.SYMBOL)
       .set("pattern", "#,##0.00### ¤")
       .build());

showed, a "magic string" "pattern" is required to get the correct MonetaryAmountFormat. In case of a typo e.g. "Pattern" instead of "pattern" this would fail. Similar to e.g. JDK Calendar.Builder and other places it would be best if the API contains at least a minimal set of default keys already. Allowing

MonetaryAmountFormat format = MonetaryFormats.getAmountFormat(
    AmountFormatQueryBuilder.of(Locale.GERMANY)
       .set(CurrencyStyle.SYMBOL)
       .set(PATTERN, "#,##0.00### ¤")
       .build());

The best place for such constant seems either MonetaryAmountFormat, MonetaryFormats or AmountFormatContext.



 Comments   
Comment by keilw [ 13/Feb/15 ]

That issue showed the usage of a "magic string", the problem raised is however unrelated.

Comment by keilw [ 13/Feb/15 ]

Just an example how similar key constants are declared e.g. by Android Robotium Instrumentation

public static final String  REPORT_KEY_IDENTIFIER 

If included in the status or final bundle sent to an IInstrumentationWatcher, this key identifies the class that is writing the report. This can be used to provide more structured logging or reporting capabilities in the IInstrumentationWatcher. 

Constant Value:   "id" 
Comment by atsticks [ 05/Mar/15 ]

We can add a constant to the implementation, but not the API. The field is strictly RI specific.

Comment by keilw [ 05/Mar/15 ]

Guess it's better to put it there than nowhere. JSRs like 310 badly mix API and RI, so it is impossible to tell where it defines such pattern constants and definitions in that case CurrencyStyle is also in Moneta, so it's consequent to do so with these constants.

Comment by atsticks [ 05/Mar/15 ]

Added AmountFormatParams constant class to moneta.formats package, including Javadocs describing the options.





[JAVAMONEY-92] Format pattern for decimal digits is ignored Created: 12/Feb/15  Updated: 05/Mar/15  Resolved: 05/Mar/15

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

Type: Bug Priority: Minor
Reporter: vitomirs Assignee: atsticks
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVAMONEY-94 Avoid "magic strings" when building M... Resolved

 Description   

When an amount is printed, decimal digits are always formatted according to the number of the fraction digits defined for the current currency. If pattern is set to show more decimal digits, like in the next example, additional digits are truncated in the output. For example, amount '1234.5678 EUR' will be printed as '1.234,56 EUR', because EUR currency has 2 as number of the fraction digits.

MonetaryAmountFormat format = MonetaryFormats.getAmountFormat(
    AmountFormatQueryBuilder.of(Locale.GERMANY)
        .set(CurrencyStyle.SYMBOL)
        .set("pattern", "#,##0.00### ¤")
        .build());

However, some prices use more decimal digits (like gasoline). Usually, items which are often sold in bigger quantities (tens or hundreds) have a price defined with more decimal digits.

From my brief look at the sources, AmountNumberToken.print() method has three lines which override behavior set by the pattern.

int digits = amount.getCurrency().getDefaultFractionDigits();
this.formatFormat.setMinimumFractionDigits(digits);
this.formatFormat.setMaximumFractionDigits(digits);

IMHO, these lines should be removed. Then, if pattern is not set formatting will be done with regard to number of the fraction digits for the currency. If pattern is set, it should have higher priority and number of the displayed decimal digits should be as defined by the pattern.



 Comments   
Comment by keilw [ 12/Feb/15 ]

Will have a look. Especially Digital currencies whether Bitcoin or others often use an even bigger number of fraction digits

Comment by atsticks [ 05/Mar/15 ]

Your analysis was correct. Thanks very much for your input.





[JAVAMONEY-79] Difficult to add a markup to FX rate Created: 14/Oct/14  Updated: 05/Mar/15  Resolved: 05/Mar/15

Status: Resolved
Project: javamoney
Component/s: API
Affects Version/s: 0.9
Fix Version/s: 1.0

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


 Description   

There doesn't seem to be a way to pass in a complete context to the exchange rate mechanism. Specifically whenever we do an FX we would like to add a markup to the rate provided by whatever provider we have setup. For example in the following snippet "markup_rate" is not carried over to the rate provider that is when getExchangeRate(ConverstionQuery q) is called we're unable to extract the passed in value.

MonetaryOperator convertTo(CurrencyUnit currency, BigDecimal forexMarkupPercentage) {
        return getConversion(
                ConversionQueryBuilder.of()
                        .setTermCurrency(currency)
                        .set("markup_rate", forexMarkupPercentage)
                        .build());
    }

Note that this "markup_rate" is something that we expect to what to change on every call and not setup once for the provider.



 Comments   
Comment by atsticks [ 29/Jan/15 ]

Will have a look at it. There were some bugfixes on the AbstractContext, which may have been the root cause that the value was not passed over to the provider.

Comment by atsticks [ 29/Jan/15 ]

Accessing an ExchangeRateProvider does not pass the ConversionQuery, whereas accessing a Conversion passes the query to ExchangeRateProvider.getCurrencyConversion(ConversionQuery);
It is in the reponsibility of the ExchangeRateProvider implementation to store the currency query or its attributes supported.

If the issue is due to the fact that a value is not stored correctly in the query itself it might be solved on the current head.

If the issues is more related to the first part, can you please give as a hint which functions you exactly are calling? THANKS!

Comment by atsticks [ 05/Mar/15 ]

Also done by otavio.





[JAVAMONEY-89] Remove setTimestamp/getTimestamp from API Created: 11/Feb/15  Updated: 18/Feb/15  Resolved: 18/Feb/15

Status: Resolved
Project: javamoney
Component/s: API
Affects Version/s: None
Fix Version/s: 1.0

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

On Contexts the methods

Long getTimestampMillis();
LocalDateTime getTimestamp();

are there. Nevertheless most of the historic data providers logically operate on LocalDate. So my proposal is to remove this methods completely, since

  • In most cases the model of timestamp is not appropriate, or requires additional timezone data to be added.
  • additional implementations will probably define their own logic, how things have to be passed/configured
  • Java 7/8 obviously have different date/time APIs.
  • the current context/builder/query mechanism is flexible enough to accommodate more advanced use cases similar to them

So the methods related to timestamps are to be removed on AbstractContext, AbstractQuery (where they never belonged), AbstractContextBuilder and AbstractQueryBuilder.

The overall impact on the RI is not much, and it helps to model the date information in the providers more accurately.



 Comments   
Comment by otaviojava [ 18/Feb/15 ]

Done by Anatole.
Now historical implementation need to take care this information.





[JAVAMONEY-91] Rename all getXXXContext() to getContext() Created: 11/Feb/15  Updated: 18/Feb/15  Resolved: 18/Feb/15

Status: Resolved
Project: javamoney
Component/s: API
Affects Version/s: None
Fix Version/s: 1.0

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

Rename all getXXXContext() to getContext() in
MonetaryAmount, CurrencyUnit, MonetaryAmountFormat, CurrencyConversion, ExchangeRateprovider



 Comments   
Comment by otaviojava [ 18/Feb/15 ]

This task was made by Anatole.
I review all these classes and are ok.





[JAVAMONEY-87] Remove ECBHistoric90RateProvider class Created: 10/Feb/15  Updated: 18/Feb/15  Resolved: 18/Feb/15

Status: Resolved
Project: javamoney
Component/s: API
Affects Version/s: 0.9
Fix Version/s: 1.0

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


 Description   

The only difference between the history classes on ECB exchange rate, [1] and [2], are the days to retrieve information.
My sugestion is remove the ECBHistoric90RateProvider and the days quantities will defined in javamoney.properties with key: ECBHistoricRateProvider.dayQuantity

[1]https://github.com/JavaMoney/jsr354-ri/blob/master/src/main/java/org/javamoney/moneta/convert/internal/ECBHistoric90RateProvider.java
[2]https://github.com/JavaMoney/jsr354-ri/blob/master/src/main/java/org/javamoney/moneta/convert/internal/ECBHistoricRateProvider.java



 Comments   
Comment by otaviojava [ 11/Feb/15 ]

The estrategy will the ECBHistory be configurable with default value of 90 days, but you can to change this days quantities by system properties such others API in Java SE.

Ex: https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ForkJoinPool.html

So:
org.javamoney.moneta.convert.internal.ECBHistoricRateProvider.days

Comment by keilw [ 11/Feb/15 ]

Actually if we already bound the API and JSR to use SE 8 and JSR 310 it should be its TimeUnit, not the one concurrency-based ForkJoin uses?
(unless of course we want to make life easier for a possible BackPort, where java.util.concurrent.TimeUnit exists, but its "clone" java.time.temporal.TimeUnit doesn't )

Comment by keilw [ 11/Feb/15 ]

If the 90 means 90 days, then it seems appropriate to use a TemporalAmount to model that or where necessary concrete classes (if they offer any additional value, otherwise better store it as TemporalAmount in our code )
A Java 7 BP would likely have to work around this by using the long representation of duration in "millis" like everywhere else.

Comment by otaviojava [ 18/Feb/15 ]

The ECB services has not a good API to extract just we need. So or 90 days or all values.
The best option is keep it the code without change.





[JAVAMONEY-93] incorrect exception in case when you try to create a money object for Double.NaN Created: 12/Feb/15  Updated: 14/Feb/15  Resolved: 14/Feb/15

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

Type: Bug Priority: Minor
Reporter: volna80 Assignee: otaviojava
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If you try to create a money object from Double.NaN. It throws NumberFormatException from a BigDecimal instead of expected ArithmeticException

Caused by: java.lang.NumberFormatException
at java.math.BigDecimal.<init>(BigDecimal.java:494)
at java.math.BigDecimal.<init>(BigDecimal.java:383)
at java.math.BigDecimal.<init>(BigDecimal.java:806)
at org.javamoney.moneta.spi.ConvertBigDecimal$2.getDecimal(ConvertBigDecimal.java:49)

A patch to fix.

diff --git a/src/main/java/org/javamoney/moneta/spi/ConvertBigDecimal.java b/src/main/java/org/javamoney/moneta/spi/ConvertBigDecimal.java
index 94b73b6..7d0cb27 100644
— a/src/main/java/org/javamoney/moneta/spi/ConvertBigDecimal.java
+++ b/src/main/java/org/javamoney/moneta/spi/ConvertBigDecimal.java
@@ -42,7 +42,7 @@ public enum ConvertBigDecimal {
@Override
BigDecimal getDecimal(Number num) {
double d = num.doubleValue();

  • if (d == Double.NaN || d == Double.POSITIVE_INFINITY || d == Double.NEGATIVE_INFINITY) {
    + if (Double.isNaN(d) || Double.isInfinite(d)) { throw new ArithmeticException("NaN, POSITIVE_INFINITY and NEGATIVE_INFINITY cannot be used as " + "parameters for monetary operations."); }

    diff --git a/src/test/java/org/javamoney/moneta/FastMoneyTest.java b/src/test/java/org/javamoney/moneta/FastMoneyTest.java
    index b2b9440..dae27fb 100644

      • a/src/test/java/org/javamoney/moneta/FastMoneyTest.java
        +++ b/src/test/java/org/javamoney/moneta/FastMoneyTest.java
        @@ -1137,4 +1137,9 @@ public class FastMoneyTest { assertEquals(m, m2); }

+ @Test(expectedExceptions = ArithmeticException.class)
+ public void testNan()

{ + FastMoney m = FastMoney.of(Double.NaN, "XXX"); + }

+
}



 Comments   
Comment by otaviojava [ 14/Feb/15 ]

@volna80 thank you for submit the path.
I am working in this issue.

Comment by otaviojava [ 14/Feb/15 ]

I saw and you did the PR, I am just put the same test in others options.

Comment by otaviojava [ 14/Feb/15 ]

@volna80 did the PR with the correction.
I just added the tests to others implementations.





[JAVAMONEY-88] Money.of() and FastMoney.of() documented wrongly in JavaDoc and tests Created: 10/Feb/15  Updated: 11/Feb/15  Resolved: 11/Feb/15

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

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: method

 Description   

There are several places in Moneta where JavaDoc or comment in test classes quote

Money.of(EURO, 1234567...

or

FastMoney.of(EURO, BigDecimal.ONE)

All of these should be fixed to reflect the actual method signature.



 Comments   
Comment by atsticks [ 11/Feb/15 ]

Where I saw such refs, I fixed them...





[JAVAMONEY-86] Clean up java.net wiki page Created: 06/Feb/15  Updated: 11/Feb/15  Resolved: 11/Feb/15

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

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

Tags: documentation

 Description   

The java.net wiki page https://java.net/projects/javamoney/pages/Home contains outdated references especially to CloudBees instances that no longer exist.






[JAVAMONEY-43] Improve Description of Rounding/Truncation Created: 08/Aug/13  Updated: 05/Feb/15  Resolved: 30/Aug/13

Status: Closed
Project: javamoney
Component/s: Spec: Specification
Affects Version/s: 0.4-EDR1
Fix Version/s: 0.5

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


 Description   

Page 29 doesn't explain in detail on Rounding and truncating the fraction. If we want to round to a certain fraction only (eg: currency usually rounds to 2 digits after decimal). Also, rounding or truncating based on decimal precision (round if > 0.5 and truncate if < 0.5) is not explained/considered. I have seen bank transfers in some banks handling with truncation if needed (could be depending on country)






[JAVAMONEY-53] Update/prepare Spec for Public Draft Review Created: 08/Aug/13  Updated: 05/Feb/15  Resolved: 15/Sep/13

Status: Closed
Project: javamoney
Component/s: Spec: Specification
Affects Version/s: 0.4-EDR1
Fix Version/s: 0.5

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


 Description   

Update the JSR specification for the Public Draft Review. Especially

  • adapt/include all changes done since EDR
  • Read through for improving English (must be done by a native English speaking colluege)
  • Add comments for points that must be checked by the TCK.

The PDR specification is located at:
https://docs.google.com/document/d/1FfihURoCYrbkDcSf1WXM6fHoU3d3tKooMnZLCpmpyV8/edit#heading=h.1e43k8j0bpig






[JAVAMONEY-80] extracting priorities in MonetayConfig#updateConfig is broken Created: 01/Nov/14  Updated: 05/Feb/15  Resolved: 29/Jan/15

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

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


 Description   

Extracting a priority string from a value in javamoney.properties fails completely. Indices are calculated wrongly and putting a priority key into the priority map first and then looking for an existing priority will always lead to an IllegalStateException.



 Comments   
Comment by cmrudolph [ 01/Nov/14 ]

Created a pull request to fix this issue:
https://github.com/JavaMoney/jsr354-ri/pull/55





[JAVAMONEY-83] Change key type in Contexts/Queries to String Created: 02/Feb/15  Updated: 05/Feb/15  Resolved: 05/Feb/15

Status: Closed
Project: javamoney
Component/s: API, Impl: RI, Spec: Specification, Test: TCK
Affects Version/s: 0.9
Fix Version/s: 1.0

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


 Description   

Change key type in Contexts/Queries to String (currently it is Object). This reduces the complexity of the context class and its builders drastically.



 Comments   
Comment by atsticks [ 05/Feb/15 ]

Fixed in 1.0-RC2.





[JAVAMONEY-45] Design/add support for ISO 20022 Created: 08/Aug/13  Updated: 05/Feb/15  Resolved: 30/Aug/13

Status: Closed
Project: javamoney
Component/s: API, Spec: Specification
Affects Version/s: 0.4-EDR1
Fix Version/s: 0.5

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


 Description   

There is no technical specification related to ISO 20022. Since business cases involves in money transfers, developer community would expect data structure related to messaging attributes like Swift.
This topic should help to decide how we can best support this standard.

atsticks: I assume we should add an according ItemFormat implementation and document it as requird part of an implementation.

Definition: Amount of money of the cash balance.
Data Type: ActiveOrHistoricCurrencyAndAmount
This data type must be used with the following XML Attribute: Currency (Ccy) which is typed by

ActiveOrHistoricCurrencyCode.
Format: ActiveOrHistoricCurrencyAndAmount
fractionDigits: 5
minInclusive: 0
totalDigits: 18

ActiveOrHistoricCurrencyCode
[A-Z]

{3,3}

Rule(s): ActiveOrHistoricCurrencyAndAmount

CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
Note: The decimal separator is a dot.



 Comments   
Comment by atsticks [ 30/Aug/13 ]
  • I added an according ItemFormat requirement, so we are able to Format/parse according amounts from to String.
  • I think it does not make sense to have a dedicated numeric MonetaryAmount implementation, since ISO 20022 is more an interchange Format, than a caclulation Format for internal use.




[JAVAMONEY-46] Add support for accountants notation Created: 08/Aug/13  Updated: 05/Feb/15  Resolved: 30/Aug/13

Status: Closed
Project: javamoney
Component/s: API, Spec: Specification
Affects Version/s: 0.4-EDR1
Fix Version/s: 0.5

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


 Description   

EDR Feedback: When we look at formatting, do we need to cover the concept of accountants notation, i.e. '(100)' not '-100'.

-> This formatting type should be enabled.
-> This qould already be possible with the curent ItemFormatBuilder, but I am not sure, if the according numeric formatter already is present.
-> Add a monetary amount ItemFormat implementation, that is supporting this feature.
-> Document the format as required format for an implementation.






Define updating mechanism (JAVAMONEY-47)

[JAVAMONEY-50] Update the IWF and EZB Exchange rate provider to use to the updater Created: 08/Aug/13  Updated: 05/Feb/15  Resolved: 15/Sep/13

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

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


 Description   

The IWF/EZB currency conversion providers both just directly read data from the internet on component creation. Instead of, both should use the common data updater/provider, which also is capable of transparently updating the data. Additionally initial versions of data files, should be added to the classpath as defined by the updater mechanism.






Define updating mechanism (JAVAMONEY-47)

[JAVAMONEY-52] Update the CurrencyProviders to use the updater Created: 08/Aug/13  Updated: 05/Feb/15  Resolved: 15/Sep/13

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.5

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


 Description   

Update the CurrencyUnit providers (ISO, CLDC for cash rounding) to use the updater for accessing data.






[JAVAMONEY-54] Define the ItemFormat instances and styles to be required by an implementation Created: 08/Aug/13  Updated: 05/Feb/15  Resolved: 30/Aug/13

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

Type: Task 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   
  • Define exactly what ItemFormat implementation must be provided by the (reference) implementation.
  • Along with that for each ItemFormat the according supported LocalizationStyle attributes must be defined.
  • Define which FormatToken implementations must be provided by the (reference) implementtion.
  • Similarly define the supported LocalizationStyle attributes.

Since when working with FormatToken}}s there are ultiple tokens in place, we need to define an "addressing" scheme, so attributes in a {{LocalizationStyle passed can be either

  • match to several tokens (unspecified)
  • match exact to one target token (explicit)

The mechanism/naming scheme should be made explicit and be discussed and also added to the specification/TCK.






[JAVAMONEY-61] Improve API of ItemFormatBuilder Created: 15/Sep/13  Updated: 05/Feb/15  Resolved: 15/Sep/13

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

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


 Description   
  • Replace addToken with add in ItemFormatBuilder for brevity.
  • Replace setXXX with withXXX to no violate JavaBeans constraints.
  • Remove (duplicate) getTargetClass() method.
  • Remove (duplicate) getLocalizationSTyle() method.





[JAVAMONEY-64] Maven dependency is broken 'javax.money:jsr354-api:0.7' Created: 30/Oct/13  Updated: 05/Feb/15  Resolved: 02/Mar/14

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

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


 Description   

On this page said:

Neverhtless this API is accessible by configuring the macen dependency:

<dependency>
<groupId>javax.money</groupId>
<artifactId>jsr354-api</artifactId>
<version>0.7</version>
</dependency>

It isn't true, I can't find this JAR in any repositories.

PS: typo "maCen"



 Comments   
Comment by atsticks [ 31/Oct/13 ]

Indeed. We planned to do that, but I admit to say we were a bit lazy. So I will take that up (have to talk with own of my EG members, to see, if he can finish this task...

Comment by atsticks [ 31/Oct/13 ]

Hi Chris

some time ago we discussed bringing our API/RI into maven central. Do you have time to finish this task within next days (for the public review 0.7 tag)?

Cheers,
Anatole

Comment by chrispheby [ 31/Oct/13 ]

Hi Anatole,

I moved back from SG to the UK in the last few weeks. Still, I should be able to make some time for this hopefully during next week. One thing I was waiting on is to determine is whether we can define a site location for publishing a Maven site to when the release is made. This could be accessed via e.g. SSH?

Regards Chris

Comment by chrispheby [ 07/Nov/13 ]

Anatole, did you manage to locate a possible Maven site location?

Cheers Chris

Comment by atsticks [ 08/Nov/13 ]

I think we should use the java.net website I created, it is manageable using webdav:
https://java.net/website/javamoney/

It is acessible with the java.net credentials...

There I creates subfolders for each module to build:

  • api
  • ri
  • tck
  • javamoney

I will add a main web page that will link to the different sub projects...

Comment by scolebourne [ 09/Nov/13 ]

I would avoid java.net, publishing pages at GitHub is so much simpler.

The whole set of http://joda.org websites are at GitHub.

The pom is here. I use a special plugin from GitHub. So I do "mvn site-deploy" rather than "mvn site:deploy":
https://github.com/JodaOrg/joda-beans/blob/master/pom.xml

I host all the project sites under the repo "jodaorg.github.io" rather than complicated per-project sites. Just push to git and you have a website.
https://github.com/JodaOrg/jodaorg.github.io

Comment by keilw [ 09/Nov/13 ]

There are already several Github pages, e.g. http://javamoney.github.io/jsr354-ri/ we should try to leverage those instead of duplication. While the java.net project is also code-named JavaMoney for historical purposes, if we still want to maintain news and updates around the Spec on java.net that sounds fair, but for RI, TCK and the JavaMoney Open Source project (which took over most of the JSRs original scope) that should be done on GitHub only. A link-list seems unnecessary effort with individual folders, a single page would be enough.

As for Joda, especially JSR 310 is one of the most bizarre examples how NOT do to this. Here on java.net there's
https://java.net/projects/jsr-310/ pointing to http://threeten.sourceforge.net/. That again claims, everything is now on GitHub, where the actual JSR page vanished because JSR 310 is not a real JSR any more, everything has been sucked into OpenJDK HG ;-/

What a mess, and perfect Lesson Learned on what we must avoid here (some day, but not with 1.0 we could face partial OpenJDK integration, but let's worry about after this one went Final )

P.s.: I just saw the javamoney.java.net page is NAKED and only shows HTTP sub-folders. Could we please try pointing that URL to https://javamoney.java.net/api/ instead?! The other pages are practically empty and see GitHub.io pages useless for most parts.

Besides, this looks like a slithly "abused" thread, the issue had nothing to do with a Wiki or Web page.
Following the success of Agorava.org, the way Antoine did that (asked him about it earlier) seems like a good pattern for a Github site (not a sub-project one like some of the repositories use already) used by javamoney.org. Until then javamoney.org simply points to the lib project, given the java.net page is a bit disfunctional at the moment

Werner

Comment by chrispheby [ 27/Nov/13 ]

Interesting dimensions to the discussion, but have we reached a decision. For the time being, I just need an agreed location (accessible via WebDAV / SSH) for publishing the Maven site as a multi-module project. We can finetune the mechanism and the structure when the basics are working?

Thanks Chris

Comment by chrispheby [ 30/Mar/14 ]

I think we didn't get an agreement on site location... how about I go ahead to arrange a Maven central release and omit the site publication?

Comment by chrispheby [ 01/Apr/14 ]

I think either Anatole or Werner published to central.

Release artifact is:

<dependency>
<groupId>org.javamoney</groupId>
<artifactId>moneta</artifactId>
<version>0.8</version>
</dependency>

Comment by chrispheby [ 01/Apr/14 ]

Now a Jar is published in Maven Central I have added some Hibernate mappings into Usertype - see https://jadira.atlassian.net/browse/JDF-76





[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-77] Factory methods called create() in some classes, not of() Created: 03/Sep/14  Updated: 05/Feb/15  Resolved: 04/Sep/14

Status: Closed
Project: javamoney
Component/s: API, Impl: RI
Affects Version/s: None
Fix Version/s: 0.9

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: design, naming, namingconvention

 Description   

A few classes, especially AmountFormatContextBuilder have static factory methods returning an instance of that class called create() not a commonly used of() while they take exactly the same sort of arguments an of() method would take with classes even in the same package (like AmountFormatQuery).

In a "Builder" class this is even more confusing, as the class creates something via the build() method, so one cannot really see the difference between create() and build() at first sight.

Unless there was a good reason to break with patterns, we should try to fix that.
Java 8 also applies it in many cases where of() replaces a more common valueOf(), wihile e.g. CLDC8 or MEEP8 also use getInstance() at least for pure singletons with no argument.



 Comments   
Comment by atsticks [ 04/Sep/14 ]

Also removed exposure of BuildableCurrencyUnit, DefaultExchangeRate in RI, by assimilating Builder design to API.





[JAVAMONEY-78] Integer overflow in DefaultMonetaryAmountsSingletonSpi#comparePriority Created: 06/Sep/14  Updated: 05/Feb/15  Resolved: 07/Sep/14

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

Type: Bug Priority: Major
Reporter: