Make Moneta Modular (JAVAMONEY-137)

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

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

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


 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.





Make Moneta Modular (JAVAMONEY-137)

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

Status: In Progress
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0.1
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: keilw Assignee: otaviojava
Resolution: Unresolved 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    
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





[JAVAMONEY-142] Define some tests as "integration-test" Created: 27/Jul/15  Updated: 27/Jul/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

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






Make Moneta Modular (JAVAMONEY-137)

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

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

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





Make Moneta Modular (JAVAMONEY-137)

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

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

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





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

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

Type: Task Priority: Major
Reporter: keilw Assignee: Unassigned
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 In Progress keilw  
JAVAMONEY-139 Format Module Sub-task Open  
JAVAMONEY-140 Convert Module Sub-task In Progress keilw  
JAVAMONEY-141 Pass TCK Sub-task In Progress otaviojava  
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-136] Broken compatibility wirh 1.0 Created: 23/Jun/15  Updated: 06/Jul/15  Resolved: 06/Jul/15

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

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?





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





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

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

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

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

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.





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

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

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

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

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





[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.0.1
Fix Version/s: 1.0.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.0.1
Fix Version/s: 1.0.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.0.1
Fix Version/s: 1.0.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.0.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.0.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.0.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-128] Mark any structural change with @since Created: 29/May/15  Updated: 29/May/15

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

Type: Task Priority: Major
Reporter: keilw Assignee: Unassigned
Resolution: Unresolved 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.






[JAVAMONEY-124] Ensure, RI-BP is in sync Created: 18/May/15  Updated: 29/May/15

Status: In Progress
Project: javamoney
Component/s: Impl: RI, Library: JavaMoney Extensions
Affects Version/s: 1.0.1
Fix Version/s: 1.0.1

Type: Task Priority: Critical
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-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 Open  
JAVAMONEY-135 Ensure Unit Test coverage and results... Sub-task Reopened otaviojava  
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.






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

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

Status: In Progress
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0.1
Fix Version/s: None

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





[JAVAMONEY-123] QueryConfig for MonetaryAmount does not honor params. Created: 15/May/15  Updated: 15/May/15

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

Type: Bug Priority: Major
Reporter: atsticks Assignee: Unassigned
Resolution: Unresolved 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.






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

Status: In Progress
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0.1
Fix Version/s: None

Type: Task Priority: Minor
Reporter: keilw Assignee: otaviojava
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-122 "Clone" conversion classes currently ... Sub-task In Progress keilw  
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 )





[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.0.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.0.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.0.1
Fix Version/s: 1.0.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.0.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.0.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.0.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.0.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.0.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.0.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.0.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.0.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-103] Create JEP for Java 10+ Created: 12/May/15  Updated: 14/May/15

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

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

 Description   

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






[JAVAMONEY-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.0.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.0.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.0.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-106] Clarify and document RI on JavaMoney page Created: 13/May/15  Updated: 13/May/15

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

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

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.






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

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

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

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-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.0.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+ Open
Tags: java9, jdk

 Description   

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



 Comments   
Comment by atsticks [ 29/Jan/15 ]

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





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

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

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

Tags: deployment, release

 Description   

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



 Comments   
Comment by keilw [ 12/May/15 ]

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





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

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: None
Fix Version/s: 1.0.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 Tue Jul 28 20:12:57 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.