Update to JogAmp JOGL 2.3.2 released on 2015 10 10

[wcmatthysen]

Description of the Change

The long-outstanding JOGL upgrade that @xranby has made back in 2016 (see: NASAWorldWind#1)

Why Should This Be In Core?

We need to eventually upgrade to the latest JOGL so that WorldWind still works in Java 9+. Seeing as Java 8 has already reached end-of-life this upgrade should happen sooner than later.

Benefits

Using the latest version of JOGL will bring in any bug-fixes that was made to JOGL itself. The upgrade will also allow WorldWind to still function in a Java 9+ environment. This will also open the door for us to upgrade to a newer version of JOGL more easily seeing as the package names have now been switched in this update.

Potential Drawbacks

There might still be users that are on the older version of JOGL that cannot upgrade just yet. They won't be able to use the latest version of WorldWind until they have switched over all of their code to also use the latest version of JOGL.

Applicable Issues

The package-names in the latest version of JOGL have been modified. Mixing code that relies on the latest version of JOGL and and older version won't work. Clients will need to update to the latest version of JOGL in order to continue using WorldWind.

[wcmatthysen]

I see the original code has been based off a very old master branch. There are a couple of conflicts that I can resolve before we merge this in.

[emxsys]

@wcmatthysen This PR should be a great addition to WWJ, as well as an example of handling PRs in the community edition. Thanks for addressing the conflicts. Meanwhile, this week I'll setup TravisCI for integration testing. And finally, we'll need to perform the WWJ functional tests for such a significant change as this.

[wcmatthysen]

I managed to fix the conflicts and I merged the changes into the development branch. The TravisCI would be great for running the tests.

[robmilton]

@wcmatthysen Thanks for contributing this change! I just cloned WWJ-CE yesterday and have built the worldwind jar which we use as a library for a large project we've worked on for years.

After updating our project to reference the new JOGL libraries and addressing a few other issues I'm able to build and run our (non-module) project in Apache NetBeans 10 with Java 12. However, as has been mentioned by others, I still receive numerous "illegal reflective access" warnings thrown by calls to gluegen-rt and jogl-all.

We're trying to put a plan together to address Java 9+ issues for our WWJ-based application (which includes replacement of WebStart which we've addressed with a combination of NSIS and GetDown)... I suppose it may now be a WWJ-CE-based application! :)

I'm wondering about a couple of things:

1. Non-WWJ question: Does anyone know if the time will come when we "MUST" develop module-based Java applications? Or can we reasonably and safely continue to develop non-module based applications into the foreseeable future?

2. Do you (or anyone) have a solid grasp of what will be required to address the "illegal reflective access" warnings in WWJ? I read some comments about this issue being related to native library loading. Just wondering if anyone is working on a game plan to address this issue?

I have zero experience with contributing to open source, but I made my first baby step yesterday by installing git and cloning the WWJ-CE project. I'd love to contribute any way I can, so I'll be looking for opportunities.

Thanks again for doing this JOGL upgrade! It seems like a very good step in the right direction!

[wcmatthysen]

@robmilton, any help would be appreciated. This community-fork is run by the community and we need all the help we can get to make it a success. So, to answer your questions:

1. I do not think we will ever be forced to develop module-based applications. You can look at this link for an explanation. As @nicolai puts it:

You are by no means forced to create modules, though. You can completely ignore module-info.java and continue to place all your JARs onto the class path. The module system will silently bundle them all into the unnamed module, which was created for maximum compatibility. You won't even notice the module system is there (assuming you've overcome the challenges I described earlier).

It might be attractive to switch over to modules in the future to ensure that when a WorldWind application gets packaged, it doesn't ship with everything in the JDK. Thus, by making use of modules we would allow for a more lean application to be shipped.

2. Yes, it looks as though the "illegal reflective access" has to do with the native library loading. You can look at the original issue logged against the upstream library at: Running with Java 9 Causes Warning NASAWorldWind/WorldWindJava#147. In particular the java.lang.ClassLoader.findLibrary() method that is invoked in the gluegen-rt jar seems to be causing issues if you look at the stack-trace listed there.

I do not know if we'll be able to get around this issue in the short term. We'll have to see what the JOGL guys can pull off. In the mean time, we can probably get away with ignoring modules until we need to address it in the future. There is probably already some users of WorldWind that must build a Java application making use of modules that will run into problems though. I've already seen this issue pop up in the original upstream pull-request: NASAWorldWind#1 where @sbwong is using Java 10 with modules and is encountering problems.

Thanks, the JOGL upgrade has been overdue for a very long time. We are not even on the latest version yet. I think the upgrade switched it to a version that was released in 2015. We still need to upgrade to a much more recent version in the near future and see if we run into any new issues that we haven't seen yet.

