Skip to main content

[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

  • From: Werner Keil <werner.keil@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED
  • Date: Sat, 2 Feb 2013 21:12:33 +0100

Sounds fair.

Please note, that's a standalone RI "draft", but nothing should keep us from phrasing and naming relevant types there accordingly.
Like the separation between Money and BigMoney (actually both backed by BigDecimal) in JodaMoney were odd and misleading, at least the default monetary type despite an internal representation possibly being BigDecimal, too, doesn't have to be named by that.

At the moment, the RI implements CurrencyUnit via the JDKBridge, but of course, in any actual RI either SE or ME it's likely going to be java.util.Currency or an adequate replacement for it (only ME, but for backward compatibility, I assume the class might remain there, too)


On Tue, Jan 29, 2013 at 12:24 PM, Jeremy <jerdavies@...> wrote:
+1 for Money over BigDecimalAmount. BDA could be mistaken for a scientific
style calculation, rather than being specific to money

-----Original Message-----
From: jodastephen@... [mailto:jodastephen@...] On Behalf Of
Stephen Colebourne
Sent: 29 January 2013 11:15
To: jcurrency_mail@...
Subject: [JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

On 29 January 2013 07:37, Anatole Tresch <atsticks@...> wrote:
> (interface)
> (class, naming to be discussed), also
> allowing to map from java.util.Currency (implementation for current
> ISO only) (interface)
> (implementation of MonetaryAmount)
> possibly also DoubleAmount (implementation of MonetaryAmount)
> (interface, naming to be discussed)
> (implementation of Exchange, naming to be
> discussed)

I would be proposing something fairly similar.

The JDK Currency class is a value type. It supports adding additional

It supports date-times on which a currency change will occur (JDK 1.8).
It could be enhanced further if this JSR can think of anything else needing
I maintain that this Currency class is sufficient for use in the JDK (unlike
java.util.TimeZone which was mutable and therefore required

I would strongly argue that you need a class called Money, not
BigDecimalAmount. It would be the only money class in the JDK.

The interface MonetaryAmount can be defined in terms of long rather than
BigDecimal if you place a limit of 18 digits on the fraction and on the
whole-part, thus returning the data as two longs and a scale.

I'm not certain that exchange rates need to be in the JDK, although I can
see benefits to doing so.

The real design questions are around pluggable logic for calculations.
But start from solid value types and you won't go too far wrong.

The more complex requirements should be dealt with separately, either as a
second EE spec or an OSS project. It is important to know what those
requirements are so that they are enabled and not blocked by the core JDK


> More advanced use cases such as localizing currencies per locale,
> regions, currency mapping and historization must be separated, since
> they seem, with such a restrictive view on how things must be
> designed, not adequately to match to SE.
> So the question still is: IS WHAT WE WANT TO ACHIEVE WITH THIS JSR. If
> the restriction of using value types instead of interfaces (which I
> personally think is not really a good solution: instead of, it would
> be much more useful to think about some language features to cover
> such immutability requirements), restricts us to only providing some
> immutable data containers, also implemented in a highly coupled
> manner, I personally have the feeling that we greatly have to reduce
> our scope here if we only want to target SE (see above). This is the
> reason, why I started also to think about EE. But alternately one can
> also think about doing such things within some OSS project ;-)
> So I think the discussion is open. And for the ones that may argue,
> that this discussion is never ending like last summer: I think it is
> crucial that we discuss these point down to the bones. We have to
> establish here something like a common sense. I personally try to put
> my fingers on the wounds, so we are able to really identify the
> advantages/disadvantages of the different variants. And as I said, we
> have urgently to come to a clear
> statement:
> - are the requirements as outlined by Stephen really are the last
> words, especially seen from a JDKs modularization point of view
> (@Stephen/all : who on Oracle side can be here a good contact?)
> - What are the use cases, we really want to cover? is SE the right
> place for
> (all) what we would like to achieve?
> - What about the requirements/features that may not match SE -> EE?
> Somewhere else?
> One key are for sure the use cases we want to cover. My draft EDR
> version tries to list some of them. If we agree on this use cases to
> provide something that allows to cover really 80% of cases along with
> monetary amounts, different currency schemes and the lacks of ISO
> 4217, I fear SE will be to restrictive and not appropriate to fit them
> all If we want to concentrate on simple ones, like a web shop or just
> a monetary representation, then just adding a few immutable data
> containers to SE is feasible.
> So again, discussion is open!
> Regards,
> 2013/1/29 Werner Keil <werner.keil@...>
>> Anatole/all,
>> As mentioned in the separate reply to Jez/Stephen's conversation,
>> taking the part that's mostly in "temporal" of java.time in an
>> appropriate manner for money and currency (hence a possible draft is
>> an interface like Monetary or the current form MonetaryAmount and
>> CurrencyUnit, that also driven by the existing JDK class) as inspiration.
>> As you may know, the "format" module is much more inspired by
>> JodaMoney anyway, so it shows quite some similarities.
>> One aspect 310 is simply missing and Date/Time needs in far less
>> cases except "show me a year in seconds" is conversion between monetary
>> While concrete implementations may be restricted to a monetary type
>> provided with such RI, like the suggested Money class, and ISO
>> currencies, the general contract of conversion at least along the
>> lines of what's identified so far should be there, too. Without
>> predicting how modular SE 9 will be in the end, this could be an
>> "optional" module of a future JDK, but except for maybe the part that
>> sits on top of java.util.Currency used across a vast majority of
>> other APIs I would say even formatting could be optional or at least
modular here.
>> Werner
>> On Mon, Jan 28, 2013 at 11:52 PM, Werner Keil <werner.keil@...>
>> wrote:
>>> Anatole,
>>> Thanks a lot for starting that thread.
>>> As mentioned in the SPI discussion once or twice, it's not all black
>>> or white in SE either. The whole ServiceProvider mechanism is the
>>> best example beside other SE frameworks like Collection API.
>>> As a matter of fact, the final Currency class internally makes heavy
>>> use
>>> of:
>>> rovider.html
>>> It may just be badly documented, but theoretically one could add
>>> another implementation if you handle classloading the right way.
>>> E.g. I provided a drop-in translation for JDK's Swing by adding
>>> resource bundles in the right place like jre/lib/ext (haven't tried
>>> that in a long time, but according to StackOverflow it still exists for
Java 7:
>>> -in-lib-ext-work-instead-of-using-a-classpath-on-window)
>>> So it's a question of good API design whether you allow this or not.
>>> Even
>>> 310 has a few extension points. Not as many as people who want e.g.
>>> to deal with working days vs. bank holidays may wish, but e.g. the
>>> package contains out of the box extensions to "Chrono" while the
>>> abstract base class allows other cultures to add further calendars.
>>> Not everything is final and inflexible in SE either, and Java 9 with
>>> aim for modularity will demand even more of that.
>>> The real question is not SE vs. EE, but having the RI under an
>>> Umbrella like SE as opposed to a standalone RI.
>>> The timeframe of SE 9 is relatively predictable, some time around 2
>>> years from now.
>>> EE 8, which could benefit from a standalone implementation (let's
>>> leave ME and CLDC 8 aside, as they are not real Umbrella JSRs, but
>>> effectively it would be similar) isn't likely to come out right next
>>> year either to be quite honest. If you look at EE 6, that went
>>> public in December 2009, so it was roughly 3 years ago, and 3 1/2
>>> years before the projected EE 7 release timeframe this spring. It is
>>> unlikely even with a drastically reduced scope, that EE 8 will launch
more than 2 years from now either.
>>> Making up the mind about the preference inside the EG is a good
>>> idea, while the ultimate decision about where they feel they want to
>>> include such JSR is up to Umbrella JSR Spec Leads of either EE or
>>> SE. It's probably a good idea to seek their input, too.
>>> When Victor last spoke about that, I believe he had some
>>> conversation with Brian, Mark or others, mainly signalling, that
>>> given stuff that's already been deferred to SE 9 and the progress of
>>> the JSR they would not consider it for SE 8, as the proposal stated.
>>> Given the modular nature of SE 9, it could be a good idea to ask them.
>>> Even before modularity, Swing by far isn't the only "javax" package.
>>> What's considered SE 7 is full of it:
>>> There are more main packages under javax. thatn java in all of that.
>>> JSR 6, javax.print is a good example, also defines both interfaces
>>> like Doc and concrete implementations like SimpleDoc, a final class,
>>> but for a good reason there is an interface defining the behavioral
>>> contract and allows extensions, despite those kinds of JSRs having
>>> been a part of the Java SE platform almost forever.
>>> Regards,
>>> Werner
>>> Am 28.01.2013 21:43 schrieb "Anatole Tresch" <atsticks@...>:
>>>> Dear all!
>>>> For me it is crucial that we really know what for a SE targeting
>>>> JSR is really required by Oracle. Whereas in an EE context
>>>> decoupling is absolutely crucial, so interfaces are really the
>>>> better way accessing "things", we have to discuss these things in a
>>>> SE context obviously. Personally if it is really required as
>>>> described by Stephen (which I guess is the case, thanks Stephen), I
>>>> am asking me, also having a in mind the complexity of use cases seen,
if we are not better to target both EE and SE, or even EE without SE.
>>>> Let me explain a bit my considerations:
>>>> Variant 1: Separation into a SE and EE part:
>>>> In the SE part:
>>>> we define the interfaces for a simple CurrencyUnit, and adapt the
>>>> java.util.Currency class accordingly. We keep the interface simple
>>>> and stupid (no historization, no attributes or extensions), just
>>>> supporting one single namespace (ISO-4217).
>>>> we define the interface for MonetaryAmount and provide an
>>>> implementation based on BigDecimal, with all the of(XX) factories
>>>> on it and what else is required. I assume BD is currently a
>>>> feasible way to go, though we know that it is not sufficient for all
usage scenarios.
>>>> we define the arithmetics and the precision handling and the
>>>> serialization format.
>>>> As we know already that will fit well for simple usage scenarios,
>>>> the more complex ones must be defined outside of SE, since it makes
>>>> not sense to build these aspects in stone, so
>>>> in the EE part:
>>>> we define the other (extended) things, such as
>>>> API/SPI for multiple numeric representations.
>>>> API/SPI for custom currency support API/SPI for currency
>>>> historization API/SPI for currency exchange API/SPI for extended
>>>> formatting API/SPI for extensions (if needed at all)
>>>> Or we throw away completely the SE restrictions and focus directly
>>>> Variant 2: Leaving SE for EE:
>>>> GO for an EE specification leaving SE as is also has its advantages:
>>>> the current JDKs classes can easily be adapted (as they are adapted
>>>> in our current RI), so we can introduce the concepts here for
>>>> several JDKs, e.g. starting from JDK 7.
>>>> the main behaviour can be modelled and defined by interfaces as of
>>>> now, leaving much more details to the implementations. This would
>>>> us also allow to easily provide the flexibility that has shown to
>>>> be required by many of the real world use cases (see attachment).
>>>> At a first look, this looks like a complete off-topic. But when a
>>>> think about our sometimes really ugly discussions here, it may be
>>>> worth to think about. Both variants would allow as to focus on the
>>>> requirements specific to SE/EE. Also since we have seen that it is
>>>> very difficult to create one-fits-it-all solution, we perhaps have
>>>> to abandon the objective of creating a SE implementation that is
exactly doing that.
>>>> All variants would us also easily allow to keep in mind (not
>>>> targeting) as a side-effect (indirectly, not explicitly) ME. In all
>>>> scenarios I do not see this JSR will directly be able to provide
>>>> the ME part by itself. The ME colleagues (and Werner ;-)) may open
>>>> their own JSR and use the stuff defined in our JSR as a starting
>>>> point ;-) When done well the API may look quite similar, though it was
defined in two separate JSRs.
>>>> We have to agree on this aspects, since this is really crucial! So,
>>>> all EG members are invited to give their opinions on this!
>>>> Regards,
>>>> --
>>>> Anatole Tresch
>>>> Java Lead Engineer, JSR Spec Lead
>>>> Glärnischweg 10
>>>> CH - 8620 Wetzikon
>>>> Switzerland, Europe Zurich, GMT+1
>>>> Twitter:  @atsticks
>>>> Blogs:
>>>> Google: atsticks
>>>> Phone   +41-44 334 40 87
>>>> Mobile  +41-76 344 62 79
> --
> Anatole Tresch
> Java Lead Engineer, JSR Spec Lead
> Glärnischweg 10
> CH - 8620 Wetzikon
> Switzerland, Europe Zurich, GMT+1
> Twitter:  @atsticks
> Blogs:
> Google: atsticks
> Phone   +41-44 334 40 87
> Mobile  +41-76 344 62 79

[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

Werner Keil 02/02/2013
Please Confirm