Proposal: Submit Groovy subproject/JAR to Groovy project as a module. about javamoney-shelter

[stokito]

I think It's a good idea. But I don't understood why it would be a module and how they thinks it should work.
IMHO all should be easy like a working with BigDecimal in groovy:

1. Package javax.money. or just classes MonetaryAmount and CurrencyUnit should be imported by default like a java.lang.* package or java.math.BigDecimal
2. It would be very useful to introduce new literal for MonetaryAmount like we can write 42L, 0.5D, or 5G for BigDecimal. But Money requires Currency unit too, so this may be better to use standard Money.of() instead.
   Anyway, main idea is that using of Money should be easier that using number types for success.

@msgilligan could you create a issue in Groovy JIRA to track all discussions?

[msgilligan]

I just presented them with the work-in-progress here. They're looking to us to provide an initial implementation, though I did get some feedback and questions on the code and expect more. I think we should continue working here in the sandbox and ask to move to a Groovy repo when we're a little further along. But that's just my opinion. I am eager to hear what others think.

I agree with your goals @stokito, but for the first release we don't want to require any changes to the Groovy parser. That means we won't be able have native parsing of MonetaryAmount literals. Though it sure would be cool to be able to write $100 or €100 or Ƀ100 inline in code.

We can get the math operators to work on MonetaryAmount just like they do with BigInteger and BigDecimal and I have demo code that will allow us to write 100.usd, 100.eur, or (with Bitcoin provider) 100.btc. (Though I'm thinking the dot-currencycode extension should probably be disabled by default.) See GroovyMoneyDemoSpec.groovy for proof-of-concept Spock tests. We should also be able to get MonetaryAmount and CurrencyUnit to be imported by default if they have groovy-money.jar on the classpath.

Groovy JIRA is actually migrating to another server soon, and I think we should continue to track the project here until we move the code to a Groovy repo on Github. In the end, I'm happy to go along with whatever works for everyone else, but my suggestion is we just keep things here for now.

But I am specifically looking for feedback on the idea of an eventual move to the Groovy project and distribution. I'm assuming everyone will consider that a very good outcome, but would love to hear from as many JavaMoney devs as possible.

[keilw]

Judging from insight into Java 9 (especially through JCP EC) I highly doubt JSR 354 could still make it into the release train. Mark (Reinhold) said, by late summer of 2015 new features could still be accepted, but so far there isn't even a JEP, so I would not count on that. A "Jigsaw" enabled add-on to Java 9 is more likely to happen. Let's see for 10 and beyond, especially the idea of "Value Types" could benefit from value-driven JSRs like 354 or 363 ;-) Offering Groovy support or also to other languages (Scala, Ceylon, maybe Clojure would pop to mind as "relevant enough") is of course a good idea.

[keilw]

Btw. there is a now largely outdated Grails Currency module: https://github.com/ricardojmendez/grails-currencies here, too. Feel free to look into it for inspiration.

[atsticks]

Hi all

I was in contact with Oracle and LJC. Money will unfortunately not end in
JDK 9. Oracle doesn't feel the topic is important enough and they focus all
resources on Jigsaw...
Perhaps we can get into as an extension module, once Jigsaw is there and a
common Oracle repository or somehting like that is there ;)

Cheers,
Anatole

2015-02-05 11:25 GMT+01:00 Werner Keil [email protected]:

Judging from insight into Java 9 (especially through JCP EC) I highly
doubt JSR 354 could still make it into the release train. Mark (Reinhold)
said, by late summer of 2015 new features could still be accepted, but so
far there isn't even a JEP, so I would not count on that. A "Jigsaw"
enabled add-on to Java 9 is more likely to happen. Let's see for 10 and
beyond, especially the idea of "Value Types" could benefit from
value-driven JSRs like 354 or 363 ;-)

—
Reply to this email directly or view it on GitHub
#9 (comment)
.

Anatole Tresch
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon

Switzerland, Europe Zurich, GMT+1
Twitter: @atsticks
_Blogs: _http://javaremarkables.blogspot.ch/
http://javaremarkables.blogspot.ch/

Google: atsticksMobile [phone]

[keilw]

