javamoney / javamoney-lib Goto Github PK

JavaMoney financial libraries, extending and complementing JSR 354

License: Apache License 2.0

Java 100.00%

currencies currency java javamoney library money

javamoney-lib's Introduction

JSR 354: Money and Currency API

JSR 354 provides an API for representing, transporting, and performing comprehensive calculations with Money and Currency. See the home page for more details: http://jcp.org/en/jsr/detail?id=354

This is the API module of JSR 354 licenced under

the Apache License Version 2.0 (LICENCE.txt)

Release Notes

1.0 API as defined by JSR 354 Spec.
1.0.1 API as defined by JSR 354 Spec (Fix: building Java 7 API with Java 7)
1.0.2 API as defined by JSR 354 Spec (Fix: built with Java 9) - dont use, use 1.0.3 instead!
1.0.3 API as defined by JSR 354 Spec (Compatible with Java 8, full Java 9 module support)
1.1 API as defined by JSR 354 MR 1.

javamoney-lib's People

Contributors

Stargazers

Watchers

javamoney-lib's Issues

Update readme

The Readme file does not reflect many of the libraries right now. Should be updated.

Consider an Exchange module for Bulgarian Lev

An Android app exists tapping into the Bulgarian National Bank: https://github.com/vexelon-dot-net/bgrates We should consider something similar. Ideally also working on Android ;-)

If it's premature here, then maybe for the Shelter...

`CompoundInterest.apply` ignores `timesCompounded` and uses 1

CompoundInterest.apply ignores timesCompounded and uses 1

javamoney-lib/calc/src/main/java/org/javamoney/calc/common/CompoundInterest.java

Line 121 in beef818

return calculate(amount, rateAndPeriods);

Unable to build due to moneta.core 1.2 jar is missing

I am unable to build javamoney-lib and its dependency libs due to missing to download moneta.core 1.2 version jar file.
Please suggest the alternate version of it. I tried with moneta 1,1 & 1.0 version and not success

Prepare Calculation for Java 8/9

The Calculation interface is a skinned-down clone of Java 8 functional interface java.util.function.Function.

Should be prepared for Java 8 or 9 by using an identical method signature (only apply() method so far) allowing seamless integration of Java 8 Lambdas (Calculation extends Function) and eventual elimination of this interface in JavaMoney without affecting third party codebase.

i.E. sub-interfaces like MonetaryCalculation would then directly extend Function.

Java 8 problems in javamoney-calc

A recent API/RI change caused the Libraries to fail compiling, at least javamoney-calc has the following problem:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project javamoney-calc: Compilation failure: Compilation failure:
[ERROR] /C:/Users/Werner/git/javamoney-lib/calc/src/main/java/org/javamoney/calc/function/MonetaryPredicates.java:[66,16] cannot infer type arguments for org.javamoney.calc.function.AndPredicate<>
[ERROR] reason: inferred type does not conform to upper bound(s)
[ERROR] inferred: org.javamoney.calc.function.MonetaryPredicate<? super T>
[ERROR] upper bound(s): org.javamoney.calc.function.MonetaryPredicate<? super capture#1 of ? super T>,java.lang.Object
[ERROR] /C:/Users/Werner/git/javamoney-lib/calc/src/main/java/org/javamoney/calc/function/MonetaryPredicates.java:[94,16] cannot infer type arguments for org.javamoney.calc.function.OrPredicate<>
[ERROR] reason: inferred type does not conform to upper bound(s)
[ERROR] inferred: org.javamoney.calc.function.MonetaryPredicate<? super T>
[ERROR] upper bound(s): org.javamoney.calc.function.MonetaryPredicate<? super capture#2 of ? super T>,java.lang.Object
[ERROR] /C:/Users/Werner/git/javamoney-lib/calc/src/main/java/org/javamoney/calc/function/MonetaryPredicates.java:[122,16] cannot infer type arguments for org.javamoney.calc.function.OrPredicate<>
[ERROR] reason: inferred type does not conform to upper bound(s)
[ERROR] inferred: org.javamoney.calc.function.MonetaryPredicate<? super T>
[ERROR] upper bound(s): org.javamoney.calc.function.MonetaryPredicate<? super capture#3 of ? super T>,java.lang.Object

