Fix the critical security issues flagged under: https://github.com/JavaMoney/javamoney-examples/security/dependabot

While the artifactId says "functional-example" the package is wrongly named "org.javamoney.funcional.example"
Should follow other naming conventions and be either "org.javamoney.examples.functional" or "org.javamoney.examples.console.functional"

See Readme, example disabled, needs adjusted Moneta classes to work again

HI, I'm trying to create a rate provider to get exchange rates from my database, but I can't found documentation about it. It's possible to do? How can I register this?

I've found no documentation as how to store monetary amounts (e.g. FastMoney) using JPA. Since the classes are reasonably not annotated as @embeddable and have more than one attribute one needs a workaround for storing/retrieving them.
I've found org.jadira.usertype.moneyandcurrency.moneta.PersistentFastMoneyAmountAndCurrency but I am not sure if this is still the way to go (since jadira seems a little bit outdated)

I would propose to document this and as well provide an example in https://github.com/JavaMoney/javamoney-examples

As we heard, Java 11 is not going to include JavaFX any more.

The JavaFX examples either have to be migrated to a successor project (Open FX or whatever) or retired over time if JavaFX itelf also ends up being archived.

Some examples are using Log4J 1, those should be upgraded to Log4J 2.

I think that storing all examples in one big repository is not a good idea. When someone forks it required to spend some time to understood project content.
Also there is a lot of sources (up 5 mb) that should be indexed by IDE and recompiled by CI on each push.
Could we saparate this repository to another smaller and simple? Like: javamoney-jsf-examples, javamoney-console-examples etc.
It make working on them more flexible

org.javamoney.lib:javamoney-lib:pom:0.5-SNAPSHOT not in repository http://repository-jsr354.forge.cloudbees.com/snapshot/

Not sure, when it last did, but the "web" example jax-rs-money no longer works with current versions of JavaMoney

Hi,
Is there any reason why classes Money, FastMoney, RoundedMoney are declared as final?
I wanted to change behavior of one method in Money class but it's not possible.
Security reasons are not relevant here because one can still implement MonetaryAmount interface and for example do it wrongly and cause some issues.
IMHO the code should be open for extension (and closed for modification). It's just a question if there are any reasons to keep these classes as final?

I am missing this example in the official documentation.
How can I help?

Are there any samples on how to save MonetaryAmount on a database? I think this is very common use case, so the docs should include it.

I would at least propose two subtasks to this:

• Relational DB via Jadira Extended
• Non-Relational DBs via Jakarta NoSQL

As of now the Java 8 "functional-examples" look like they merely run on the console, thus they should be moved under "console" here.

Examples do not have distributionManagement, so no need for change here, since JCenter won't be removed for the time being, see https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/

See JavaMoney/javamoney-parent#6

Create console examples demonstrating Java 8 features like Lambdas

A Money instance written in the US format cannot be parsed again using the very same format.

In this example add the following line to see it fail:

Money.parse(usFormat.format(monetaryAmount), usFormat);

Using the German format works fine though.

It makes little sense to separate Functional or Lambda examples into their own module, just put them into javamoney-console-java8 and above (where differences exist like using var, etc.)

Create a JShell example e.g. a Currency Converter using JShell.

Rolled over from #30

http://geronimo.apache.org/GMOxDOC21/developing-a-simple-restful-service.html
shows how a JSP may consume a RESTful Web Service for a Currency Converter (even Rupees to USD ;-) We should try a similar example for JSR 354 here.

Accessing the IMF looks very error-prone nowadays. Building the examples throws