Thanks for the update, with regards to a standard repo or "Module Shop" we saw all kinds of ambitions with JavaBeans and later even Enterprise JavaBeans. One shop I used to sell such components 15 years ago was taken over by BEA which is now part of Oracle, but the shop had disappeared in obscurity before that. Mark simply said, there's always MavenCentral, and his talk also hinted, making these new models as compatible as possible with Maven or OSGi notion of modules is a goal, so we probably just see "yet another META-INF" entry, or at most even another archive, but the structure will most likely remain where Maven or Gradle can pick them up;-)

Cheers,
Werner

[atsticks]

Perfect!

2015-02-05 11:40 GMT+01:00 Werner Keil [email protected]:

Thanks for the update, with regards to a standard repo or "Module Shop" we
saw all kinds of ambitions with JavaBeans and later even Enterprise
JavaBeans. One shop I used to sell such components 15 years ago was taken
over by BEA which is now part of Oracle, but the shop had disappeared in
obscurity. Mark simply said, there's always MavenCentral, and his talk also
hinted, making these new models as compatible as possible with Maven or
OSGi notion of modules is a goal, so we probably just see "yet another
META-INF" entry, or at most even another archive, but the structure will
most likely remain where Maven or Gradle can pick them up;-)

Cheers,
Werner

—
Reply to this email directly or view it on GitHub
#9 (comment)
.

Anatole Tresch
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon

Switzerland, Europe Zurich, GMT+1
Twitter: @atsticks
_Blogs: _http://javaremarkables.blogspot.ch/
http://javaremarkables.blogspot.ch/

Google: atsticksMobile [phone]

[msgilligan]

To be clear a "Groovy module" is different from a JDK 9 module (they're really just add-on jar files.) The reason I created this issue/question is to make sure everyone is OK with the idea of moving the Groovy support to the Groovy project at some time in the future. I cannot guarantee that the Groovy project will accept it, but I have received preliminary feedback that is very positive.

Is everyone OK with the idea of moving Groovy support for Java Money API/RI to the Groovy project at some time in the future?

[atsticks]

As fas I see, I dont see anything that speaks against it ;)

2015-02-05 19:21 GMT+01:00 Sean Gilligan [email protected]:

To be clear a "Groovy module" is different from a JDK 9 module. The reason
I created this issue/question is to make sure everyone is OK with the idea
of moving the Groovy support to the Groovy project at some time in the
future. I cannot guarantee that the Groovy project will accept it, but I
have received preliminary feedback that is very positive.

Is everyone OK with the idea of moving Groovy support for Java Money
API/RI to the Groovy project at some time in the future?

—
Reply to this email directly or view it on GitHub
#9 (comment)
.

Anatole Tresch
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon

Switzerland, Europe Zurich, GMT+1
Twitter: @atsticks
_Blogs: _http://javaremarkables.blogspot.ch/
http://javaremarkables.blogspot.ch/

Google: atsticksMobile [phone]

[keilw]

Well if they have something similar to the "JEP" at OpenJDK, why not propose it;-)

[msgilligan]

They do have GEPs. When the proof-of-concept gets a little further along, I'll create one.

[msgilligan]

I've been moving ahead with JavaMoney support in the OmniJ project -- focusing on using NumberValue for representing quantities of Omni Layer currencies (aka Smart Properties) -- and have found a significant issue in Groovy GROOVY-7608 that limits the usefulness of DSLs using NumberValue (== doesn't work properly.)

So the next step as far as the Groovy project itself goes is to get this issue fixed. Groovy plans a major overhaul of how it handles operator overloading and related issues in Groovy 3.0, but I'd like to see a resolution for this in Groovy 2.5 (if it's not too late) or Groovy 2.6. I have some ideas about how this might be done and am willing to write unit tests and attempt to submit a pull request to get this fixed. As there are handful of related issues, I'm not sure I can limit the scope of a change and it might turn out to be too big or controversial of a change for me to get done as a side project. But I'll try to get a discussion going.

[msgilligan]

@keilw @atsticks If you could "vote" for GROOVY-7608 and talk to some of the Groovy developers about it at ApacheCon that would be awesome.

[keilw]

Will do. Though it only briefly mentions JSR-275 used by Groovy in Guillaume's DSL example, I will already briefly mention use cases in my standards talk tomorrow (p32 on http://events.linuxfoundation.org/sites/events/files/slides/ApacheBD_EU15_DataQuality_on_Mars.pdf)