Without commenting on the proposed implementation below, Future seems like
a good place to start. I suspect that ExecutorService and
ScheduledExecutorService would also be good targets to enhance.
Stephen
On Fri, 15 Jun 2018, 18:43 Martin Buchholz, wrote:
>
>
> On Wed, May 30, 2018 at 11:32 AM,
On Wed, May 30, 2018 at 11:32 AM, Doug Lea wrote:
>
> The original rationale for designing j.u.c.TimeUnit using the Flyweight
> pattern was to to reduce allocation and GC-related overhead and timing
> jitter for methods that otherwise may operate on the order of
> nanoseconds. But there are many
Finally got to check the logic in convert(Duration), and it looks fine to me.
All three look good
thanks
Stephen
(not an OpenJDK reviewer).
On 6 June 2018 at 18:03, Martin Buchholz wrote:
> OK, here is a RFR for low-hanging changes (some of these changes have
> already been reviewed by some of
Hi Martin,
All three look fine to me. +3
Roger
On 6/6/18 1:03 PM, Martin Buchholz wrote:
OK, here is a RFR for low-hanging changes (some of these changes have
already been reviewed by some of you):
8204375: Add TimeUnit#convert(Duration)
OK, here is a RFR for low-hanging changes (some of these changes have
already been reviewed by some of you):
8204375: Add TimeUnit#convert(Duration)
http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/convertDuration/index.html
https://bugs.openjdk.java.net/browse/JDK-8204375
JDK-8204375: Add TimeUnit#convert(Duration)
Looks like if you switch representation for negative Duration, much of the
hair goes away.
This version also optimizes for NANOSECONDS, which is very likely to be the
target in practice:
public long convert(Duration duration) {
long secs = duration.getSeconds();
int nano =
TimeUnit#toDuration is gone.
Here's a non-strawman attempt at TimeUnit#convert(Duration).
I was astonished how hard it was to get this really correct instead of
merely mostly correct.
For negative numbers, the long/int representation of Duration is sort-of a
"floored" division instead of java's
I am not sure I understand this implementation, but isn’t
>long s = convert(duration.getSeconds(), SECONDS);
needing to actually be
>long s = convert(duration.getSeconds(), NANOSECONDS);
so that s+n is in a common unit of measure?
Gregg
> On May 30, 2018, at 7:19 PM, Martin
I'm not convinced TimeUnit::toDuration(long amount) has enough value.
We don't have a similar method on ChronoUnit
Duration.of(amount, timeUnit.toChronoUnit()) seems sufficient. Maybe
document this in the convert(Duration) method?
Stephen
On 31 May 2018 at 01:19, Martin Buchholz wrote:
>
In j.u.concurrent the APIs bottom out in something that just takes a long
nanos, like LockSupport.parkNanos, so there's no advantage to converting to
TimeUnit-based durations greater than 292 years. And returning multiple
values in Java remains clumsy.
On Wed, May 30, 2018 at 11:06 PM, Peter
Just thinking loud...
On 05/30/18 19:36, Martin Buchholz wrote:
Obvious progress would seem to be more conversion methods. Conversion code
tends to be annoying/errorprone because of having to deal with overflow.
Stephen/Doug: is there any reason we didn't add conversions between
Duration and
On Wed, May 30, 2018 at 7:43 PM, Gregg Wonderly wrote:
> I am not sure I understand this implementation, but isn’t
>
> >long s = convert(duration.getSeconds(), SECONDS);
>
> needing to actually be
>
> >long s = convert(duration.getSeconds(), NANOSECONDS);
>
> so that s+n is in a
v.0.2 has both conversion methods in TimeUnit. The unexpected weirdness is
that convert(Duration) saturates while toDuration throws
ArithmeticException, but both seem author-culture-consistent. Perhaps
TimeUnit#toDuration doesn't provide enough value in view of the existing
Duration.of and
Kurt's initial post did not make it to concurrency-interest. At this
point, it is probably least confusing if interested readers who aren't
on core-libs-dev follow this on archives:
http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev
On 05/30/2018 01:36 PM, Martin Buchholz wrote:
>
On 30 May 2018 at 18:15, Kurt Alfred Kluever wrote:
> 1. Rename ALL existing unitless primitive method parameters to include
> their time unit.
This seems like a simple win. AFAIK, parameter names can be changed
freely in the JDK.
> 2. Add a java.time overload to some APIs ...
> Note that new
On 30 May 2018 at 18:36, Martin Buchholz wrote:
> Stephen/Doug: is there any reason we didn't add conversions between Duration
> and TimeUnit when we added conversions to ChronoUnit?
I don't remember the idea being discussed. The proposed implementation
seems reasonable.
thanks
Stephen
>
Obvious progress would seem to be more conversion methods. Conversion code
tends to be annoying/errorprone because of having to deal with overflow.
Stephen/Doug: is there any reason we didn't add conversions between
Duration and TimeUnit when we added conversions to ChronoUnit?
Here's a
18 matches
Mail list logo
