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