On 05/30/13 14:18, Mike Duigou wrote:
- I don't see the advantage to exposing the ConcurrentHashMap.KeySetView type
particularly for newKeySet(). Why not return Set? The additional methods
don't seem to offer much that's desirable for the newKeySet() case.
Since we don't have a ConcurrentSet in
On May 29 2013, at 06:11 , Doug Lea wrote:
> On 05/28/13 15:07, Mike Duigou wrote:
>> Hi Chris & Doug;
>
>> - I don't see the advantage to exposing the ConcurrentHashMap.KeySetView type
>> particularly for newKeySet(). Why not return Set? The additional methods
>> don't seem to offer much that's
On Wed, May 29, 2013 at 7:45 AM, Chris Hegarty wrote:
> decouple it from the other changes going on here. (Says me who wanted to
> resync, in one pass, the complete j.u.c last week!)
>
However it gets done, Chris, thanks very much for taking on the big task of
syncing jsr166.
On 29/05/2013 15:28, Peter Levart wrote:
.
I don't feel strongly about this either, but I think it deserves
possibly its own bug number and consideration. I have removed it from
this review request, and will a file a new bug to track it.
Hi,
Why not using Unsafe (which is already used in
On 05/29/2013 04:07 PM, Chris Hegarty wrote:
... and the links to the updated spedcdiff / webrev
http://cr.openjdk.java.net/~chegar/8005704/ver.01/specdiff/java/util/concurrent/package-summary.html
http://cr.openjdk.java.net/~chegar/8005704/ver.01/webrev/
-Chris.
On 29/05/2013 15:06, Ch
Mike, Doug,
On 28/05/2013 20:07, Mike Duigou wrote:
Hi Chris& Doug;
- I don't feel strongly about the removal of AbstractMap. I don't see this as
very likely to cause problems in real world code though there is probably some
test code somewhere that assigns CHM to an AbstractMap.
I don't f
... and the links to the updated spedcdiff / webrev
http://cr.openjdk.java.net/~chegar/8005704/ver.01/specdiff/java/util/concurrent/package-summary.html
http://cr.openjdk.java.net/~chegar/8005704/ver.01/webrev/
-Chris.
On 29/05/2013 15:06, Chris Hegarty wrote:
Mike, Doug,
On 28/05/2013 20
On 05/28/13 16:03, Martin Buchholz wrote:
A long-returning size method seems like a framework-level decision. We could
add a default method to Collection.java and Map.java
default long mappingCount() { return size(); }
The lambda EG discussed this, and decided not to do it now,
and to put off
On 05/28/13 15:07, Mike Duigou wrote:
Hi Chris & Doug;
- I don't see the advantage to exposing the ConcurrentHashMap.KeySetView type
particularly for newKeySet(). Why not return Set? The additional methods
don't seem to offer much that's desirable for the newKeySet() case.
Since we don't hav
On 29/05/2013 2:29 PM, Martin Buchholz wrote:
On Tue, May 28, 2013 at 9:00 PM, David Holmes mailto:david.hol...@oracle.com>> wrote:
On 29/05/2013 5:53 AM, Martin Buchholz wrote:
Is atomicity part of the contract of ConcurrentMap.getOrDefault?
Currently, it doesn't say.
On Tue, May 28, 2013 at 9:00 PM, David Holmes wrote:
> Martin,
>
>
> On 29/05/2013 5:53 AM, Martin Buchholz wrote:
>
>> Is atomicity part of the contract of ConcurrentMap.getOrDefault?
>> Currently, it doesn't say.
>> Actually, there are two possible guarantees it could make - whether the
>> def
Martin,
On 29/05/2013 5:53 AM, Martin Buchholz wrote:
Is atomicity part of the contract of ConcurrentMap.getOrDefault?
Currently, it doesn't say.
Actually, there are two possible guarantees it could make - whether the
default implementation ConcurrentMap.getOrDefault is atomic (when the map
do
A long-returning size method seems like a framework-level decision. We
could add a default method to Collection.java and Map.java
default long mappingCount() { return size(); }
I'm not sure mappingCount is the best name, but all names will be
confusing. Using the name "length()" at least has an
Vaguely related, looking at Map.getOrDefault:
---
Whitspace is wonky - we want more whitespace before the '*', less after.
/**
* Returns the value to which the specified key is mapped,
* or {@code defaultValue} if this map contains no mapping
* for the key.
---
The @param fo
Hi Chris & Doug;
- I don't feel strongly about the removal of AbstractMap. I don't see this as
very likely to cause problems in real world code though there is probably some
test code somewhere that assigns CHM to an AbstractMap.
- I don't see the advantage to exposing the ConcurrentHashMap.Ke
Thank you Doug, this addresses my concerns.
On 05/28/2013 11:29 AM, Doug Lea wrote:
On 05/27/13 10:30, Chris Hegarty wrote:
1) CHM no longer extends AbstractMap. I guess this should not be a
problem in the real world, and I guess users would not be too
surprised by instanceof checks.
On 05/27/13 10:30, Chris Hegarty wrote:
1) CHM no longer extends AbstractMap. I guess this should not be a
problem in the real world, and I guess users would not be too
surprised by instanceof checks. Just worth highlighting the change
for compatibility.
Yes, thanks. It was a bad
Thank you Paul, got it.
-Chris.
On 05/28/2013 10:00 AM, Paul Sandoz wrote:
Hi Chris,
On May 27, 2013, at 4:30 PM, Chris Hegarty wrote:
2) KeySetView.spliterator()
I guess the API should also report CONCURRENT, NONNULL & SUBSIZED?
And the implementation should return SIZED too?
3) Va
Hi Chris,
On May 27, 2013, at 4:30 PM, Chris Hegarty wrote:
> 2) KeySetView.spliterator()
>
> I guess the API should also report CONCURRENT, NONNULL & SUBSIZED?
> And the implementation should return SIZED too?
>
> 3) Value/EntrySpliterator.spliterator() should return SIZED?
>
The CHM sp
Since my previous failed attempt to update the j.u.c. world, this review
is for the update to j.u.c.ConcurrentHashMap v8 from Doug's CVS.
http://cr.openjdk.java.net/~chegar/8005704/ver.00/specdiff/java/util/concurrent/package-summary.html
http://cr.openjdk.java.net/~chegar/8005704/ver.00/webrev/
20 matches
Mail list logo
