GL_ARB_vertex_buffer_object not available on Mac?

Pushed more fixes to https://github.com/WadeWalker/jogl/tree/java-11-fixes. Removed references to tools.jar, since this no longer exists in Java 9+ (see https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-A78CC891-701D-4549-AA4E-B8DD90228B4B). Also removed an import of jogamp.opengl.glu.gl2.* that caused compilation of GLgl2.java and GLUgl2ProcAdressTable.java to fail in new Java compilers, removed refs to non-existent method GLCanvas.getPeer() in debug code, and annotated some deprecated methods with @Deprecated to get rid of some compiler warnings.

Next up are more javah-related failures that are exposed as the build goes further and further :)

Both gluegen and JOGL now compile successfully on Windows 10 using Java 11 :) The code is in https://github.com/WadeWalker/gluegen/tree/java-11-fixes and https://github.com/WadeWalker/jogl/tree/java-11-fixes.

The next step is to get JOCL compiling, then test gluegen/JOGL/JOCL on Windows, then test the builds on Mac OS X and Linux.

Brilliant, can't wait to get my hands on the Mac build and access to my Mac where I have the Java 11 installation.
At this pace both will happen around second week January... Happy New Year!

wbr Kusti





On 29/12/2018 16:14, "Wade Walker [via jogamp]" <[hidden email]> wrote:



Both gluegen and JOGL now compile successfully on Windows 10 using Java 11 :) The code is in

https://github.com/WadeWalker/gluegen/tree/java-11-fixes <https://github.com/WadeWalker/gluegen/tree/java-11-fixes> and
https://github.com/WadeWalker/jogl/tree/java-11-fixes <https://github.com/WadeWalker/jogl/tree/java-11-fixes>.

The next step is to get JOCL compiling, then test gluegen/JOGL/JOCL on Windows, then test the builds on Mac OS X and Linux.


________________________________________
If you reply to this email, your message will be added to the discussion below:
http://forum.jogamp.org/GL-ARB-vertex-buffer-object-not-available-on-Mac-tp4039309p4039351.html
To unsubscribe from GL_ARB_vertex_buffer_object not available on Mac?,
click here <
NAML <http://forum.jogamp.org/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>


This e-mail may contain confidential or privileged information and is intended solely for the person to whom it is addressed. If you have received this e-mail in error, please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from the alteration of this e-mail, or as a result of any virus being passed on or as of transmission of this e-mail in general.

java.awt.Component.getPeer() was removed from the API in Java 1.9.

Now gluegen, JOGL, JOCL, and JOAL all compile on Windows. Tests on glugen and JOGL seem to work for the most part; there are a few failures sprinkled around, but I don't think they reflect on the build process. Haven't tried the build on Mac or Linux yet.

I took a quick stab at the "Illegal reflective access" errors to see how deep they went. The first one is due to java.lang.ClassLoader.findLibrary(), which it seems like we may not have to call any more -- perhaps it was only useful to find libraries from inside applets, which are now deprecated? In any case, when I comment these out, the code still seems to work.

The next error is from accessing sun.java2d.opengl.OGLUtilities, which is used in GLJPanel to check the Java2D surface type. Unfortunately the entire sun.* package hierarchy seems to be inaccessible in Java 9+. I may be able to replace this with OpenGL calls like glIsFramebuffer() and glIsTexture() instead of stealing the surface type out of OGLUtilities and sun.java2d.opengl.OGLSurfaceData.

Tested gluegen and JOGL on Mac OS X 10.13 with Java 11 this morning, and they look good. I was half-afraid that Apple would have done some weirdness with clang or something that would mess up our compilation, but it worked fine with the default clang that's installed by

xcode-select --install

Tomorrow I'll work some more on the "Illegal reflective access" errors to see if I can find some legit solutions there. I still have some questions there, like does

AccessController.doPrivileged(new PrivilegedAction<Object>() {} )

 ever make sense now that we won't ever be running in an applet environment.

findLibrary is called when loading the native libraries extracted by our automatic native library loading, isn't it?