[robmilton]

@wcmatthysen Thanks for the quick and helpful response! I can definitely see how going to modules in the future could be a benefit. But wanted to confirm that I wouldn't cause problems sticking with the current approach in the meantime.

I wanted to ask about the statement "we are not even on the latest version yet"... When I visit the JogAmp site it seems that JOGL 2.3.2 is the latest stable release. Just wondering if I'm missing something?

[wcmatthysen]

@robmilton, yes, you are correct. We are on the latest stable release of JOGL. For some reason I thought there was a newer version already available considering 2.3.2 was last released in 2015. I see that there are stubs for 2.4.0 and 2.5.0 with issues listed under them. It looks like a 2.4.0 release is close if you consider the number of closed issues. But, yeah, I don't know how far away from a new release they are though.

[robmilton]

I see the call to the java.lang.ClassLoader.findLibrary() method on the gluegen-rt jar. But if I run with VM Option: --illegal-access=warn then I also get warnings related to access of 'fields' and 'methods' in the jogl-all jar as well. It's interesting to me that I don't see a warning that appears to be related to loading the jogl-all jar.

Just for reference below is the list of warnings I receive. Each of the warnings below were prefaced with 'WARNING: Illegal reflective access by ' which I removed to save space:

com.jogamp.common.os.NativeLibrary$3 (file:<path-to>/gluegen-rt.jar) to method java.lang.ClassLoader.findLibrary(java.lang.String)
jogamp.opengl.awt.Java2D$2 (file: <path-to>/jogl-all.jar) to field sun.java2d.opengl.OGLUtilities.UNDEFINED
jogamp.opengl.awt.Java2D$2 (file: <path-to>/jogl-all.jar) to field sun.java2d.opengl.OGLUtilities.WINDOW
jogamp.opengl.awt.Java2D$2 (file: <path-to>/jogl-all.jar) to field sun.java2d.opengl.OGLUtilities.TEXTURE
jogamp.opengl.awt.Java2D$2 (file: <path-to>/jogl-all.jar) to field sun.java2d.opengl.OGLUtilities.FLIP_BACKBUFFER
jogamp.opengl.awt.Java2D$2 (file: <path-to>/jogl-all.jar) to field sun.java2d.opengl.OGLUtilities.FBOBJECT
jogamp.nativewindow.jawt.JAWTUtil$1 (file: <path-to>/jogl-all.jar) to method sun.awt.SunToolkit.awtLock()
jogamp.nativewindow.jawt.JAWTUtil$1 (file: <path-to>/jogl-all.jar) to method sun.awt.SunToolkit.awtUnlock()
com.jogamp.opengl.awt.GLCanvas$14 (file: <path-to>/jogl-all.jar) to method sun.awt.windows.WToolkit.disableBackgroundErase(java.awt.Canvas)
jogamp.nativewindow.jawt.windows.Win32SunJDKReflection$1 (file: <path-to>/jogl-all.jar) to method sun.awt.Win32GraphicsConfig.getConfig(sun.awt.Win32GraphicsDevice,int)
jogamp.nativewindow.jawt.windows.Win32SunJDKReflection$1 (file: <path-to>/jogl-all.jar) to method sun.awt.Win32GraphicsConfig.getVisual()
com.jogamp.nativewindow.awt.AppContextInfo (file: <path-to>/jogl-all.jar) to method sun.awt.AppContext.getAppContext()

Also for reference I am developing with:
Windows 10 Pro 64-bit (version 1809)
Apache NetBeans 10
OpenJDK 12
WWJ-CE (develop branch cloned 4/24/2019)

Out of curiosity do you know if anyone has talked with the guys at JogAmp? I haven't poked around on their site much (but I probably will very soon). Do you know if they are working on addressing the Java 9+ issues?

UPDATE: After looking at the roadmaps for upcoming JOGL versions it looks like "Support for Java 11+" is slated for version 2.5.0. However, I don't see any indication of a goal/planned release date. As @wcmatthysen mentioned it seems like the 2.4.0 release might not be too far off when you look at the completed features/bugs.

[wcmatthysen]

Those warnings are related to JOGL accessing internal sun APIs which will also become a problem as far as I know. I think the JOGL guys are working on this as we speak. I haven't interacted with any of them myself. I saw there were people that used WorldWind that logged some issues on the JogAmp forum: (look near the bottom of the post to see the WorldWind reference). I also found this bugzilla bug that was logged very recently with links to some other bugs of interest.

[robmilton]

I saw that bug as well... and it notes that it is slated for the 2.5.0 version. But there's no information or discussion at all (at least that I can find) about timing.

I sent Sven Gothel an email asking him about that bug and his thoughts about when it might get addressed. Hopefully I'll hear back from him.