Drop JodaMoney or make it a proper JSR 354 implementation

[keilw]

As JSR 354 EG Member, it would be perfectly legitimate to turn JodaMoney into a proper implementation. When can we expect that, otherwise, there is not a lot of reason to keep the project alive at all.

[jodastephen]

I'll evaluate whether Joda-Money should implement a spec at the appropriate time, when the spec is complete. From what I've seen so far, MonetaryAmount isn't something I'd consider implementing.

[keilw]

Like all other EG or JCP Members you're more than welcome to review it and make recommendations, but it's a democratic process and nobody except Anatole (or Oracle in some cases, see the way 310 evolved with things like TemporalAmount;-) has the last word or could dictate things into the spec.

[jodastephen]

TemporalAmount did not copy money in any way shape or form. It wasn't there originally, because it didn't make sense for it to be there at the time. Space was always available for it to be added at a later stage - the concept was known about. As the API was refined, it made sense to add it for JDK 1.8, as opposed to say 1.9. But adding it it has negatives as well as positives, converting some compile errors to runtime errors. So, perhaps you can stop claiming money inspired it now?

[keilw]

Well the Git repositories speak and its timing speak a slightly different language. If you can point to a single spec document of JSR 310 if they even exist so far where those ideas were defined a year ago or as far back as 2007, please do so. otherwise the optic doesn't seem right about your claim it had nothing to do with it. Even the change to Temporal* has both quite a few similarities to Monetary* (see http://en.wikipedia.org/wiki/Monetary_unit, the fact it's named CurrencyUnit was pretty much the only JodaMoney left-over, but fixed it to be interface) from JSR 354 or if you look at http://en.wikipedia.org/wiki/Day_(disambiguation) the description "A day is a unit of temporal measurement" brings us as far back as Unit-API and the 2 JSRs before it;-)

[jodastephen]

You appear to be accusing me of lying. No matter how many times I try to correct you, you appear to have a fixed view of 310, and its design. Frankly its not worth me responding to you anymore, as you are behaving just like a Troll.

[keilw]

OK. as of JCP this is the latest official EDR2 doc: http://jcp.org/aboutJava/communityprocess/edr/jsr310/guide-0.7.html While the word "temporal" exists once in a brief chapter, there is no single notion of any other new concept recently adopted from "elsewhere". I know, Roger's been driving this: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/006a15252fcc, and even before the JSR 360 EG started meeting, I was in constant touch with him and his 360 Co Spec Lead over JSR 354 and how to best facilitate it in the ME world. So he was very well aware of 354 and its API before refactoring these interfaces;-) Plus between the January EC F2F and his change about 2 weeks later, I had various discussions with Roger, Brian Goetz and others at the F2F/JUG Summit about issues of JSR 310. Including these odd interfaces he then eliminated with the new amount. See other tickets here.

[michaelklishin]

@keilw asking an author of an OSS project to shut the project down just because you want him to is pretty offensive (and incredibly optimistic) in and of itself.

Congratulations, @keilw, you win the GitHub Asshole of the Month award.

[keilw]

Who are you, the monkey on the back of Github then?;-D Stay with your Ruby stuff, and better not stick your nose into something (Java) you may not understand;-)

[keilw]

@jodastephen The code doesn't lie, that's enough, nor does Git history clearly stating Roger changed that. He made Oracle's view also very clear about that silly backport:

I don't think any serious companies would consider changing to use an incompatible and opensource library so I'm not concerned about the existence of another open source project. @michaelklishin As mentioned, you don't seem qualified to speak about Java projects, but this statement about the relevance of an OSS project (the Threeten effort here, at SF.net or java.net;-) was from Oracle itself;-D

[michaelklishin]

@keilw not sure how you came to that conclusion. I've been using Java and 4 other JVM languages for almost 10 years and have started or contributed dozens of open source project in JVM languages you can pretty easily find on GitHub.

But please keep going, your behavior will be reported to the EG you are on, so even more evidence of you juvenile and unprofessional behavior will help.

[keilw]

See my mail, don't bother continuing this discussion here, as the Git or Mercurial repo speaks enough truth in this matter;-)

[jodastephen]

For those reading this, the git repo simply indicates that Roger chose to take on the work once the requirements were decided. This thread indicates the discussion that led to the decision to make the change.

JSR-310 is now included in the plans for JDK 1.8, and integration within the rest of the JDK continues. No new separate specification document will be issued, as it is now part of the JDK, thus covered by that specification.

I remain open to constructive criticism and feedback, which can be sent by any open mechanism, such as GitHub issues, which is here for 310.

[keilw]

While on a separate thread, the whole TemporalAdder topic went as far back as https://github.com/ThreeTen/threeten/issues/122 One of the cases where indeed you or the team (Roger) followed a suggestion, later picked up in other threads (I don't read every thread for every JSR, especially as EC Member I need to review Dozens a week;-) @michaelklishin if Github may some day add "related to" for those tickets, this could be more transparent, e.g. if I see related items to the ticket I created;-) The Quantity vs. Amount discussion goes even further back than JSR 275 or 108, though it matters to everything these 2 resulted in (UCAR, Unit-API and of course Fantom;-) For most none of us "invented" that from scratch, most of the core concepts and theories were defined by folks like Andrew Kennedy, Martin Fowler or Roedy Green ages ago. Most of them in theoretical papers, a bit like Alan Turing's publications from the 30s compared to the computers later derived from his work. If any I'd say Andrew Kennedy deserves most of the credit in the area of units and measurements for IT systems. Despite the fact, he joined the "Dark Force" Microsoft;-D

[michaelklishin]

It's a real shame that JSR Expert Group members behave like this, especially on public forums. I don't have a dog in this fight and simply wanted to point out that this kind of demanding, condescending, rude and humorless behavior would be offensive to any maintainer.

[keilw]

Your plural is well taken, given @jodastephen is also in the same Expert Group;-)

[keilw]

Oddly enough, a slight shift of scope the Spec Lead decided (which in a sense goes alongside what @jodastephen suggested;-) JSR 354 shall come with the future JDK default base types built-in, so they're no longer part of a separate RI package or project. Thus with an equivalent or superior BigDecimal based default type Money in the JSR fewer to no people would require JodaMoney after all... Like I said, the decision was fueled by what @jodastephen asked for, but made by the Spec Lead based on various other discussions, probably also at conferences like the one yesterday.

[atsticks]

Sorry, to keep it short: its @jodastephen's own decision how JodaMoney will evolve, also JSR 354, which , if all works fine, will probably reach EDR state in some days, will not have to care about this. I hope that JSR 354 will be successful at the end, but I am sure, that if we waste our energies in such useless and let say it direct ugly discussions, we probably will fail this target. So @keilw please, please, please: be constructive, and nothing else. Or to say it differently Stephen with 310 and also JodaXXX has achieved things, we have to achieve first. And even, if have achieved them also, there is no reason for fighting against each other!

[keilw]

Thanks for your input. I think we came to some constructive progress in the JSR which could make it easier for @jodastephen to consider implementing it.