Re: custom Nano time provider

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()); //12 System.out.println(" = " + System.nanoTime()); // 144 System.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] 
> <mailto:[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 list
>>>     [email protected]  <mailto:[email protected]>
>>>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>>     _______________________________________________
>>     Concurrency-interest mailing list
>>     [email protected]  <mailto:[email protected]>
>>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>     _______________________________________________
>     Concurrency-interest mailing list
>     [email protected]
>     <mailto:[email protected]>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

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