Skip to main content

[JSR-354] Re: JSR 354 API Update

  • From: Sascha Freitag <dunschtig@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Re: JSR 354 API Update
  • Date: Tue, 30 Jul 2013 22:18:41 +0200

Hi Werner,

yes that was not the intend, to switch to threeten. But from my point of view it give the answer, if it's worth to have something in this direction. So on JDK 7 base we will need to use something already there or mimic something in the example code into the direction of JDK8. So for Money API this means we need to stay on Long.

Cheers Sascha

On 28.07.2013 22:53, Werner Keil wrote:
Define what? Java 8 is not in scope for the JSR, a timestamp may for those running Java SE 8 already come from the java.time package and its elements, but neither API nor TCK must force people to use a particular Java version like 8. The minimum version is 7 (given 6 is at least officially deprecated soon, while it may still work for most of the core parts) so no dependency on 8 or 9, that could be for R2 of this API.

Werner

On Sun, Jul 28, 2013 at 10:13 PM, Sascha Freitag <dunschtig@... <mailto:dunschtig@...>> wrote:

    basically the 310 API will allow to implement such a scenario,
    when you only use now with a clock
    
(http://download.java.net/jdk8/docs/api/java/time/LocalDate.html#now%28java.time.Clock%29)
    and not the two other provided now methods.
    I think this is useful in same as well as in bigger libraries. And
    the questions with the threeten API is more, from where you get
    the Clock instance from and leaves you with that alone. But that
    is maybe also good, since it's was not the scope of the API to
    define this.


    On 17.07.2013 21:15, Anatole Tresch wrote:
    Basically also in our bank such discussions were initiated.
    Basically, when testing integrated systems this is a very
    functional way to simulate different time scenarios, eg year end
    processing.
    For testing smaller libraries i personally prefer to dynamically
    provide test data or services/mocks for the corresponding tests.
    This, contrary to the global solution, still allows isolation of
    my test cases/suites...

    Cheers

    -
    Anatole Tresch
    Gl√§rnischweg 10
    8620 Wetzikon
    Tel +41 (43) 317 05 30
    -
    Send from Mobile

    Am 17.07.2013 um 19:47 schrieb Werner Keil <werner.keil@...
    <mailto:werner.keil@...>>:

    This pattern for testing timestamps might be useful, too:
    http://www.javapractices.com/topic/TopicAction.do?Id=234
    While it (obviously) uses long, such a layer could also allow
    using multiple Date/Time APIs behind the scenes, and come handy
    for either simple unit tests or maybe those in the TCK, too.

    Since most parts of the API tend to consume a timestamp, using
    such an interface as part of the actual API may not help much,
    there, or does anybody feel it would benefit?

    Werner


--
    Sascha Freitag v/o Dunschtig




--

Sascha Freitag v/o Dunschtig



[JSR-354] Re: JSR 354 API Update

Werner Keil 07/16/2013

[JSR-354] Re: JSR 354 API Update

Werner Keil 07/17/2013

[JSR-354] Re: JSR 354 API Update

Anatole Tresch 07/17/2013

[JSR-354] Re: JSR 354 API Update

Werner Keil 07/18/2013

[JSR-354] Re: JSR 354 API Update

Tresch Anatole (KFSC 225) 07/18/2013

[JSR-354] Re: JSR 354 API Update

Werner Keil 07/18/2013

[JSR-354] Re: JSR 354 API Update

Sascha Freitag 07/28/2013

[JSR-354] Re: JSR 354 API Update

Werner Keil 07/28/2013

[JSR-354] Re: JSR 354 API Update

Werner Keil 07/29/2013

[JSR-354] Re: JSR 354 API Update

Werner Keil 07/30/2013

[JSR-354] Re: JSR 354 API Update

Sascha Freitag 07/30/2013

[JSR-354] Re: JSR 354 API Update

Werner Keil 07/30/2013
 
 
Close
loading
Please Confirm
Close