Yes, the current code does call java.lang.ClassLoader.findLibrary(), but it seems like the actual loading is done by System.load( pathname ) or System.loadLibrary( libname ), which are still freely accessible in Java 11. So I'm not sure what the point is of calling findLibrary() -- why not just load it? If we're using JOGL's automatic native extraction from JAR, then we know the pathname already (since we extracted it), so we can call System.load(); if the user has set -Djava.library.path, then System.loadLibrary() will find the libraries there by libname.

Gradually getting closer to being warning-free! I had to hard-code some constants in jogamp.opengl.awt.Java2D that used to be set by reflection from sun.java2d.opengl.OGLUtilities, and it looks like the next one is in jogamp.nativewindow.jawt.JAWTUtil where it uses reflection to access sun.awt.SunToolkit.awtLock() and sun.awt.SunToolkit.awtUnlock(). I'm not sure why it uses reflection to do this, instead of just using the lock and unlock from the Java Native AWT interface (see https://docs.oracle.com/en/java/javase/11/docs/specs/AWT_Native_Interface.html#jawt.h). I'll dig in and see if there's some trick here, but it looks solvable.

findLibrary is used to find the location of the library in a platform-dependent manner in the environment. However, I don't find the source code doing it in Java 1.11, ClassLoader.findLibrary() just returns null, I've found nothing in SecureClassLoader and URLClassLoader.

I think findLibrary returns null if there is no system-dependent lookup and will fall back to just searching java.library.path.

Harvey

I've removed findLibrary() for now and everything still seems to work, but I'll do a more comprehensive test at the end where I compare the regression results with and without my patch, just to make sure nothing hidden has broken.

ClassLoader.findLibrary was only overridden in sun.misc.Launcher.ExtClassLoader, which was the class loader used by the extension mechanism. As this mechanism has been removed and was error prone, I have advised people not to use it for years. When ClassLoader.findLibrary returns null, maybe some callers do some platform-dependent lookup but ClassLoader.findLibrary itself has become completely useless and has been totally useless for those who have followed my advise. In other words, I think that this call can be safely removed. I'd like to know Sven's opinion about that, maybe I'm missing something.

Edit.: Wade, actually, it's an excellent idea, it will help us to get rid of native libraries coming from obsolete JOGL versions installed as extensions especially under OS X :)

After removing the illegal reflective accesses to sun.awt.SunToolkit.awtLock/Unlock in JAWTUtil, my SWT Eclipse RCP apps finally run without any warnings on Windows 10/Java 11/Eclipse 2018 :)

