cannot access class jdk.internal.ref.Cleaner (in module java.base) because module java.base does not export jdk.internal.ref to unnamed module
uschindler at apache.org
Sun Aug 7 09:05:44 UTC 2016
The Lucene code as linked in previous mail is prepared to work with your patch about using the public Cleanable, too. The code works with all 3 possibilities: java 8 and earlier, current Java 9, and yours. The comments in code are a bit misleading as I expected your patch to be committed long ago, because I liked your clean approach.
Unfortunately, your patch was not accepted until now.
Am 7. August 2016 10:10:25 MESZ, schrieb Peter Levart <peter.levart at gmail.com>:
>Hi, I've been planing to give a suggestion regarding internal Cleaner
>implementing Runnable interface. If this internal Cleaner in DBB ever
>replaced with public API in the form of java.lang.reflect.Cleanable
>implementation, then at that time, such workarrounds will break again
>would have to be revised once more. So why wouldn't internal Cleaner
>implement java.lang.reflect.Cleanable instead of Runnable from day one
>JDK 9 release?
>What do you think?
>On Aug 7, 2016 9:50 AM, "Alan Bateman" <Alan.Bateman at oracle.com> wrote:
>> On 06/08/2016 16:15, Julien Gouesse wrote:
>> It doesn't work:
>>> [gouessej at localhost test-classes]$ ~/Téléchargements/jdk-9/bin/java
>>> ../classes:../test-classes --add-exports
>>> Unrecognized option: --add-exports
>>> Error: Could not create the Java Virtual Machine.
>>> Error: A fatal exception has occurred. Program will exit.
>>> The existing name for --add-exports is -XaddExports, we are
>> transition. The Jigsaw builds handle both and the plan is to drop
>> -XaddExports after the new options are bedded down in the regular JDK
>> builds (transition period TBD, hopefully only a few weeks). So retry
>> -XaddExports if you are using the regular JDK 9 builds.
More information about the jigsaw-dev