JOGL OpenGL ES error in NetBeans

What is the right way to dispose them then?

((DirectBuffer) buffer).cleaner().clean(); ?

I get a warning on NB, "DirectBuffer is internal proprietary API and may be removed in a future release"

DirectBuffer has been driven inaccessible in Java 1.9 like many sun.misc interfaces and classes except a few ones including sun.misc.Cleaner. You have to use the Java reflection API if you want to get rid of this warning but anyway, DirectBuffer won't be found at runtime with Java 1.9. It's very tedious, I did it in my deallocation helper (I gave you the link on IRC but you probably didn't look at it), you have to call isDirect() to be sure that you're treating a direct NIO buffer and you have to look for a byte buffer within the passed buffer (and its children) until you find a direct byte buffer with a non null cleaner. It's a bit different with Apache Harmony, Android DVM and GNU Classpath but the search is still necessary.

gouessej wrote

DirectBuffer has been driven inaccessible in Java 1.9 like many sun.misc interfaces and classes except a few ones including sun.misc.Cleaner. You have to use the Java reflection API if you want to get rid of this warning but anyway, DirectBuffer won't be found at runtime with Java 1.9. It's very tedious, I did it in my deallocation helper (I gave you the link on IRC but you probably didn't look at it), you have to call isDirect() to be sure that you're treating a direct NIO buffer and you have to look for a byte buffer within the passed buffer (and its children) until you find a direct byte buffer with a non null cleaner. It's a bit different with Apache Harmony, Android DVM and GNU Classpath but the search is still necessary.

Actually I opened both the links, but I didn't spend so much time trying to understand them completely.

https://sourceforge.net/p/tuer/code/HEAD/tree/pre_beta/src/main/java/engine/misc/DeallocationHelper.java#l100

Now I just did, but why are they going to be driven inaccessible?

You used reflection only to get rid of that or also because of another reason?

You should have read them carefully like the posts on SO and the JEP 260 explains why they are going to be driven inaccessible, mainly for security reasons.

I use the reflection in case ignoreClassesAndFieldsHints is set to true. It's useful because "viewedBuffer" was renamed "att" and such renaming operations might occur later. Moreover, using the reflection is mandatory without DirectBuffer :s