Review request: JDK-8211122: Reduce the number of internal classes made accessible to jdk.unsupported
daniel.fuchs at oracle.com
Fri Nov 2 10:18:18 UTC 2018
I won't comment on the approach, though  looks more
cryptic to me as it includes suspicious native code
I skimmed through the patch file at
and haven't noticed anything wrong at first sight.
The changes to java.util.logging & associated tests look fine.
On 02/11/2018 04:16, Mandy Chung wrote:
> This patch includes the following changes that will reduce the
> number of internal classes made accessible to jdk.unsupported
> module via qualified exports.
> 1. move shared secrets to a new jdk.internal.access package.
> jdk.internal.misc package has been a dumping ground for various
> kinds of internal APIs and many of which were moved to an appropriate
> package. This is a follow-up clean up that moves the shared secrets
> and JavaXXXAccess interfaces to jdk.internal.access package.
> 2. add a wrapper class jdk.internal.misc.FileSystemOption to expose
> sun.nio.fs.ExtendedOptions for com.sun.nio.file to access
> This eliminates the qualified exports of sun.nio.fs to jdk.unsupported.
> 3. Refactor the implementation of sun.misc.Unsafe::invokeCleaner
> to jdk.internal.misc.Unsafe.
> This eliminates the qualified exports of jdk.internal.ref and
> sun.nio.ch to jdk.unsupported.
> The change is straight forward although quite many files are modified.
> Majority of the changes is import statement change or test @modules
> change due to the rename.
> I ran hs-tier1-3 and jdk-tier1-3 tests.
> We considered the alternative to define a wrapper class for everything
> that jdk.unsupported module depends on in a dedicated package
> e.g. jdk.internal.unsupported. It would need a wrapper for Unsafe,
> Signal, SignalHandler and ExtendedOptions. It means that it would
> have 3 classes of each - two similar/duplicated implementations
> (one in sun.misc and one in jdk.internal.unsupported) and one
> in jdk.internal.misc ( is the prototype). Only a limited number
> of files are touched but I think the proposed approach is cleaner.
>  http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8211122/webrev.01/
More information about the core-libs-dev