Note that both OneTriangleAWT and OneTriangleSwingGLCanvas crash with the same error. OneTriangleSwingGLJPanel crashes as well, but that seems due to a JDK bug: 
  https://bugs.openjdk.java.net/browse/JDK-8160421

(In reply to Stijn Debruyckere from comment #1)
> Note that both OneTriangleAWT and OneTriangleSwingGLCanvas crash with the
> same error. OneTriangleSwingGLJPanel crashes as well, but that seems due to
> a JDK bug: 
>   https://bugs.openjdk.java.net/browse/JDK-8160421

Why do you think that it seems to be due to this bug?

For all clarity: OneTriangleAWT and OneTriangleSwingGLCanvas crashed with the ArrayIndexOutOfBoundsException mentioned in the description.

OneTriangleSwingGLJPanel crashed with a NullPointerException, the exact same one as JDK-8160421 which leads me to believe it was due to that bug ;-) The resolution is set to fixed, but the fix version still says 'team' instead of '9' so I believe it's not yet available in the EA builds.

(In reply to Stijn Debruyckere from comment #3)
> For all clarity: OneTriangleAWT and OneTriangleSwingGLCanvas crashed with
> the ArrayIndexOutOfBoundsException mentioned in the description.
> 
> OneTriangleSwingGLJPanel crashed with a NullPointerException, the exact same
> one as JDK-8160421 which leads me to believe it was due to that bug ;-) The
> resolution is set to fixed, but the fix version still says 'team' instead of
> '9' so I believe it's not yet available in the EA builds.

Ok, thanks, it's crystal clear now. Please let me know when the fix is available in a EA build.

(In reply to Stijn Debruyckere from comment #3)
> For all clarity: OneTriangleAWT and OneTriangleSwingGLCanvas crashed with
> the ArrayIndexOutOfBoundsException mentioned in the description.
> 
> OneTriangleSwingGLJPanel crashed with a NullPointerException, the exact same
> one as JDK-8160421 which leads me to believe it was due to that bug ;-) The
> resolution is set to fixed, but the fix version still says 'team' instead of
> '9' so I believe it's not yet available in the EA builds.

OneTriangleSwingGLJPanel should work now as JDK-8160421 is fixed in the latest early build. Please can you give it a try?

When I run JOGLQuad (my example from the wiki) with the build 172, I get:
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -1
        at jogamp.opengl.windows.wgl.awt.WindowsAWTWGLGraphicsConfigurationFactory.chooseGraphicsConfigurationImpl(WindowsAWTWGLGraphicsConfigurationFactory.java:171)
        at com.jogamp.nativewindow.GraphicsConfigurationFactory.chooseGraphicsConfiguration(GraphicsConfigurationFactory.java:424)
        at com.jogamp.opengl.awt.GLCanvas.chooseGraphicsConfiguration(GLCanvas.java:1560)
        at com.jogamp.opengl.awt.GLCanvas.addNotify(GLCanvas.java:611)
        at java.desktop/java.awt.Container.addNotify(Container.java:2796)
        at java.desktop/java.awt.Window.addNotify(Window.java:772)
        at java.desktop/java.awt.Frame.addNotify(Frame.java:490)
        at java.desktop/java.awt.Window.show(Window.java:1034)
        at java.desktop/java.awt.Component.show(Component.java:1669)
        at java.desktop/java.awt.Component.setVisible(Component.java:1616)
        at java.desktop/java.awt.Window.setVisible(Window.java:1017)
        at JOGLQuad.main(JOGLQuad.java:86)

I entered this:
"C:\Program Files\Java\jdk-9\bin\java.exe" --permit-illegal-access  -cp .;C:\checkout-svn\HEAD1\java\lib\jogamp-fat.jar JOGLQuad

