Re: custom Nano time provider

Well, mock will work only if you know the Queue is not going to call
nanoTime. As such, this is a dangerous assumption.

Alex

On Mon, 6 Apr 2020, 13:52 Thorsten via Concurrency-interest, <
[email protected]> wrote:

> You can replace 1234 with whatever logic you want ,  so  yes a queue seems
> a natural choice
>
> final MockUp mockUp = new MockUp(System.class) {
>     private final Queue<Long> objects = new LinkedBlockingQueue(List.of(12L, 144L));    @Mock    long nanoTime() {
>         return objects.poll();    }
> };System.out.println(" = " + System.nanoTime()); //12System.out.println(" = " + System.nanoTime()); // 144System.out.println(" = " + System.nanoTime()); // dies miserably
>
> Or he what about this
>
> final MockUp mockUp = new MockUp(System.class) {
>     private final Iterator<Long> objects = LongStream.iterate(20, x -> x + 1).iterator();    @Mock    long nanoTime() {
>         return objects.next();    }
> };
>
> > That's why I still think it would beneficial to have something different
> from a mocked solution, but a proper API extension that unify the usage of
> temporal info.
>
> I kind of fail to see how that would work differently from what you can do
> with Mocks.  You get your callback and you can do whatever you want and if
> your code is stupid enough you might blow up your application ;)
>
> I dont't whant to argue about this, just showcasing for reference that one
> can return reproducible values from System#nanoTime without to much effort
> and without requiring a new API.
>
> Best regards,
>
> Thorsten
> Am 06/04/2020 um 14:18 schrieb Alex Otenko:
>
> How does that work for a sequence of timestamps you want to feed?
> (Assuming you will need some j.u.c.Queue for this...)
>
> Alex
>
> On Mon, 6 Apr 2020, 11:54 Thorsten via Concurrency-interest, <
> [email protected]> wrote:
>
>> Hello
>>
>> To expand on Peters answer: For testing purpose to get reproducible
>> results you might to look into some mocking frameworks.
>>
>> For example in jmockit i can just do this
>>
>> final MockUp mockUp = new MockUp(System.class) {
>>     @Mock    long nanoTime() {
>>         return 1234;    }
>> };System.out.println(" = " + System.nanoTime());
>>
>> Boom custom nanoTime Provider.
>>
>> Best regards,
>>
>> Thorsten Goetzke
>> Am 06/04/2020 um 11:55 schrieb Peter Levart via Concurrency-interest:
>>
>> You could perhaps use bytecode instrumentation (
>> https://www.baeldung.com/java-instrumentation) to "patch" System class
>> and redirect/delegate it's execution to your custom time source.
>>
>> Peter
>>
>> On 4/5/20 1:23 PM, Francesco Nigro via Concurrency-interest wrote:
>>
>> Hi folks,
>>
>> In the recent period I am working on some high availability solution in
>> the project I currently work and I have noticed how is important for
>> testing purposes to use custom System::currentTimeMillis and
>> System::nanoTime providers to trigger specific reproducible conditions:
>> there is any plan to allow something similar in some of the concurrent
>> primitive that make uses of such functions?
>> I believe this could help both implementors and users.
>>
>>
>> Thanks,
>> Franz
>>
>> _______________________________________________
>> Concurrency-interest mailing [email protected]://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing [email protected]://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> [email protected]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
> _______________________________________________
> Concurrency-interest mailing list
> [email protected]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest