Make Moneta Modular (JAVAMONEY-137)

[JAVAMONEY-148] Analyze Dependencies Created: 27/Aug/15  Updated: 17/Nov/16  Resolved: 17/Nov/16

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
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

Issue Links:
Relates
relates to JAVAMONEY-158 Ensure JApiCmp reports are comparable... Open
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:



 Comments   
Comment by stokito [ 07/Sep/16 ]

Maybe you can find something useful in the list https://stokito.wordpress.com/2015/10/27/linkset-dependency-duplicates-in-maven-and-jar-hell-with-java-classloader/





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

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

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

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

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

 Description   

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



 Comments   
Comment by stokito [ 07/Sep/16 ]

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





[JAVAMONEY-165] Official support Jadira Usertype Extended Created: 07/Sep/16  Updated: 17/Nov/16  Resolved: 17/Nov/16

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

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


 Description   

Jadira Usertype Extended - is a framework that provides Hibernate user types which allows to work with Money types.
It started to support JSR 354 starting from v3.2.0.GA.
Unfortunately framework is written by one @chrisphe and may contain some errors.
Tutorial has only few lines about how to deal with Money
http://jadira.sourceforge.net/usertype-userguide.html

So I would like to ask JSR 354 team to review and check the integration because this is very important for enterprise users.
All money persistant classes are located here:
/org/jadira/usertype/moneyandcurrency/moneta

For example, LongColumnMoneyMinorMapper uses API incorrectly and uses movePointRight() instead of ConvertMinorPartQuery

So could you add Jadira under umbrella of JavaMoney and make at least code review?



 Comments   
Comment by keilw [ 17/Nov/16 ]

This should be fixed by https://github.com/JadiraOrg/jadira





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

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

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

Tags: test

 Description   

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

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

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



 Comments   
Comment by otaviojava [ 27/Aug/15 ]

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

Comment by keilw [ 28/Aug/15 ]

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

MoneyUtils.checkAmountParameter(amount, this.currency);

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

Comment by otaviojava [ 28/Aug/15 ]

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





[JAVAMONEY-103] Create JEP for Java 10+ Created: 12/May/15  Updated: 17/Nov/16  Resolved: 17/Nov/16

Status: Resolved
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: Won't Fix 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.



 Comments   
Comment by keilw [ 17/Nov/16 ]

We may do this at a later stage, but for now OpenJDK just doesn't seem ready for it. Should create a new ticket in a successor to java.net e.g. Github





Make Moneta Modular (JAVAMONEY-137)

[JAVAMONEY-138] Core Module Created: 16/Jul/15  Updated: 17/Nov/16  Resolved: 17/Nov/16

Status: Resolved
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: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by otaviojava [ 17/Nov/16 ]

resolved





Make Moneta Modular (JAVAMONEY-137)

[JAVAMONEY-140] Convert Module Created: 16/Jul/15  Updated: 17/Nov/16  Resolved: 17/Nov/16

Status: Resolved
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: Fixed 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.

Comment by otaviojava [ 17/Nov/16 ]

resolved and on master





[JAVAMONEY-166] MonetaryAmountFormat should expose regular expression that will match the format Created: 19/Oct/16  Updated: 13/Nov/16

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

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


 Description   

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

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



 Comments   
Comment by keilw [ 19/Oct/16 ]

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

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

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

Comment by Oliver Gierke [ 21/Oct/16 ]

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

Comment by otaviojava [ 12/Nov/16 ]

Hello Oliver.

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

Comment by otaviojava [ 13/Nov/16 ]

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

Comment by Oliver Gierke [ 13/Nov/16 ]

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

Comment by otaviojava [ 13/Nov/16 ]

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

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

Comment by Oliver Gierke [ 13/Nov/16 ]

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





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

 Description   

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

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






