Hi Stuart et al,
I've gone through the feedback (thanks, everyone!) and made the
following adjustments which I
hope covers most, if not all, concerns:
- Per John's suggestion I've moved most of the methods in List12/ListN
to AbstractImmutableList,
using for-loops rather than iterators etc. I'
Hi Claes,
> http://cr.openjdk.java.net/~redestad/8193128/open.05/
src/java.base/share/classes/java/util/ImmutableCollections.java
599 public boolean contains(Object o) {
600 Objects.requireNonNull(o);
601 return size > 0 && probe(o) >= 0; // implicit nullcheck
Hi Andrej, thanks for catching this. Webrev updated in-place.
Regards
/Claes
On 2018-01-08 14:25, Andrej Golovnin wrote:
Hi Claes,
http://cr.openjdk.java.net/~redestad/8193128/open.05/
src/java.base/share/classes/java/util/ImmutableCollections.java
599 public boolean contains(Obj
Hi Claes,
Are you sure that AbstractImmutableSet.equals(Object) is correct?
@Override
public boolean equals(Object o) {
if (o == this)
return true;
if (!(o instanceof Set))
return false;
Collection c = (Collecti
Also, I don't think that ClassCastException should be caught here. It
should never be thrown by containsAll(c) anyway.
On 01/08/18 20:09, Peter Levart wrote:
Hi Claes,
Are you sure that AbstractImmutableSet.equals(Object) is correct?
@Override
public boolean equals(Object o) {
On 01/08/18 20:09, Peter Levart wrote:
Should the method also check that the size(s) of both sets are the same?
Or better yet, compute the size of the other set as you iterate the
elements. Like this:
public boolean equals(Object o) {
if (o == this)
ret
On 01/08/18 20:46, Peter Levart wrote:
Or better yet, compute the size of the other set as you iterate the
elements. Like this:
public boolean equals(Object o) {
if (o == this)
return true;
if (!(o instanceof Set))
return fals
Gosh! My intent was to carry over AbstractSet::equals verbatim, so I
have no idea how the size
check got lost in translation and passed through testing! Appears to be
another hole in the test
coverage, or I didn't run the right ones.
As to calculating o.size() as we go then I'm not sure: most S
Hi Claes,
On 01/08/18 21:57, Claes Redestad wrote:
Gosh! My intent was to carry over AbstractSet::equals verbatim, so I
have no idea how the size
check got lost in translation and passed through testing! Appears to
be another hole in the test
coverage, or I didn't run the right ones.
As to ca
Hi Claes,
On 01/08/18 23:41, Peter Levart wrote:
Hi Claes,
On 01/08/18 21:57, Claes Redestad wrote:
Gosh! My intent was to carry over AbstractSet::equals verbatim, so I
have no idea how the size
check got lost in translation and passed through testing! Appears to
be another hole in the test
http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html
8191483: AbstractQueuedSynchronizer cancel/cancel race
http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/AQS-cancel-cancel-race/index.html
https://bugs.openjdk.java.net/browse/JDK-8191483
Lots of minor
Hi,
On 2018-01-09 00:04, Peter Levart wrote:
Hi Claes,
On 01/08/18 23:41, Peter Levart wrote:
Hi Claes,
On 01/08/18 21:57, Claes Redestad wrote:
CCE is specified to be thrown by Set::contains/containsAll, so I
think we should play it safe and
leave it unchanged.
It's probably specified s
No takers? ... let's try again. Despite uniform failure to reproduce this
except under a debugger, let's apply the simple obviously correct fix,
namely:
/** Craft a LambdaForm customized for this particular MethodHandle */
/*non-public*/
void customize() {
+final LambdaForm
That looks good to me. Vladimir Ivanov should take a look.
Christmas vacation is just ending in Russia, so he should be around soon.
On Jan 8, 2018, at 6:41 PM, Martin Buchholz wrote:
>
> No takers? ... let's try again. Despite uniform failure to reproduce this
> except under a debugger, let'
Hi Martin
[Back from holiday]
Can you reproduce using the debugger? If so do you have a more up to date stack
trace?
That change looks ok. The form field is final, and in the j.l.invoke package
such fields are also stable so once C2 gets at it it will likely treat it as a
constant. In general
In the hotspot sources I find
// An instance field can be constant if it's a final static field or
if
// it's a final non-static field of a trusted class (classes in
// java.lang.invoke and sun.invoke packages and subpackages).
BUT
you can't trust MethodHandle.form!
Yes, it's
16 matches
Mail list logo
