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@... <mailto: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
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
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...
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
|Tresch Anatole (KFSC 225)||07/18/2013|
[JSR-354] Re: JSR 354 API Update