cannot access class jdk.internal.ref.Cleaner (in module java.base) because module java.base does not export jdk.internal.ref to unnamed module

[Julien Gouesse]

Peter, my source code doesn't rely on the class name of the cleaner:
https://sourceforge.net/p/tuer/code/HEAD/tree/pre_beta/src/main/java/engine/misc/DeallocationHelper.java#l98
It would break only if java.nio.DirectByteBuffer was moved but it would be easy to fix by creating a direct byte buffer and getting its class.
Now, it just works :) I've tested with Java 1.9 Early Access build 129 and OpenJDK 1.8.0 update 101.
Personally, I'm happy with the current solution, the clean() method is called in the run() method which uses the security manager. I assume that the Panama project will provide better APIs to deal with communication with native APIs. There is no emergency to provide something better for direct NIO buffers as long as it remains possible to release the native memory whenever we want. The projects with no need of backward compatibility will use java.nicl.NativeScope, NativeLibrary, Pointer, Reference and MemoryRegion.
Alan, thank you for the tips, it's good to know that. I fixed JMonkeyEngine too in the meantime:Fixes the reflection allocator with Java 9, tested with Java 9 Early … · jMonkeyEngine/jmonkeyengine at f820bbfFixes a spelling mistake in the reflection allocator · jMonkeyEngine/jmonkeyengine at d0f0cfe

|   |
|   |  |   |   |   |   |   |
| Fixes a spelling mistake in the reflection allocator · j...jmonkeyengine - A complete 3D game development suite written purely in Java. |
|  |
| Afficher sur github.com | Aperçu par Yahoo |
|  |
|   |



|   |
|   |  |   |   |   |   |   |
| Fixes the reflection allocator with Java 9, tested with ...…Access build 129 and OpenJDK 1.8.0 update 101 |
|  |
| Afficher sur github.com | Aperçu par Yahoo |
|  |
|   |


Best regards.


    Le Dimanche 7 août 2016 10h10, Peter Levart <peter.levart at gmail.com> a écrit :
 

 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" <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/ja va -cp ../classes:../test-classes --add-exports java.base/jdk.internal.ref=ALL -UNNAMED engine/misc/TestDeallocationHe lper
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