Hi Mandy, I won't comment on the approach, though [1] looks more cryptic to me as it includes suspicious native code changes.
I skimmed through the patch file at http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8211122/webrev.02/open.patch and haven't noticed anything wrong at first sight. The changes to java.util.logging & associated tests look fine. best regards, -- daniel 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. Webrev: http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8211122/webrev.02 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 ([1] is the prototype). Only a limited number of files are touched but I think the proposed approach is cleaner. Thanks Mandy [1] http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8211122/webrev.01/