Next, there are a couple of illegal accesses that occur only on Mac in JAWTUtil, to sun.awt.CGraphicsDevice.getScaleFactor() and sun.awt.CGraphicsDevice.getCGDisplayID(). There seems to be a legitimate solution to obtaining scale factor on Mac now (see https://bugs.openjdk.java.net/browse/JDK-8172962), so I'll put this in and see what happens. Hopefully this will complete my goal of:

- Getting glugen/jogl/jocl/joal to compile and run under Java 11
- Getting rid of all runtime warnings, at least for my particular use-cases

Please can you elaborate? I don't see correctly the quoted bug report, I can't scroll :s, what is the legitimate solution?

The solution is, instead of doing this in JAWTUtil.java:

final PrivilegedDataBlob1 pdb1 = (PrivilegedDataBlob1) AccessController.doPrivileged(new PrivilegedAction<Object>() {
    @Override
    public Object run() {
        final PrivilegedDataBlob1 d = new PrivilegedDataBlob1();
        try {
            final GraphicsDevice gd = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice();
            final Class<?> gdClass = gd.getClass();
            d.getScaleFactorMethod = gdClass.getDeclaredMethod("getScaleFactor");
            d.getScaleFactorMethod.setAccessible(true);
        } catch (final Throwable t) {}
        return d;
    }
});
...
final Object res = getScaleFactorMethod.invoke(device);
if (res instanceof Integer) {
    sx = ((Integer)res).floatValue();
} else if ( res instanceof Double) {
    sx = ((Double)res).floatValue();
}
sy = sx;

to now do this (since GraphicsConfiguration.getDefaultTransform() has been added):

GraphicsDevice gd = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice();
GraphicsConfiguration gc = gd.getDefaultConfiguration(); 
AffineTransform tx = gc.getDefaultTransform();
sx = (float)tx.getScaleX(); 
sy = (float)tx.getScaleY(); 

On a Windows PC with a 4K monitor, this returns 2.25 as the scale factor in both directions, which seems like the right answer. I'm trying on Mac next.

OK, I'm finished with my holiday goal of getting JOGL to run without illegal reflective access errors, at least for my use-cases :) The changes I've made are in:

https://github.com/WadeWalker/gluegen/tree/java-11-fixes
https://github.com/WadeWalker/jogl/tree/java-11-fixes
https://github.com/WadeWalker/joal/tree/java-11-fixes

I also fixed the build process to work with Java 11 and the latest versions of MinGW64 and Clang. I've confirmed that gluegen/joal/jogl/jocl all compile on both Windows 10 and MacOS High Sierra.

I'm sure there are many more potential illegal reflective access errors lurking in the code, depending on what windowing toolkit you use. I didn't try to eliminate the ones that I wasn't encountering in my daily use, but I can help advise if someone else wants to take a crack at them.

These fixes also incorporate a fix for determining the AWT display scale factor, which is now handled the same way across all platforms.

Yes, you're right, I saw a similar fix in Java3D 1.7.

Brilliant!

Many, many thanks!

Compiles and runs (with my software) without warnings on MacOs 10.13.6 (High Sierra) and openjdk 11.0.1 2018-10-16.

Now, how about jocl?

And when could we realistically expect precompiled jars with all the native bits for all the platforms?

wbr Kusti

PS Not related but anyone know a replacement for Apple FullScreenUtilities which gives:

WARNING: Illegal reflective access /  com.apple.eawt.FullScreenUtilities.setWindowCanFullScreen(java.awt.Window,boolean)


On 06/01/2019, 21.17, "Wade Walker [via jogamp]" <[hidden email]> wrote:



OK, I'm finished with my holiday goal of getting JOGL to run without illegal reflective access errors, at least for my use-cases :) The changes I've made are in:


https://github.com/WadeWalker/gluegen/tree/java-11-fixes
https://github.com/WadeWalker/jogl/tree/java-11-fixes
https://github.com/WadeWalker/joal/tree/java-11-fixes

I also fixed the build process to work with Java 11 and the latest versions of MinGW64 and Clang. I've confirmed that gluegen/joal/jogl/jocl all compile on both Windows 10 and MacOS High Sierra.


I'm sure there are many more potential illegal reflective access errors lurking in the code, depending on what windowing toolkit you use. I didn't try to eliminate the ones that I wasn't encountering in my daily use, but I can help advise if someone else wants
 to take a crack at them.

These fixes also incorporate a fix for determining the AWT display scale factor, which is now handled the same way across all platforms.


________________________________________
If you reply to this email, your message will be added to the discussion below:
http://forum.jogamp.org/GL-ARB-vertex-buffer-object-not-available-on-Mac-tp4039309p4039372.html
To unsubscribe from GL_ARB_vertex_buffer_object not available on Mac?,
click here <
NAML <http://forum.jogamp.org/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>


This e-mail may contain confidential or privileged information and is intended solely for the person to whom it is addressed. If you have received this e-mail in error, please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from the alteration of this e-mail, or as a result of any virus being passed on or as of transmission of this e-mail in general.

JOCL compiles now, without any changes besides the ones I posted, but I didn't try running it yet, since I'm not using it myself at the moment. Have you tried duplicating your initial tests with a newly-built JOCL to see if it still fails? I'm hoping that the Mac natives just got out of date due to some library/compiler change in the OS.

You can find precompiled JARs in my repo at https://github.com/WadeWalker/com.jogamp.jogl. It's an Eclipse project, but the JARs in it are just the ones I built over the last few days. Currently it has 64-bit Windows, Mac, and Linux (just built with Ubuntu 18.04 yesterday).