WARNING: Failed to read/load resource (checking fallback): IMFHistoricRateProvider
java.lang.IllegalArgumentException: Failed to load new data: org.javamoney.moneta.convert.imf.IMFHistoricRateProvider{ context: ProviderContext (
{User-Agent=Chrome/51.0.2704.103, rateTypes=[HISTORIC], providerDescription=Historic International Monetary Fond, days=0, provider=IMF-HIST})}
	at org.javamoney.moneta.internal.loader.DefaultLoaderListener.trigger(DefaultLoaderListener.java:85)
	at org.javamoney.moneta.internal.loader.LoadDataLoaderService.execute(LoadDataLoaderService.java:41)
	at org.javamoney.moneta.internal.loader.DefaultLoaderServiceFacade.loadData(DefaultLoaderServiceFacade.java:43)
	at org.javamoney.moneta.internal.loader.DefaultLoaderService.loadData(DefaultLoaderService.java:264)
	at org.javamoney.moneta.convert.imf.IMFHistoricRateProvider.<init>(IMFHistoricRateProvider.java:66)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at java.lang.Class.newInstance(Class.java:442)
	at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
	at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
	at org.javamoney.moneta.internal.PriorityAwareServiceProvider.loadServices(PriorityAwareServiceProvider.java:98)
	at org.javamoney.moneta.internal.PriorityAwareServiceProvider.getServices(PriorityAwareServiceProvider.java:65)
	at javax.money.spi.Bootstrap.getServices(Bootstrap.java:102)
	at org.javamoney.moneta.convert.internal.DefaultMonetaryConversionsSingletonSpi.reload(DefaultMonetaryConversionsSingletonSpi.java:64)
	at org.javamoney.moneta.convert.internal.DefaultMonetaryConversionsSingletonSpi.<init>(DefaultMonetaryConversionsSingletonSpi.java:56)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at java.lang.Class.newInstance(Class.java:442)
	at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
	at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
	at org.javamoney.moneta.internal.PriorityAwareServiceProvider.loadServices(PriorityAwareServiceProvider.java:98)
	at org.javamoney.moneta.internal.PriorityAwareServiceProvider.getServices(PriorityAwareServiceProvider.java:65)
	at javax.money.spi.Bootstrap.getService(Bootstrap.java:113)
	at javax.money.convert.MonetaryConversions.getMonetaryConversionsSpi(MonetaryConversions.java:59)
	at javax.money.convert.MonetaryConversions.getExchangeRateProvider(MonetaryConversions.java:169)
	at org.javamoney.examples.test.MonetaryConversionTest.testGetExchangeRateProvider_Chained(MonetaryConversionTest.java:58)
	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:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
	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)
Caused by: java.lang.IllegalArgumentException: Failed to load IMF data provided.
	at org.javamoney.moneta.convert.imf.IMFAbstractRateProvider.newDataLoaded(IMFAbstractRateProvider.java:123)
	at org.javamoney.moneta.convert.imf.IMFHistoricRateProvider.newDataLoaded(IMFHistoricRateProvider.java:47)
	at org.javamoney.moneta.internal.loader.DefaultLoaderListener.trigger(DefaultLoaderListener.java:83)
	... 54 more
Caused by: java.io.IOException: Request has been rejected by IMF server.
	at org.javamoney.moneta.convert.imf.IMFRateReadingHandler.read(IMFRateReadingHandler.java:66)
	at org.javamoney.moneta.convert.imf.IMFAbstractRateProvider.newDataLoaded(IMFAbstractRateProvider.java:114)
	... 56 more

So it's not restricted to Russia, China or other countries, this happens in the EU as well.
It won't break the overall build but we should find a solution or disable these tests or even reconsider certain exchange rate providers if IMF is no longer reliable.

For Java 9 and (as soon as issues like JavaMoney/jsr354-api#71 can be resolved) also Java 10 there should be dedicated examples.
If it's possible to build some of them as multi-version JAR files for Java 9, 10 or below it would be a plus.

Something nice would be

• Java 9 JShell currency converter
• Java 10 var usage

CurrencyUnit base = MoneetaryCurrencies.getCurrency("EUR");
CurrencyUnit term = MoneetaryCurrencies.getCurrency("USD");

should read

CurrencyUnit base = MonetaryCurrencies.getCurrency("EUR");
CurrencyUnit term = MonetaryCurrencies.getCurrency("USD");

The ECB Rate Provider isn't working for me in the JavaMoney Demo Application. I am using NetBeans 8.0.2 and Default JDK 1.8.

Note that when I run my own sample application, ECB is cool with the 0.9 dependency and not for anything sooner...

Thanks,
Robert

From JavaMoney/jsr354-ri#198, as it is not really the place in the Moneta issue tracker.

I want to write custom exchange provider to provide the exchange rate manually with a csv file.

The "web" example javamoney-tradingapp no longer works after changes to API/RI and lib

Running the FormatExample class throws an exception when we try to run the US SYMBOL code:

Nov 04, 2015 11:46:45 AM org.javamoney.moneta.DefaultMonetaryContextFactory createMonetaryContextNonNullConfig
INFO: Using custom MathContext: precision=256, roundingMode=HALF_EVEN
Exception in thread "main" javax.money.MonetaryException: No MonetaryAmountFormat for AmountFormatQuery AmountFormatQuery (
{Query.formatName=SYMBOL, java.util.Locale=en_US})
at javax.money.spi.MonetaryFormatsSingletonSpi.getAmountFormat(MonetaryFormatsSingletonSpi.java:71)
at javax.money.format.MonetaryFormats.getAmountFormat(MonetaryFormats.java:110)
at org.javamoney.examples.console.functional.FormatExample.main(FormatExample.java:24)

Hi,

I would love to see an example serializing and restoring monetary amounts over the wire using efficient serialization mechanics like Google Protobuf or Apache Avro ?

Thank you, kindly
Oscar

Like other modules (main JSR, lib) examples should also trigger a Travis build on code changes.

Update CDI demos to Java EE 8 and CDI 2.