Add yahoo Finances as Exchange Rate implementation

Update license headers

To make this a community effort and reflect the true nature of contributors, we should apply a similar pattern as Red Hat, MicroProfile etc.

Unlike the actual JSR where the Spec Lead is Credit Suisse until it may change some day, here the legal entities can simply be @atsticks, @otaviojava, myself or others.

So we should address this in the license headers, too (the READMe file already does)

Remove IMF and ECB providers from lib

The EMFand ECB (out-of-the-box) provider should be moved as modules (back) into RI.
Moneta/BP can perfectly use a module under an Umbrella POM but external dependencies used by Moneta/BP would create a circular dependency between RI and an external module using it.

Harmonize Builders with java.util Classes

Unlike most static Builder classes in JavaMoney or Moneta every builder in java.util particularly in the i18n area use set(property) not with(property), see
Locale aLocale = new Builder().setLanguage("sr").setScript("Latn").setRegion("RS").build();

With the prospect of similar builders for e.g. java.util.Currency or implementations of MonetaryAmount, this shall be harmonized.

Exchange Rate Providers for Google Currency

Consider an Exchange Rate Provider for Google Currency similar to https://github.com/RubyMoney/google_currency

Currency data source URL for IsoCurrencyOnlineProvider needs updating

See https://java.net/jira/browse/JAVAMONEY-58 for history

Tests fail in FCR provider module (exchange)

All tests accessing real frc rates do actually fail.

javax.money.MonetaryException: No such service found: interface javax.money.spi.MonetaryAmountsSingletonQuerySpi

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running org.javamoney.cdi.SmokeTest
Nov 12, 2014 8:33:01 AM org.javamoney.moneta.DefaultMonetaryContextFactory createMonetaryContextNonNullConfig
INFO: Using custom MathContext: precision=256, roundingMode=HALF_EVEN
*** Starting CDIContainer ...
311 [main] INFO org.jboss.weld.Version - WELD-000900 1.1.5 (Final)
467 [main] INFO org.jboss.weld.Bootstrap - WELD-000101 Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously.
1144 [main] WARN org.jboss.interceptor.util.InterceptionTypeRegistry - Class 'javax.ejb.PostActivate' not found, interception based on it is not enabled
1145 [main] WARN org.jboss.interceptor.util.InterceptionTypeRegistry - Class 'javax.ejb.PrePassivate' not found, interception based on it is not enabled
*** CDIContainer started.
Nov 12, 2014 8:33:02 AM javax.money.MonetaryAmounts loadMonetaryAmountsSingletonQuerySpi
SEVERE: Failed to load MonetaryAmountsSingletonQuerySpi, query functionality will not be available.
javax.money.MonetaryException: No such service found: interface javax.money.spi.MonetaryAmountsSingletonQuerySpi
    at javax.money.spi.Bootstrap.getService(Bootstrap.java:126)
    at javax.money.MonetaryAmounts.loadMonetaryAmountsSingletonQuerySpi(MonetaryAmounts.java:72)
    at javax.money.MonetaryAmounts.<clinit>(MonetaryAmounts.java:41)
    at javax.money.format.AmountFormatQuery.getMonetaryAmountFactory(AmountFormatQuery.java:70)
    at org.javamoney.moneta.format.internal.DefaultAmountFormatProviderSpi.getAmountFormats(DefaultAmountFormatProviderSpi.java:78)
    at javax.money.format.MonetaryFormats$DefaultMonetaryFormatsSingletonSpi.getAmountFormats(MonetaryFormats.java:208)
    at javax.money.spi.MonetaryFormatsSingletonSpi.getAmountFormat(MonetaryFormatsSingletonSpi.java:69)
    at javax.money.format.MonetaryFormats.getAmountFormat(MonetaryFormats.java:110)
    at javax.money.format.MonetaryFormats.getAmountFormat(MonetaryFormats.java:80)
    at org.javamoney.cdi.SmokeTest.testAmountFormatRoundTrip(SmokeTest.java:95)
    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:483)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
    at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
    at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
    at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
    at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
    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:483)
    at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
    at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
    at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
    at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
    at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)

Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.645 sec <<< FAILURE!
*** Stopping CDIContainer ...
*** CDIContainer stopped.

