RFR: 8132984: incorrect type for Reference.discovered
Kim Barrett
kbarrett at openjdk.java.net
Sat Dec 26 03:49:02 UTC 2020
Please review this change which fixes the type of the private
Reference.discovered field. It was Reference<T>, but that's wrong because
it can be any Reference object.
I've changed it to Reference<?> and let that flow through, updating some
other variables that were previously somewhat incorrectly typed (usually
with an Object type parameter). The interesting change is to the
ReferenceQueue.enqueue parameter, which is now also Reference<?>.
This ultimately end up with a provably safe and correct, but uncheckable,
cast in ReferenceQueue.enqueue.
An alternative might be to use a raw type for the discovered field, but I
think that ends up with more @SuppressWarnings of various flavors. I think
the unbounded wildcard approach is clearer and cleaner.
Note that all of the pending list handling, including the discovered field,
could be moved into a non-public, non-generic, sealed(?) base class of
Reference<T>. The pending list handling has nothing to do with the generic
parameter T.
Testing:
mach5 tier1 and tier4 (tier4 is where vmTestbase_vm_gc_ref tests are run)
-------------
Commit messages:
- Use unbounded wildcard placeholders and final safe but unchecked cast
Changes: https://git.openjdk.java.net/jdk/pull/1897/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1897&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8132984
Stats: 16 lines in 2 files changed: 8 ins; 0 del; 8 mod
Patch: https://git.openjdk.java.net/jdk/pull/1897.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/1897/head:pull/1897
PR: https://git.openjdk.java.net/jdk/pull/1897
More information about the core-libs-dev
mailing list