It seems to work:
WARNING: --permit-illegal-access will be removed in the next major release
WARNING: Illegal access by com.jogamp.common.os.NativeLibrary$3 (file:/C:/checkout-svn/HEAD1/java/lib/jogamp-fat.jar) to method java.lang.ClassLoader.findLibrary(java.lang.String) (permitted by --permit-illegal-access)
WARNING: Illegal access by jogamp.opengl.awt.Java2D$2 (file:/C:/checkout-svn/HEAD1/java/lib/jogamp-fat.jar) to field sun.java2d.opengl.OGLUtilities.UNDEFINED (permitted by --permit-illegal-access)
WARNING: Illegal access by jogamp.opengl.awt.Java2D$2 (file:/C:/checkout-svn/HEAD1/java/lib/jogamp-fat.jar) to field sun.java2d.opengl.OGLUtilities.WINDOW (permitted by --permit-illegal-access)
WARNING: Illegal access by jogamp.opengl.awt.Java2D$2 (file:/C:/checkout-svn/HEAD1/java/lib/jogamp-fat.jar) to field sun.java2d.opengl.OGLUtilities.TEXTURE (permitted by --permit-illegal-access)
WARNING: Illegal access by jogamp.opengl.awt.Java2D$2 (file:/C:/checkout-svn/HEAD1/java/lib/jogamp-fat.jar) to field sun.java2d.opengl.OGLUtilities.FLIP_BACKBUFFER (permitted by --permit-illegal-access)
WARNING: Illegal access by jogamp.opengl.awt.Java2D$2 (file:/C:/checkout-svn/HEAD1/java/lib/jogamp-fat.jar) to field sun.java2d.opengl.OGLUtilities.FBOBJECT (permitted by --permit-illegal-access)
WARNING: Illegal access by jogamp.nativewindow.jawt.JAWTUtil$1 (file:/C:/checkout-svn/HEAD1/java/lib/jogamp-fat.jar) to method sun.awt.SunToolkit.awtLock() (permitted by --permit-illegal-access)
WARNING: Illegal access by jogamp.nativewindow.jawt.JAWTUtil$1 (file:/C:/checkout-svn/HEAD1/java/lib/jogamp-fat.jar) to method sun.awt.SunToolkit.awtUnlock() (permitted by --permit-illegal-access)
WARNING: Illegal access by com.jogamp.opengl.awt.GLCanvas$14 (file:/C:/checkout-svn/HEAD1/java/lib/jogamp-fat.jar) to method sun.awt.windows.WToolkit.disableBackgroundErase(java.awt.Canvas) (permitted by --permit-illegal-access)
WARNING: Illegal access by jogamp.nativewindow.jawt.windows.Win32SunJDKReflection$1 (file:/C:/checkout-svn/HEAD1/java/lib/jogamp-fat.jar) to method sun.awt.Win32GraphicsConfig.getConfig(sun.awt.Win32GraphicsDevice,int) (permitted by --permit-illegal-access)
WARNING: Illegal access by jogamp.nativewindow.jawt.windows.Win32SunJDKReflection$1 (file:/C:/checkout-svn/HEAD1/java/lib/jogamp-fat.jar) to method sun.awt.Win32GraphicsConfig.getVisual() (permitted by --permit-illegal-access)
WARNING: Illegal access by com.jogamp.nativewindow.awt.AppContextInfo (file:/C:/checkout-svn/HEAD1/java/lib/jogamp-fat.jar) to method sun.awt.AppContext.getAppContext() (permitted by --permit-illegal-access)

We have a workaround for sure.

It's no longer a blocker as we have a workaround.

It should help to break the encapsulation when --permit-illegal-access stops being supported in Java 1.10:
--add-exports=java.base/java.lang=ALL-UNNAMED
--add-exports=java.desktop/sun.awt=ALL-UNNAMED
--add-exports=java.desktop/sun.java2d=ALL-UNNAMED

The very first exports addition should work on the long term to remove the warning about java.lang.ClassLoader.findLibrary(java.lang.String). However, the packages in sun.awt and sun.java2d might be moved or substantially modified.

It works with Java Webstart too:
https://bugs.openjdk.java.net/browse/JDK-8172986

I need to test my suggestions. If they work, I'll lower the severity of this bug to "normal".

My understanding is that the reflective access will work, but that a warning will appear.  Is that correct?

Since we use JOGL in a product used by many customers, we would see that warning as a major issue.  I'm still reading up on this, but do we know what might be done about it?

thanks
andy

