> On Jun 19, 2018, at 9:11 AM, Zheka Kozlov wrote:
>
> The function you propose is just a binary variant of mapping:
>
> Collector mapping(
> Function mapper,
> Collector downstream);
>
> (omitted '? super' for readability)
>
> So, it
The function you propose is just a binary variant of mapping:
Collector mapping(
Function mapper,
Collector downstream);
(omitted '? super' for readability)
So, it is logical to use the name biMapping:
Collector biMapping(
On Mon, Jun 18, 2018 at 10:19 PM, David Holmes
wrote:
>
> I'm unsure why we're trying to make this particular class
> unsafe-publication-proof, but I guess it's generally a good thing.
The particular field we're changing is a """final""" field, and it would be
pretty embarrassing to grab a stal
On 19/06/2018 3:08 PM, Martin Buchholz wrote:
Latest version looks like this:
public Object clone() {
try {
@SuppressWarnings("unchecked")
CopyOnWriteArrayList clone =
(CopyOnWriteArrayList) super.clone();
clone.resetLoc
Latest version looks like this:
public Object clone() {
try {
@SuppressWarnings("unchecked")
CopyOnWriteArrayList clone =
(CopyOnWriteArrayList) super.clone();
clone.resetLock();
+// Unlike in readObject, here we can
Discussions on the CSR request have led to further changes to the
documentation involving nests and the new nest-related method. There are
no semantic changes here just clearer explanations.
Incremental webrev:
http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.corelibs.v7-incr/
(don'
> On Jun 19, 2018, at 1:21 AM, Brian Goetz wrote:
>
> distributing?
>
> On 6/18/2018 6:04 PM, Chris Hegarty wrote:
>>
>>> On 18 Jun 2018, at 22:29, Brian Goetz wrote:
>>>
>>> "bisecting" sounds like it sends half the elements to one collector and
>>> half to the other ...
>>>
>>> "tee" mi
On 19/06/2018 6:01 AM, Doug Lea wrote:
On 06/18/2018 11:22 AM, Martin Buchholz wrote:
Or better, lockField.set in resetLock could instead be setRelease.
Except it is using reflection, not VarHandles. So it could be preceded
with VarHandle.releaseFence(), although it is hard to th
On 6/17/18 4:23 PM, Peter Levart wrote:
My attempt to optimize the Map.copyOf() was also using just public APIs (with
the addition of an internal class).
Well, it does speed-up Map.copyOf() by 30%. But I agree there are other
approaches that could go even further. In particular when all int
Hi,
Could I have a review of an enhancement that will make it possible to
add JFR events to java.base, and possibly other modules in the JDK,
without a compile time dependency on jdk.jfr.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8203629
Webrev:
http://cr.openjdk.java.net/~egahlin/820362
Looks good Liam; thanks,
-Joe
On 6/15/2018 10:58 AM, Liam Miller-Cushon wrote:
Hello,
This change is a follow-up to JDK-7183985 which replaces the interior of
parseClassArray, parseEnumArray, and parseAnnotationArray with a shared
method that is passed a lambda for the type-specific parsing lo
On 6/18/18 7:25 AM, Roger Riggs wrote:
In regard to new SharedSecret interfaces, one option is move shared (but
private) implementation classes
to a jdk.internal.xx package (not exported). This only works well if they are
not tightly coupled to other
package private classes.
SpinedBuffer m
On 6/17/18 1:50 AM, Peter Levart wrote:
It's a little strange that the generator function is used to construct an
empty array (at least in the default method, but overrides will likely do the
same if they want to avoid pre-zeroing overhead) in order to just extract the
array's type from it. So
On Jun 18, 2018, at 2:29 PM, Brian Goetz wrote:
>
> "bisecting" sounds like it sends half the elements to one collector and half
> to the other …
The main bisection or splitting operation that's relevant to a stream is what
a spliterator does, so this is a concern.
Nobody has mentioned "unzipp
+1 from me.
> On Jun 14, 2018, at 9:02 PM, Stuart Marks wrote:
>
> Hi all,
>
> I wanted to restart review of the changeset for bug JDK-8060192 [1]. The
> latest webrev is here: [2].
>
> The previous review was from December 2017: [3]. The only difference between
> the current changeset and t
Tagir Valeev wrote:
If you are going to create long-living array which is likely to be empty,
it's good to deduplicate them to spare the heap space. This can be easily
done via existing toArray method like
collection.toArray(MyClass.EMPTY_ARRAY) assuming we have an empty array
constant. We us
Hi Rémi,
On 6/15/18 12:26 AM, Remi Forax wrote:
The overrides I had previously provided in specific implementation classes like
ArrayList actually are slower, because the allocation of the array is done
separately from filling it. This necessitates the extra zero-filling step. Thus,
I've removed
Hi, Roger
On 6/18/18 7:31 AM, Roger Riggs wrote:
The CSR and Webrev are updated.
webrev:
http://cr.openjdk.java.net/~rriggs/webrev-static-property-8066709
* src/java.base/share/classes/java/lang/System.java :
Should the @implNote with the list of cached properties be added
everywhere th
Hi Peter,
Existing composing collectors tend to unpack all the functions of the input
collector ahead of time, i don’t recall being too concerned about this at the
time. It does allow for more robust null checking, something we were less
diligent about doing.
Paul.
> On Jun 17, 2018, at 3:04
yes, the proposed new methods would use nulls differently. The original
get() behavior of creating a mapping was a mistake, inconsistent with Map.
Yes, it will cause confusion. But it's already confusing.
On Mon, Jun 18, 2018 at 1:45 PM, David Lloyd wrote:
> On Mon, Jun 18, 2018 at 12:53 PM, M
distributing?
On 6/18/2018 6:04 PM, Chris Hegarty wrote:
On 18 Jun 2018, at 22:29, Brian Goetz wrote:
"bisecting" sounds like it sends half the elements to one collector and half to
the other ...
"tee" might be a candidate, though it doesn't follow the `ing convention.
"teeing" sounds du
> On 18 Jun 2018, at 22:29, Brian Goetz wrote:
>
> "bisecting" sounds like it sends half the elements to one collector and half
> to the other ...
>
> "tee" might be a candidate, though it doesn't follow the `ing convention.
> "teeing" sounds dumb.
Doesn’t follow the convention either, bu
Replicator (as in DNA)
Sent from my iPhone
> On Jun 18, 2018, at 6:49 PM, James Laskey wrote:
>
> Bifurcate
>
> Sent from my iPhone
>
>> On Jun 18, 2018, at 6:29 PM, Brian Goetz wrote:
>>
>> "bisecting" sounds like it sends half the elements to one collector and half
>> to the other ...
>
Bifurcate
Sent from my iPhone
> On Jun 18, 2018, at 6:29 PM, Brian Goetz wrote:
>
> "bisecting" sounds like it sends half the elements to one collector and half
> to the other ...
>
> "tee" might be a candidate, though it doesn't follow the `ing convention.
> "teeing" sounds dumb.
>
>
>
Agreed. Not sure if this has been suggested, but what about duplex(ing)?
On Mon, Jun 18, 2018 at 5:29 PM Brian Goetz wrote:
> "bisecting" sounds like it sends half the elements to one collector and
> half to the other ...
>
> "tee" might be a candidate, though it doesn't follow the `ing
> conve
"bisecting" sounds like it sends half the elements to one collector and
half to the other ...
"tee" might be a candidate, though it doesn't follow the `ing
convention. "teeing" sounds dumb.
On 6/15/2018 7:36 PM, Paul Sandoz wrote:
Hi Tagir,
This is looking good.
My current favorite name
On Mon, Jun 18, 2018 at 12:53 PM, Martin Buchholz wrote:
> On Mon, Jun 18, 2018 at 10:21 AM, Tony Printezis
> wrote:
>
>> Martin,
>>
>> You are forgiven. :-)
>>
>> So, the (valid, I think) issue with getIfPresent(), as originally proposed
>> by Peter, was that if get() was overridden in the subcl
On 06/18/2018 11:22 AM, Martin Buchholz wrote:
> Or better, lockField.set in resetLock could instead be setRelease.
> Except it is using reflection, not VarHandles. So it could be preceded
> with VarHandle.releaseFence(), although it is hard to think of a
> scenario in which it cou
A gentle ping :)
Do you think it's good to go now?
With kind regards,
Ivan
On 6/10/18 11:15 PM, Ivan Gerasimov wrote:
Hi Alan!
On 6/6/18 6:57 AM, Alan Bateman wrote:
I think this should be okay but the Windows implementation has a long
history of biting the fingers of anyone that dares to
On Mon, Jun 18, 2018 at 10:21 AM, Tony Printezis
wrote:
> Martin,
>
> You are forgiven. :-)
>
> So, the (valid, I think) issue with getIfPresent(), as originally proposed
> by Peter, was that if get() was overridden in the subclass to somehow
> transform the returned value, getIfPresent() wouldn’
Martin,
You are forgiven. :-)
So, the (valid, I think) issue with getIfPresent(), as originally proposed
by Peter, was that if get() was overridden in the subclass to somehow
transform the returned value, getIfPresent() wouldn’t apply the same
transformation.
Doesn’t your compute() method have e
Hi Everybody,
In the process of solving the issue [1] a part of the proper solution
should be a partially change of the Reader.nullReader() specification. I
opened a new CSR to address this. The main change would be to change to
following lines:
|* The {@code markSupported()} method returns {@co
On 2018-06-18 18:09, Peter Levart wrote:
On 06/18/2018 04:47 PM, Claes Redestad wrote:
On 2018-06-18 16:23, Peter Levart wrote:
Hi Claes,
On 06/18/2018 03:54 PM, Claes Redestad wrote:
I'd suggest something simple like this to ensure correctness, while
keeping the number of volatile rea
On 06/18/2018 04:47 PM, Claes Redestad wrote:
On 2018-06-18 16:23, Peter Levart wrote:
Hi Claes,
On 06/18/2018 03:54 PM, Claes Redestad wrote:
I'd suggest something simple like this to ensure correctness, while
keeping the number of volatile reads to a minimum:
http://cr.openjdk.java.ne
On 17/06/2018 22:20, Peter Levart wrote:
Update: the discussion on concurrent-interest about possible future
addition of public ThreadLocal.getIfPresent() or
ThreadLocal.isPresent() has died out, but it nevertheless reached a
point where ThreadLocal.isPresent() was found the least problemati
On Mon, Jun 18, 2018 at 7:21 AM, Doug Lea wrote:
> On 06/18/2018 10:05 AM, Martin Buchholz wrote:
> > There's a long history of cheating and setting final fields in
> > pseudo-constructors readObject and clone, which is well motivated since
> > Java should really support pseudo-constructors in a
+1
Stephen
On 18 June 2018 at 15:55, Roger Riggs wrote:
> Hi Naoto,
>
> Looks fine
>
> Regards, Roger
>
>
>
> On 6/15/2018 6:14 PM, Naoto Sato wrote:
>>
>> Hello,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8042131
>>
>> The proposed change
Hi Naoto,
Looks fine
Regards, Roger
On 6/15/2018 6:14 PM, Naoto Sato wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8042131
The proposed change is located at:
http://cr.openjdk.java.net/~naoto/8042131/webrev.00/
The fix is originally
On 2018-06-18 16:23, Peter Levart wrote:
Hi Claes,
On 06/18/2018 03:54 PM, Claes Redestad wrote:
I'd suggest something simple like this to ensure correctness, while
keeping the number of volatile reads to a minimum:
http://cr.openjdk.java.net/~redestad/8199435.00/
Then file a follow-up RF
Hi Alan,
Thanks for the review and suggestion.
The CSR and Webrev are updated.
webrev:
http://cr.openjdk.java.net/~rriggs/webrev-static-property-8066709/
csr:
https://bugs.openjdk.java.net/browse/JDK-8204235
On 6/16/2018 8:42 AM, Alan Bateman wrote:
On 13/06/2018 15:10, Roger Riggs wrote
Hi Stuart,
In regard to new SharedSecret interfaces, one option is move shared (but
private) implementation classes
to a jdk.internal.xx package (not exported). This only works well if
they are not tightly coupled to other
package private classes.
SpinedBuffer might be a good candidate, I ha
Hi Claes,
On 06/18/2018 03:54 PM, Claes Redestad wrote:
I'd suggest something simple like this to ensure correctness, while
keeping the number of volatile reads to a minimum:
http://cr.openjdk.java.net/~redestad/8199435.00/
Then file a follow-up RFE to investigate if we can make these fields
On 06/18/2018 10:05 AM, Martin Buchholz wrote:
> There's a long history of cheating and setting final fields in
> pseudo-constructors readObject and clone, which is well motivated since
> Java should really support pseudo-constructors in a better way..
> Cheating has used Unsafe or reflection with
I'm ignoring the direct buffers problem (sorry Tony) and wearing my
ReentrantReadWriteLock hat. I still like the idea of adding
ThreadLocal.compute(Function remappingFunction) and perhaps other such
map-inspired methods. RRWL wouldn't benefit much, since it already tries to
minimize use of ThreadL
There's a long history of cheating and setting final fields in
pseudo-constructors readObject and clone, which is well motivated since
Java should really support pseudo-constructors in a better way..
Cheating has used Unsafe or reflection with setAccessible
(CopyOnWriteArrayList.resetLock()).
I ha
I'd suggest something simple like this to ensure correctness, while
keeping the number of volatile reads to a minimum:
http://cr.openjdk.java.net/~redestad/8199435.00/
Then file a follow-up RFE to investigate if we can make these fields
non-volatile, e.g. using careful fencing as suggested
by
On 2018-06-18 13:06, Peter Levart wrote:
Adding a volatile read on every read through Properties is likely to
have some performance impact,
On non-Intel architectures in particular. On intel it would just
inhibit some JIT optimizations like hoisting the read of field out of
loop...
Righ
Hi Claes,
On 06/18/2018 12:02 PM, Claes Redestad wrote:
On 2018-06-18 05:45, David Holmes wrote:
Making it "final" to fix unsafe publication only works with actual
publication after construction. You're making it "final" but then not
setting it at construction time and instead using UNSAFE.p
On 2018-06-18 05:45, David Holmes wrote:
Making it "final" to fix unsafe publication only works with actual
publication after construction. You're making it "final" but then not
setting it at construction time and instead using UNSAFE.putVolatile
to get around the fact that it is final! The
49 matches
Mail list logo
