[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.
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 (
> 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...
> 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:
> 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?
> Sascha Freitag v/o Dunschtig