[JSR-354] Re: JSR 354 API Update
- From: Werner Keil <werner.keil@...>
- To: jcurrency_mail@...
- Subject: [JSR-354] Re: JSR 354 API Update
- Date: Mon, 29 Jul 2013 13:38:08 +0200
Beside other tests and the TCK, this looks like a very interesting test,
In fact, many parts of Java, particularly those also potentially used in
Small / Embedded environments should be tested that way. For some I'm
afraid this may come a bit too late, but we're at a stage where these "non
functional" requirements can still be looked upon and tested, too.
On Sun, Jul 28, 2013 at 10:53 PM, Werner Keil <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.
> 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