(In reply to Andy Skinner from comment #10)
> My understanding is that the reflective access will work, but that a warning
> will appear.  Is that correct?
> 
> Since we use JOGL in a product used by many customers, we would see that
> warning as a major issue.  I'm still reading up on this, but do we know what
> might be done about it?
> 
> thanks
> andy

The warning appears when using the dumbest workaround based on --permit-illegal-access but the second solution shouldn't print any warning.

The second solution is using the other add exports?
--add-exports=java.base/java.lang=ALL-UNNAMED
--add-exports=java.desktop/sun.awt=ALL-UNNAMED
--add-exports=java.desktop/sun.java2d=ALL-UNNAMED

That does seem to work for me, and will do for now.

thanks
andy

(In reply to Andy Skinner from comment #12)
> The second solution is using the other add exports?
> --add-exports=java.base/java.lang=ALL-UNNAMED
> --add-exports=java.desktop/sun.awt=ALL-UNNAMED
> --add-exports=java.desktop/sun.java2d=ALL-UNNAMED
> 
> That does seem to work for me, and will do for now.
> 
> thanks
> andy

Yes. Thank you for the feedback.

Oops, maybe something wrong happens under Mac OS X (in jogamp.opengl.macosx.cgl.awt.MacOSXAWTCGLGraphicsConfigurationFactory) but it has to be tested without mixing JOGL 2 with JOGL 1:
http://forum.jogamp.org/Jogl-Jogamp-on-Java-9-tp4038012p4038383.html

What is the plan for this in the longer term?

I am told that in Java 10, the suppressed warnings will become errors.

thanks
andy

(In reply to Andy Skinner from comment #15)
> What is the plan for this in the longer term?
> 
> I am told that in Java 10, the suppressed warnings will become errors.
> 
> thanks
> andy

The second solution you tested with Java 1.9 should go on working in Java 1.10 until Oracle does breaking changes under the hood but I'm almost sure that the first solution breaks in Java 1.10.

I'm told that add-exports still works right now in Java 11, but that we have no idea whether it will stay.

Is there a plan for addressing the issue?  What is involved?

thanks
andy

(In reply to Andy Skinner from comment #17)
> I'm told that add-exports still works right now in Java 11, but that we have
> no idea whether it will stay.
> 
> Is there a plan for addressing the issue?  What is involved?
> 
> thanks
> andy

Hey Andy

There is nothing to fix yet. If Oracle moves the internal classes of AWT that we use in JogAmp, we'll have to use the reflection to find them in order to make it work both with the current location and the new location.

The addition of exports can be done in module-info.java or in a JAR manifest too, it would allow us not to do it in command line. Let me know whether you find this solution smarter.

We've got a spot to do the add-exports, so we're OK with that for now.

Could you write or point me to a clear explanation of the problem?  I know it it has to do with access to things in AWT and changes in Java 9, but I'd like to put it all together.  I have looked through the forum post and this bug report, but still think it would be good to have clarity on what the problem is that we're working around with add-exports, and what the future options are.  This was prompted by me not really understanding what is meant that there is nothing to fix at this point.

thanks
andy

(In reply to Andy Skinner from comment #19)
> We've got a spot to do the add-exports, so we're OK with that for now.
> 
> Could you write or point me to a clear explanation of the problem?  I know
> it it has to do with access to things in AWT and changes in Java 9, but I'd
> like to put it all together.  I have looked through the forum post and this
> bug report, but still think it would be good to have clarity on what the
> problem is that we're working around with add-exports, and what the future
> options are.  This was prompted by me not really understanding what is meant
> that there is nothing to fix at this point.
> 
> thanks
> andy

The problem here causing incompatibility is the new encapsulation of the module system for Java > 8, which by now you surely are aware of.

Related JEP's 260 and 261

I have created Bug 1363 to address all these issues and coordinate work towards a clean Java 11 JogAmp build.

This should work in the meantime:
--add-exports java.base/java.lang=ALL-UNNAMED
--add-exports java.desktop/sun.awt=ALL-UNNAMED
--add-exports java.desktop/sun.java2d=ALL-UNNAMED

(In reply to Julien Gouesse from comment #21)
> This should work in the meantime:
> --add-exports java.base/java.lang=ALL-UNNAMED
> --add-exports java.desktop/sun.awt=ALL-UNNAMED
> --add-exports java.desktop/sun.java2d=ALL-UNNAMED

As our java11 capable release comes to a closing,
passing the unit tests will close this bug.

However, Java9 will not be officially supported.

Closed as described in comment 22 
Our Java 11 unit tests are passing.