RFR: jsr166 jdk9 integration wave 2

Paul Sandoz paul.sandoz at oracle.com
Tue Nov 17 10:16:05 UTC 2015


> On 16 Nov 2015, at 22:39, Martin Buchholz <martinrb at google.com> wrote:
> 
> Smaller than wave 1, but still large.  Nothing like a looming deadline to spur work ...
> 
> Oracle folks will need to help with API review.
> 
> https://bugs.openjdk.java.net/issues/?jql=(subcomponent%20%3D%20java.util.concurrent)%20AND%20status%20%3D%20%22In%20Progress%22%20ORDER%20BY%20updatedDate%20DESC
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
> 
> The primary focus is making jtreg tests more robust and faster.
> It also contains the changes to j.u.c.atomic that Aleksey is waiting for.


src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java
—

CCC created.


src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java
—

 398         private final void valueCheck(V v) {
 399             if (v != null && !(vclass.isInstance(v)))
 400                 throwCCE();
 401         }

Why not directly use vclass.cast ?

I think there may be a subtle change in behaviour with the updates to A*FU, where previously a CCE would be thrown and now a IAE is thrown e.g. consider an erased A*FU to a public field of some class and and a receiver of the incorrect type is passed to an access method. Does not really matter in practice, although the error message will be confusing.

Paul.






More information about the core-libs-dev mailing list