[JAVAMONEY-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 Resolved
Relates
relates to JAVAMONEY-135 Ensure Unit Test coverage and results... Reopened
Tags: coverage, test

 Description   

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






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

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

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

Tags: documentation, website

 Description   

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

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

This should be clarified and explained in the Readme.



 Comments   
Comment by keilw [ 08/Feb/16 ]

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





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





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





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 Resolved
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 Resolved
Tags: test

 Description   

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






[JAVAMONEY-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-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-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+ Resolved
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-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-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-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-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.





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-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: cmrudolph Assignee: atsticks
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

DefaultMonetaryAmountsSingletonSpi#comparePriority calculates its result using subtraction. This may lead to an integer under- / overflow, especially if null is the first comparison parameter.



 Comments   
Comment by cmrudolph [ 06/Sep/14 ]

I created a pull request with a test and a fix for this bug:
https://github.com/JavaMoney/jsr354-ri/pull/41

Comment by atsticks [ 07/Sep/14 ]

Changes were manually included due to merge issues. Thanks for contribution!





[JAVAMONEY-42] Add Percent Operation Created: 09/May/13  Updated: 05/Feb/15  Resolved: 30/Aug/13

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

Type: Improvement 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: arithmetic, core

 Description   

Based on Chris' suggestion
1) Do we need to model the concept of a percentage? I think this would make a lot of money operations more readable (especially GST / VAT), and it's a candidate for being an immutable type itself.

and existing approaches to that in Eclipse UOMo Business let's try to create a reusable Percent operation ideally based on the MonetaryOperation/MonetaryFunction paradigm the JSR already has.






[JAVAMONEY-47] Define updating mechanism 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: Task Priority: Major
Reporter: atsticks Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: 3 days, 22 hours Remaining Estimate: 12 hours
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: 3 days, 22 hours Original Estimate: 12 hours

Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVAMONEY-50 Update the IWF and EZB Exchange rate ... Sub-task Closed  
JAVAMONEY-51 Update the CLDC region providers to u... Sub-task Closed  
JAVAMONEY-52 Update the CurrencyProviders to use t... Sub-task Closed  
JAVAMONEY-60 Define and test an updater mechanism Sub-task Closed atsticks  

 Description   

Define and implement an updating mechanism/policies to keep changing resources up to date, e.g. countries, régions or currency data. Hereby I see the following policies:

  • LOCAL: read resources from the classpath, no automatic update (default).
  • CACHED: read resource from the CP, too, but automatically reload/update the resources using the configured connections.
    • The cache location may also be configured:
      • VM try to write the files into a locatoin within the JDK/JRE.
      • USER write the data to the user directory.
      • TEMP write the files as temporary files only and delete them on VM exit.
      • CUSTOM write the files to a custom location.

For the second part, the locations, where the different resources can be looked up and read, can be configured. This allows clients which want to control the update mechanism (e.g. due to security reasons) to configure a local company update site, instead of directly loading the resources, e.g. from ISO, Unicode.

The machanism implemented hereby should support the following features:

  • Each resource is defined by a resourceID and a resource location. Resources are accessed by its id.
  • It should be extendible (it can cache arbitrary resources), so it can also be used by spi implementations of this JSR.
  • The resources cached should be accessible by an API of the updater, clients should not directly access the file system.
  • Updating can be triggered programmatically.
  • There is a JMX bean that can be loaded, to trigger the update mechanism.
  • Finally it should be possible to configure some automatic updating, e.g. by using a Timer.





Define updating mechanism (JAVAMONEY-47)

[JAVAMONEY-51] Update the CLDC region providers 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: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Update the CLDR loaders/region providers to use the updater for locating/registering their resources.






[JAVAMONEY-63] Include feedback from Mark Davis and David Beaumont Created: 20/Sep/13  Updated: 05/Feb/15  Resolved: 22/Sep/13

Status: Closed
Project: javamoney
Component/s: API, Impl: RI
Affects Version/s: 0.5
Fix Version/s: 0.6

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


 Description   

Several relevant Feedback, see
https://docs.google.com/document/d/1viC1J5wQYe2DvZxvQXE0-MlljQMNgw60iv51Z-cEewI/edit#heading=h.s7t4itrat9w6

Topics:

  • Reduce overal API footprint
  • Correct API Docs (Javadocs)
  • Remove bad usages (Calendar, Builders and Constructors at the same time).
  • improve predicates and functions
  • ...





[JAVAMONEY-82] Parent POM of RI (1.0-RC1) not in codebase, differs from TCK Created: 29/Jan/15  Updated: 05/Feb/15  Resolved: 29/Jan/15

Status: Closed
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 0.9
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: version

 Description   

The parent POM 1.0-RC1 of the Moneta RI is not in GitHub.
The most recent one there is 0.5.
A snapshot of the 1.0-RC1 Parent was put to MavenCentral, but there is no equivalent in Github.

Also the TCK uses 0.5 of javamoney-parent, while the RI uses 1.0-RC1.






[JAVAMONEY-81] properties in a custom javamoney.properties might get overridden depending on classpath order 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   

Depending on the order in which javamoney.properties are found on the classpath, properties like org.javamoney.moneta.Money.defaults.precision get overridden by the default values, when the default file gets loaded after the custom one.






[JAVAMONEY-76] Possible problem in IMF Exchange Created: 02/Sep/14  Updated: 05/Feb/15  Resolved: 05/Feb/15

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

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


 Description   

otaviojava commented 15 days ago
Doing a tutorial about money API, and I found a behavior strange. In Exchange rate using the ECB to convert real to dollar the value goes very well (USD 4.4209622560512496568), but using IMF the value goes, I believe, wrong (USD 22.779024906).

import java.util.Locale;

import javax.money.CurrencyUnit;
import javax.money.MonetaryAmount;
import javax.money.MonetaryCurrencies;
import javax.money.convert.CurrencyConversion;
import javax.money.convert.ExchangeRateProvider;
import javax.money.convert.MonetaryConversions;

import org.javamoney.moneta.Money;

public class ExchangeExample {

public static void main(String[] args)

{ CurrencyUnit real = MonetaryCurrencies.getCurrency("BRL"); CurrencyUnit dollar = MonetaryCurrencies.getCurrency(Locale.US); ExchangeRateProvider ecbRateProvider = MonetaryConversions .getExchangeRateProvider("ECB"); ExchangeRateProvider imfRateProvider = MonetaryConversions .getExchangeRateProvider("IMF"); CurrencyConversion ecbDollarConvertion = ecbRateProvider .getCurrencyConversion(dollar); CurrencyConversion imfDollarConvertion = imfRateProvider .getCurrencyConversion(dollar); MonetaryAmount money = Money.of(10, real); System.out.println(money.with(ecbDollarConvertion)); System.out.println(money.with(imfDollarConvertion)); }

}



 Comments   
Comment by atsticks [ 05/Feb/15 ]

Added test as well which compares values from ECB/IMF for INR, CHF and BRL. Output as follows:

ECB : USD 0.1619735504715828927
IMF : USD 0.161617017470929549198859585865823
ECB : USD 10.777368470766033598
IMF : USD 10.7769859778391460805732890664039
ECB : USD 3.652602599398169424
IMF : USD 3.68352145269119496180811818488349




[JAVAMONEY-12] Align Integration Requirements With OpenJDK Created: 30/Jan/13  Updated: 02/Sep/14  Due: 14/Mar/15  Resolved: 02/Sep/14

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

Type: Task Priority: Minor
Reporter: atsticks Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: 2 days
Time Spent: Not Specified
Original Estimate: 2 days
Environment:

Targeting SE 9.


Tags: JSR, SE, core, design

 Description   

It is viable to discuss with Oracle JDK architects the required constraints on value type and accessor design. As a result of this task a small document should be written or provided that states the common requirements for SE JSRs like this. As an advantage this document can also be shared with other JSRs that are not lead by Oracle.



 Comments   
Comment by keilw [ 26/Apr/13 ]

Given Java 9 has been deferred to early 2016 this issue probably won't matter at all for 1.0





[JAVAMONEY-25] Multi MonetaryAmount and CurrencyUnit Values Created: 02/Feb/13  Updated: 11/Mar/14  Resolved: 11/Mar/14

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

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

Tags: MonetaryAmount, compount_amount, multi-currency, multi-value

 Description   

Define a compound multi-valued monetary amount that consists of several amounts:

  • of the same currency, but with different semantics, e.g. for use cases in insurance calculations
  • of different currencies, e.g. for easily switching between currencies supported in web shop
  • a mix of the above.

A compound value has the following properties:

  • it is immutable.
  • it does not offer arithemtics
  • it provides access to all its containing{{MonetaryAmount}} instances:
    • Map<String,MonetaryAmount> getAll()
    • Enumeration<String> getKeys();
    • MonetaryAmount getMonetaryAmount(String key)
    • boolean isMonetaryAmountDefined(String key)
  • It allows access to all different currencies contained:
    • Enumeration<CurrencyUnit> getContainedCurrencies()
  • it provides a CompoundMonetaryAmountFactory for creating compound values.
  • Since a compound amount is defined to be immutable, it can only be extended/adapted as follows:
    • CompoundMonetaryAmount add(String key, MonetaryAmount amount);
    • CompoundMonetaryAmount remove(String... key);
    • CompoundMonetaryAmountBuilder toBuilder() // and using the builder to create a new instance


 Comments   
Comment by keilw [ 02/Feb/13 ]

Sorry, but this seems a little to specific for most users.
On that I can only agree with Stephen about the 80% of users. It is certainly valid, but shouldn't go into "core", probably more towards one of the EE-related modules or simply an extension.

Comment by chrispheby [ 05/Feb/13 ]

Is another use case an e-'wallet' concept for the above?

Comment by atsticks [ 05/Feb/13 ]

Currently only a CompoundItem and CompoundItemBuilder are defined in convert as interfaces. The effective value types are implemented within the RI only as of now. It can be useful to move these interfaces into the extensions module.
Basically one of the most important use cases are pension calculations, where several input parameters are required and also the result of a pension calculation are multiple amounts, e.g. death capital, total capital, buy in option, risk investment strategy amounts etc.

Comment by keilw [ 05/Feb/13 ]

Both CompoundItem and CompoundItemBuilder are generic in convert, so they seem more like "specialized Collection API" elements than part of "Conversion API", I agree they might go to "ext", which doesn't prevent certain implementations from using those interfaces. Whether or not that'll be the RI and for which target platform, we shall see.

Comment by atsticks [ 11/Mar/14 ]

This Feature has not shown to be useful as part of API/RI. May be something can be added to lib, but also here there is no real Advantage to just using a map of <x, MonetaryAmount>.





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

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

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


 Description   

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



 Comments   
Comment by atsticks [ 10/Mar/14 ]

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





Define updating mechanism (JAVAMONEY-47)

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

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

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


 Description   

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

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


 Comments   
Comment by atsticks [ 10/Mar/14 ]

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





[JAVAMONEY-19] Support for regional Rounding Rules Created: 01/Feb/13  Updated: 10/Mar/14  Resolved: 10/Mar/14

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

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


 Description   

Support for regional and custom rounding rules is provided:

  • Roundings that are defined by a CurrencyUnit, refer also to the Unicode standard.
  • Support for arbitrary roundings defined by use cases.
  • Providing a comprehensive API/SPI for Rounding and according accessor methods.
  • Ensure interoperability with rounding as defined by java.math.


 Comments   
Comment by chrispheby [ 05/Feb/13 ]

Couple of use cases:

In Singapore, 1 cent coins are no longer being produced although they remain in circulation. As a result I have never seen one. Retailers round cash (but not card transactions) to the nearest 5 cents. I believe Canada is in the process of doing this the same move currently.

In Saudi Arabia, some retailers round up to the nearest riyal, with the difference forming a charitable donation.

Comment by atsticks [ 10/Mar/14 ]

MonetaryRoundings allows to pass a MonetaryContext that may contain any additional Parameters required. So this Feature is fully covered by the current API.





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

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

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


 Description   

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



 Comments   
Comment by atsticks [ 06/Feb/13 ]

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

Comment by atsticks [ 10/Mar/14 ]

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





[JAVAMONEY-10] Keep JDK Stub up to date Created: 20/Jan/13  Updated: 10/Nov/13  Due: 09/Apr/13  Resolved: 08/Apr/13

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

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

Tags: jdk

 Description   

After updates to CurrencyUnit, the jdk-stub module no longer compiled.
Please while it isn't part of the "portable RI", let's always ensure, it's up do date with the spec given this will become the de facto RI for either SE 9, CLDC 8/9 or both.



 Comments   
Comment by keilw [ 05/Feb/13 ]

Fixed the Stub again, a change of the getValid* methods in CurrencyUnit forced it, after code was broken there.
This module should probably also be included in a CI Job to ensure consistency.

If returning <code>null</code> is a mandatory requirement for these timestamps, leaving them as Long object instead of a simple long primitive type might be acceptable, but I see a possible overhead or risk of people using AutoBoxing in real life when they gather such primitive values from System.currentTimeMillis(), System.nanoTime() or similar.
Ultimately that will be up to advise by Oracle Architects, if a complex type is feasible, especially if this affects java.util.Currency, too.





Extended JSR Scope (JAVAMONEY-23)

[JAVAMONEY-32] Separate platform aspects from advanced features. Created: 16/Feb/13  Updated: 10/Nov/13  Due: 01/Mar/13  Resolved: 27/Apr/13

Status: Closed
Project: javamoney
Component/s: General: Build and quality management, Impl: RI, Spec: Specification
Affects Version/s: 0.3
Fix Version/s: 0.4-EDR1

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


 Description   

Separate platform aspects from advanced features. Ensure separation also within other area, e.g.

  • specification
  • JIRA
  • etc.

Discuss details in next EG meeting.






Generated at Sun Dec 11 14:35:20 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.