Results :

Tests in error: 
  testExchange(org.javamoney.cdi.SmokeTest)

Tests run: 5, Failures: 0, Errors: 1, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------

Replace Bintray from JavaMoney-Lib

Maven POM and settings.xml, see https://central.sonatype.org/pages/apache-maven.html
Project Settings: Update CI_DEPLOY_PASSWORD for Sonatype/OSSH

See JavaMoney/javamoney-parent#6

Should every module be an OSGi bundle?

Many lib modules are currently of type "jar".
Should they be OSGi bundles, too?

Support HTML5 Microformats?

I found this effort by the Microformats project: http://microformats.org/wiki/measure
It's about "measure" but aims to cover monetary amounts, too

Deploy lib to maven repository

If you haven't repository try to use Bintray.com

Move "retired" to javamoney-shelter

The "retired" modules should not sit around here. Let's move them into shelter. If there is enough momentum behind some, they could graduate back here again.

Travis CI build failed but marked as passed and greeen

Test are failed but Travis badget looks pretty green.
I found that enabled option of surefire plugin:

<testFailureIgnore>true</testFailureIgnore>

Why?
There is a LOT of tests that failed, but this option makes build successfully

Add Google Finances as Exchange Rate implementation

Add Google Finances as Exchange Rate implementation
http://www.google.com/finance/converter?a=1&from=BRL&to=USD
https://www.google.com/finance/converter?a=16.6700&from=GBP&to=USD

Fix wrongly named getInstance()

As in Java 8 a no-op factory returning a singleton is called getInstance(), not of() which is used only with arguments.
E.g. javax.microedition.event.EventManager, etc.

Fix Readme

Now that retired seems gone or moved to javamoney-shelter, please also update the README file and remove the paragraph about those old modules or cut/paste it into the README of shelter.

Remove "bundles"

For now there is no real purpose for the "bundles" folder/sub-module.

Could we split "update_exchange" script and move it to each module?

The Update script on the top level POM project handles only IMF and ECB, but their subsequent scripts should be in a separate module only for either of them.

Move javamoney-cdi to Midas?

It seems javamoney-lib/integration especially for CDI could have a better place under the "Midas" umbrella. WDYT?

"update_*" scripts should be platform-neutral

Also provide a Batch/Powershell script for update exchange rates under Windows, or better a Java tool;-)

Ideally a Maven plugin like this one: https://github.com/maven-download-plugin/maven-download-plugin

The defaults are so rapidly outdated, that it seems better to have Maven retrieve them while building (optional or always) and add them to JAR, but not bother with constantly changing sources.

Android Support

I'm interested in using the Java Money RI and these libraries in Android Apps. Is this possible using technologies like retrolambda?

Has anyone tried this?

What are the issues?

Note: I probably would have opened this issue in the RI repo, but issues aren't enabled there.

YieldToMaturity calculation fault

Your YieldToMarurity calculation uses formula for approximate YTM (please read carefully mentioned source).
In the middle of http://www.financeformulas.net/Yield_to_Maturity.html there's formula for present value of a bond.
To get precise YTM you have to reverse formula to get r from it.
It's hardly reversible, and you have to approximate it with binary search or using Newton–Raphson method.

Fix Predicate redundancy

The Predicate interface is a skinned-down clone of Java 8 functional interface java.util.function.Predicate.

Should be resolved by renaming this element to MonetaryPredicate. Using an identical method signature (only test() method so far) allowing seamless integration of Java 8 Lambdas (MonetaryPredicate extends Predicate) and eventual elimination of this part of JavaMoney without affecting third party codebase.
i.E. classes like MonetaryCalculations would then use java.util.function.Predicate instead of MonetaryPredicate.

Prepare release of library module

We should try to get out the library module in an initial release. Can anybody interested have a spot on it? I know documentation is very little ;)
Note this also includes a CDI annotation API in the CDI module.

javamoney / javamoney-lib Goto Github PK

javamoney-lib's Introduction

JSR 354: Money and Currency API

Release Notes

javamoney-lib's People

Contributors

Stargazers

Watchers

Forkers

javamoney-lib's Issues

Recommend Projects

Recommend Topics

Recommend Org