Hi, 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. Uwe Am 7. August 2016 10:10:25 MESZ, schrieb Peter Levart <[email protected]>: >Hi, I've been planing to give a suggestion regarding internal Cleaner >implementing Runnable interface. If this internal Cleaner in DBB ever >gets >replaced with public API in the form of java.lang.reflect.Cleanable >implementation, then at that time, such workarrounds will break again >and >would have to be revised once more. So why wouldn't internal Cleaner >rather >implement java.lang.reflect.Cleanable instead of Runnable from day one >of >JDK 9 release? > >What do you think? > >Regards, Peter > >On Aug 7, 2016 9:50 AM, "Alan Bateman" <[email protected]> wrote: > >> On 06/08/2016 16:15, Julien Gouesse wrote: >> >> It doesn't work: >>> [gouessej@localhost test-classes]$ ~/Téléchargements/jdk-9/bin/java >-cp >>> ../classes:../test-classes --add-exports >java.base/jdk.internal.ref=ALL-UNNAMED >>> engine/misc/TestDeallocationHelper >>> 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 >currently in >> transition. The Jigsaw builds handle both and the plan is to drop >> -XaddExports after the new options are bedded down in the regular JDK >9 >> builds (transition period TBD, hopefully only a few weeks). So retry >with >> -XaddExports if you are using the regular JDK 9 builds. >> >> -Alan >>
