Skip to main content

[JSR-354] Re: Public Review will be late - latest updates

  • From: Werner Keil <werner.keil@...>
  • To: "jcurrency_mail@javamoney java. net" <jcurrency_mail@...>
  • Subject: [JSR-354] Re: Public Review will be late - latest updates
  • Date: Fri, 27 Sep 2013 14:23:03 -0700

Stephen/all,

Thanks for the good discussion and effort.
It seems at least indirectly (he was also in the BOF) Oracle's Roger Riggs
got involved. It would be great if that would lead to some commitment by
Oracle as the EC Meeting in Zurich also suggested.

JodaMoney has quite some momentum, though it may be lesser known than
JodaTime. Including Bitcoin APIs and Wallets some of the authors told me
personally a better synergy with other Currency classes would be good.
Implementing this Spec could answer their needs and that of other similar
projects. Its API feels a bit different, but even well established Java
accounting tools like MoneyDance or ERP solutions like JFire are likely to
implement a rather slim spec, too.

Greetings from Social Media Week LA,
Werner
Am 27.09.2013 13:12 schrieb "Stephen Colebourne" <scolebourne@...>:

> Anatole, Werner and myself managed good work at JavaOne. I argued that
> the JSR should focus on the minimum necessary to be interoperable
> between different implementations, as that would also likely prove a
> good fit for JDK9.
>
> The current proposal was:
> CurrencyUnit
> - getCurrencyCode()
>
> MonetaryAmount
> - getCurrency()
> - getAmountWhole()
> - getAmountFractionNumerator()
> - getAmountFractionDenominator()
> - query(MonetaryQuery)
> - with(MonetaryAdjuster)
>
> MonetaryAdjuster
> - adjustInto(MonetaryAmount)
>
> MonetaryQuery
> - queryFrom(MonetaryAmount)
>
> MonetaryException
>
>
> These 4 interfaces and 1 exception would be the core. We need
> agreement from Oracle that they could envisage them being in JDK9
> together with a single Money class implementation.
>
> Formatting remains a little uncertain. In all likelihoods, the
> formatting needed for the JDK will be different to the formatting
> needed for an enterprise version. I expect the JDK to have a small
> formatter package that would not cover all needs, but would allow
> external libraries implementing the spec  to be formatted.
>
> With the new API above, Joda-Money is now in a position to implement
> the JSR. I consider that to be a big win.
>
> As Anatole mentioned, there would be the opportunity to provide an OSS
> project for "enterprise money" as well as an RI to prove the
> technology. It is conceivable that Joda-Money could be the reference
> implementation, however its simple enough that this group might as
> well have another.
>
> We should make efforts to check if other money libraries can implement
> the new simple spec.
>
> thanks
> Stephen
>
>
>
> On 24 September 2013 17:47, Anatole Tresch <atsticks@...> wrote:
> > Dear All,
> >
> > I just wanted to inform you, that the anticipated Public Review will be
> > postponed. Reason behind is that I, Stephen Colebourne and Werner Keil
> had a
> > couple of intense but very good discussions, which will have a direct
> effect
> > on our JSR. The outcome if it will be a great improvement and simplicity
> of
> > all code APIs and most of all, they lead to a possible great reduction of
> > the JSRs footprint overall.
> > I will drop another more detailed, when the code will be update,
> hopefully
> > tonight Pacific time. As first hint I would like to summarize our
> thinkings
> > as follow:
> >
> > the core API cam be reduced to CurrencyUnit, MonetaryAmount,
> > MonetaryAdjuster, MonetaryQuery and MonetaryException
> > the reference implementation will contain: Money, RoundedMoney,
> > MoneyCurrency, MonetaryFunctions, MonetaryRoundings,
> MoneyCurrencyProvider
> > and possible a simple MonetaryAmountFormatter
> >
> > The overall design was discussed and will be fully 310 styled, which
> makes
> > completely sense (see the details later).
> > Basically all other functionality defined so far, can
> >
> > The currernt format package will be moved to the extras part
> > The current exchange package will be moved to the extras part.
> > The current extensions part will be moved to the extras part.
> >
> > So basically, only the minimized core part will be left over as part of
> the
> > JSR. The reasons behind are
> >
> > After Public Review, we must deliver a full reference implementation and
> a
> > TCK. The current resources on the JDK will not allow to deliver all
> parts as
> > discussed so far in a reasonable time.
> > The basic core infrastructure clearly shows, that it is possible, to
> > implement such things on top of it. So the API supports all this things,
> > nevertheless it is questionable, if our JSR also should standardize them,
> > within this first release-
> > Finally all artifacts written so far, are not lost. We plan to move them
> > over into their own OSS project, where they can be used and further
> > developed, by whoever may profit of them.
> > Additionally, when also Jodamoney would support this JSR, these
> extensions
> > done would, completely interoperable with Jodamoney and also other
> > implementations, since they share the same common mechanisms.
> > Basically for a version 1.0 JSR is is a reasonable scope, we can still
> do a
> > maintenance release later, if there is reason to add more functionality.
> >
> > So basically, beside that neither the code base nor the spec currently
> > reflects these aspects, everybody is invited to leave his comments... ;-)
> >
> > Cheers,
> > Anatole
> >
> > --
> > Anatole Tresch
> > Java Lead Engineer, JSR Spec Lead
> > Gl√§rnischweg 10
> > CH - 8620 Wetzikon
> >
> > Switzerland, Europe Zurich, GMT+1
> > Twitter:  @atsticks
> > Blogs: http://javaremarkables.blogspot.ch/
> > Google: atsticks
> > Mobile  +41-76 344 62 79
>


[JSR-354] Public Review will be late - latest updates

Anatole Tresch 09/25/2013

[JSR-354] Re: Public Review will be late - latest updates

Stephen Colebourne 09/27/2013

[JSR-354] Re: Public Review will be late - latest updates

Werner Keil 09/27/2013
 
 
Close
loading
Please Confirm
Close