Skip to main content

[JSR-354] Re: JSR 354 API Update

  • From: Werner Keil <werner.keil@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Re: JSR 354 API Update
  • Date: Sun, 28 Jul 2013 22:53:53 +0200

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@...> 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@...>:
>
>  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
>
>


[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