Skip to main content

[JSR-354] Re: Time modelling and future extensions for 310

  • From: Simon Martinelli <simon.martinelli@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Re: Time modelling and future extensions for 310
  • Date: Fri, 28 Jun 2013 12:20:16 +0200

Hi Anatole,

This sounds good to me.
Specially that we can remove CurrencyValidityInfo.

Thanks


On Thu, Jun 27, 2013 at 10:04 PM, Anatole Tresch <atsticks@...> wrote:

> Hi all
>
> I was thinking about how we can better support the current as well as the
> future time APIs. I was thinking about using template parameters, but this
> makes the API rather useless. At the end I ended up, by a quite simply
> solution, which would be feasible with all areas, where we currently have
> time related types:
>
>    - I still model the timstamps using Long types
>    - I added additional methods to support the JDK 7 Calendar APIs and
>    will create corresponding Calendar instances on request.
>    - Using templates it is possible to support all implementations of
>    Calendar , when they have a parameterless constructor (which as far as
>    I know is true for all implementations that come with the JDK).
>
> As an example refer to:
>
> https://github.com/atsticks/javamoney/blob/master/money-api/ext/src/main/java/javax/money/ext/ValidityInfo.java
>
> The methods on ExchangeRate could be  modelled similarly.
>
> The advantages here are several:
>
>    - Since both classes are final, we can easily extend them in a
>    maintenance release to support access to the corresponding 310 types as
>    needed, without breaking any contracts.
>    - Since still two Long values are needed for the internal
>    representation the instance itself would still be serializable 
> compatible,
>    with former releases.
>    - As a side effect I also removed the CurrencyValidityInfo, since it
>    could be easily modelled by ValidityInfo directly. This makes it also
>    quite simple to add other ValidityInfos not related to regions.So
>    overall the extensions package size could be additionally reduced.
>
> Opinions? Do we need more here?
>
> Regards,
> 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
> Phone   +41-44 334 40 87
> Mobile  +41-76 344 62 79*
>


[JSR-354] Time modelling and future extensions for 310

Anatole Tresch 06/27/2013

[JSR-354] Re: Time modelling and future extensions for 310

Simon Martinelli 06/28/2013
 
 
Close
loading
Please Confirm
Close