Re: RFR: 8266846: Add java.time.InstantSource

2021-05-15 Thread Ralph Goers
On Thu, 13 May 2021 20:52:33 GMT, Stephen Colebourne wrote: > 8266846: Add java.time.InstantSource Can you possibly find a way that this can be used in a garbage free manner? Providing a MutableInstant interface that allows the Instant object to be provided and have its values set by a

Re: RFR: 8266846: Add java.time.InstantSource

2021-05-15 Thread Istvan Neuwirth
On Thu, 13 May 2021 20:52:33 GMT, Stephen Colebourne wrote: > 8266846: Add java.time.InstantSource src/java.base/share/classes/java/time/InstantSource.java line 93: > 91: * @since 17 > 92: */ > 93: public interface InstantSource { Should not we add `@FunctionalInterface`? I can easily

Re: JEP draft: Scope Locals

2021-05-15 Thread Peter Levart
Hi, So if scopeLocal.get() is called in a thread outside any .run() scope in that thread, it will throw exception and scopeLocal.isBound() will return false. Unless it was called on an inheritableScopeLocal which inherited binding from parent thread. What if I wanted to create and start a

Re: JEP draft: Scope Locals

2021-05-15 Thread Remi Forax
Apart the performance, threadLocal has currently two issues that are addressed by scope locals. ThreadLocal let the programmer defines the lifecycle, while it seems great on paper, it's a huge mess in reality. Because not everybody wraps the calls to set()/remove() in a try/finally, so the

Re: JEP draft: Scope Locals

2021-05-15 Thread Andrew Haley
On 5/15/21 10:10 AM, Alex Otenko wrote: > ScopeLocal.where(...).run(...).finally(...) would be nice. Is that different from try ... run ... finally ? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98

Re: JEP draft: Scope Locals

2021-05-15 Thread Andrew Haley
On 5/14/21 8:19 PM, Mike Rettig wrote: > I don't see a way to capture the lifecycle of the scoped variable. I think > for framework designers it's going to be important to know the life cycle > of the scoped variable especially with snapshotting and inheritance. The > lack of a defined life cycle

Re: RFR: 8266846: Add java.time.InstantSource

2021-05-15 Thread Michael Hixson
On Thu, 13 May 2021 20:52:33 GMT, Stephen Colebourne wrote: > 8266846: Add java.time.InstantSource src/java.base/share/classes/java/time/InstantSource.java line 68: > 66: * @implSpec > 67: * This interface must be implemented with care to ensure other classes > operate correctly. > 68: *

Re: RFR: 8266846: Add java.time.InstantSource

2021-05-15 Thread Stephen Colebourne
On Fri, 14 May 2021 07:19:03 GMT, Anthony Vanelverdinghe wrote: >> 8266846: Add java.time.InstantSource > > src/java.base/share/classes/java/time/Clock.java line 513: > >> 511: * {@link System#currentTimeMillis()} or equivalent. >> 512: */ >> 513: static final class

Re: RFR: 8266846: Add java.time.InstantSource

2021-05-15 Thread Naoto Sato
On Thu, 13 May 2021 20:52:33 GMT, Stephen Colebourne wrote: > 8266846: Add java.time.InstantSource src/java.base/share/classes/java/time/Clock.java line 2: > 1: /* > 2: * Copyright (c) 2012, 2019, 2021, Oracle and/or its affiliates. All > rights reserved. `2019, ` should be removed.

RFR: 8266846: Add java.time.InstantSource

2021-05-15 Thread Stephen Colebourne
8266846: Add java.time.InstantSource - Commit messages: - 8266846: Add java.time.InstantSource - 8266846: Add java.time.InstantSource Changes: https://git.openjdk.java.net/jdk/pull/4016/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4016=00 Issue:

Re: RFR: 8266846: Add java.time.InstantSource

2021-05-15 Thread Anthony Vanelverdinghe
On Thu, 13 May 2021 20:52:33 GMT, Stephen Colebourne wrote: > 8266846: Add java.time.InstantSource A nice addition to the JDK, thanks for taking this on. src/java.base/share/classes/java/time/Clock.java line 114: > 112: * provides access to the current instant, and does not provide access

Re: JEP draft: Scope Locals

2021-05-15 Thread Andrew Haley
On 5/15/21 12:28 AM, Nathan Reynolds wrote: > What about cleanup of the scoped objects? For example, how do I ensure > close() or some cleanup method is called at the right time on the scoped > object? Do I need to use a Weak/Soft/PhantomReference and a ReferenceQueue > to track the object? Do