Update to JogAmp JOGL 2.3.2 released on 2015 10 10

[xranby]

This pull request enable users to distribute and bundle WorldWind in combination with Oracle's Java SE builds by complying with the Java SE binary license section F.
"F. JAVA TECHNOLOGY RESTRICTIONS. You may not create, modify, or change the behavior of, or authorize your licensees to create, modify, or change the behavior of, classes, interfaces, or subpackages that are in any way identified as "java", "javax", "sun", “oracle” or similar convention as specified by Oracle in any naming convention designation."
http://www.oracle.com/technetwork/java/javase/terms/license/index.html

JogAmp JOGL have relocated javax.media.opengl.* -> com.jogamp.opengl.* to relax probable license issue while bundling JOGL.
For details see: https://jogamp.org/bugzilla/show_bug.cgi?id=682

This update was mostly done using find and replace across the source tree like this:
git grep -lz 'javax.media.opengl' | xargs -0 perl -i'' -pE "s/javax.media.opengl/com.jogamp.opengl/g"
git grep -lz 'javax.media.nativewindow' | xargs -0 perl -i'' -pE "s/javax.media.nativewindow/com.jogamp.nativewindow/g"

I had to manually fix some minimal JogAmp JOGL 2.x.x -> 2.3.2 API changes

I imported the JogAmp JOGL 2.3.2 jars using:
wget http://jogamp.org/deployment/v2.3.2/archive/jogamp-all-platforms.7z
7z x jogamp-all-platforms.7z
cp jogamp-all-platforms/jar/gluegen-rt.jar .
cp jogamp-all-platforms/jar/gluegen-rt-natives-.jar .
cp jogamp-all-platforms/jar/jogl-all.jar .
cp jogamp-all-platforms/jar/jogl-all-natives-.jar .

[pdavidc]

Xerces, Thanks for providing the motivation for this pull request, along with the comprehensive changes necessary to update the JOGL libraries. Though the update is predominantly package name changes, the World Wind team must perform comprehensive tests any time the JOGL libraries change. We'll need to perform tests on your changes prior to incorporation into the public repository.

Additionally, it would be helpful if you would provide the following:

• What were the JOGL API changes that affected World Wind?
• What platforms have you tested these changes on?

[sbwong]

What is the status of this pull request? Is anyone working on it? It was submitted almost 3 years ago and seems to have stalled. Getting updated to the latest JOGL is critical in terms of becoming more compatible with Java 9+.

[gbburkhardt]

What is the status of this pull request? Is anyone working on it? It was submitted almost 3 years ago and seems to have stalled. Getting updated to the latest JOGL is critical in terms of becoming more compatible with Java 9+.

For what it's worth, we've updated our working code base to use JOGL 2.3.2, and it's working fine for us. In addition to installing the libraries in the class path, some changes to the source are needed. But those can be done with these commands:

grep -rl 'javax.media.nativewindow' src/com src/gov/nasa | xargs sed --in-place "s/javax.media.nativewindow/com.jogamp.n
ativewindow/g"
grep -rl 'javax.media.opengl' src/com src/gov/nasa | xargs sed --in-place "s/javax.media.opengl/com.jogamp.opengl/g"

[sbwong]

Is there a branch that I can clone to get the updated code? I'd rather be connected into an "official" codebase rather than rely on my own implemented customizations. That also enables me to stay current with the WWJ codebase.

Does your working code operate successfully with a Java 9+ (10.0.2 for us) project that uses modules? If so, what are the modulepath, classpath, module-info.java, command line parameters and other magical settings needed to get it to work? In case it matters, we're running Eclipse Photon.

I've been tearing my hair out for over a week to get WWJ to work with a project with modules and it's got to work in the next couple of days.

Thank you!

[gbburkhardt]

Is there a branch that I can clone to get the updated code? I'd rather be connected into an "official" codebase rather than rely on my own implemented customizations. That also enables me to stay current with the WWJ codebase.

Does your working code operate successfully with a Java 9+ (10.0.2 for us) project that uses modules? If so, what are the modulepath, classpath, module-info.java, command line parameters and other magical settings needed to get it to work? In case it matters, we're running Eclipse Photon.

I've been tearing my hair out for over a week to get WWJ to work with a project with modules and it's got to work in the next couple of days.

Thank you!

I'm not aware of any branch other than this one that you could clone to JOGL 2.3.2. We are running with Java 8. But it was reasonably straight forward for us. We pulled the JOGL release from 'jogamp.org', and put the two commands in my earlier post in a script to use on the Worldwind source when we unzipped the Worldwind 2.1.0 release. You need "jogl-all.jar" and "gluegen-rt.jar" in your class path, and either "gluegen-rt-natives-linux-amd64.jar" or "gluegen-rt-natives-windows-amd64.jar" unzipped into your application's execution path.

[sbwong]

My problem is that we've switched to Java 10 using projects with modules and WWJ throws exceptions even when we try to run the ApplicationTemplate demo (Index out of bounds exception). WWJ works fine if the Java 10 project has no modules though. I suspect that the problem lies in JOGL but I can't track anyone down who has gotten either JOGL or WWJ to work with Java 9+ in a project with modules.

[gbburkhardt]

My problem is that we've switched to Java 10 using projects with modules and WWJ throws exceptions even when we try to run the ApplicationTemplate demo (Index out of bounds exception). WWJ works fine if the Java 10 project has no modules though. I suspect that the problem lies in JOGL but I can't track anyone down who has gotten either JOGL or WWJ to work with Java 9+ in a project with modules.

You should try the development forum, if you haven't already. Good luck!

[sbwong]

Thank you for your help! It's reassuring to know that the simple text replacement is all that it takes to upgrade to JOGL 2.3.2. It does seem to me that any Java 9+ implementation of WWJ is going to have to use that newer JOGL version.

Sanity check: By "unzipped into your application's execution path", I assume that you mean that the JARs are on the classpath, which is the normal setup for WWJ?

I have been looking through the development forum but haven't found any leads yet. This pull request was the closest thing I've found so far.

If you hear of anyone that has played around with either JOGL or WWJ using Java 9+ in a project with modules, please let me know right away as I am in desperate need to talk with anyone about this issue.

Thank you again!

[gbburkhardt]

Thank you for your help! It's reassuring to know that the simple text replacement is all that it takes to upgrade to JOGL 2.3.2. It does seem to me that any Java 9+ implementation of WWJ is going to have to use that newer JOGL version.

Sanity check: By "unzipped into your application's execution path", I assume that you mean that the JARs are on the classpath, which is the normal setup for WWJ?

I have been looking through the development forum but haven't found any leads yet. This pull request was the closest thing I've found so far.

If you hear of anyone that has played around with either JOGL or WWJ using Java 9+ in a project with modules, please let me know right away as I am in desperate need to talk with anyone about this issue.

Thank you again!

The native libraries are released as jar files. The shared libraries they contain need to be loaded by your application somehow. Usually putting them in the application's execution search path is enough.

I think you want "jogamp-all-platforms.7z" at http://jogamp.org/deployment/v2.3.2/archive/. You won't need all of it - only "jogl-all.jar", "gluegen-rt.jar", and a set of native libraries for "gluegen" (I think! - No guarantees... ;-) ).

[sbwong]

When I make the package name changes detailed above, I get compiler errors saying that the follow methods do not exist:

1. GLU.destroy() (in DebugListener.dispose() ) -- There doesn't seem to be any comparable method in JOGL 2.3.2.

2. GLDrawable.getWidth/Height() ( in DrawContextImpl.getDrawableWidth/Height() ) -- These methods appear to have been renamed "getSurfaceWidth/Height()".

How did you get around these issues, particularly the GLU.destroy()?
Thanks!

Note: I believe that WWJ has problems in modular environments not just because of JOGL but also because the worldwindx JAR code tries to load resources, e.g. image files, from the worldwind JAR file, which Java 9+ doesn't allow. See the discussing in the forum: https://forum.worldwindcentral.com/forum/world-wind-java-forums/development-help/158565-java-11-and-worldwind

[gbburkhardt]

When I make the package name changes detailed above, I get compiler errors saying that the follow methods do not exist:

1. GLU.destroy()   (in DebugListener.dispose() ) -- There doesn't seem to be any comparable method in JOGL 2.3.2.

2. GLDrawable.getWidth/Height()   ( in DrawContextImpl.getDrawableWidth/Height() ) -- These methods appear to have been renamed "getSurfaceWidth/Height()".

How did you get around these issues, particularly the GLU.destroy()?
Thanks!

Note: I believe that WWJ has problems in modular environments not just because of JOGL but also because the worldwindx JAR code tries to load resources, e.g. image files, from the worldwind JAR file, which Java 9+ doesn't allow. See the discussing in the forum: https://forum.worldwindcentral.com/forum/world-wind-java-forums/development-help/158565-java-11-and-worldwind

1. I believe that the call to GLU.destroy() can simply be omitted. The JOGL release included in WorldWind 2.1.0 is JOGL 2.1.5. The source archive on jogamp.org omits GLU.java, but it can be found in one of the automated builds (http://jogamp.org/deployment/autobuilds/master/jogl-b1240-2014-03-11_04-15-42/jogl-2.1-b1240-20140311-windows-amd64.7z). The call to GLU.destroy() simply results in a de-referencing of ProjectFloat.matrixBuf, and of GLU.project. But this is only relevant when the DebugListener is created, which is only during debug, so if there's a memory leak any release application wouldn't see it.

2. Yes, change the calls to "getSurfaceWidth/Height()"
   public final int getDrawableHeight()
   {

•    return this.getGLDrawable().getHeight();
  

•    return this.getGLDrawable().getSurfaceHeight();
  

  }

  public final int getDrawableWidth()
  {

•    return this.getGLDrawable().getWidth();
  

•    return this.getGLDrawable().getSurfaceWidth();
  

  }

[wcmatthysen]

@xranby, @gbburkhardt, @sbwong. Hi guys. We want to get these changes into the community fork of WorldWind as soon as possible. As far as I understand from the discussion here, would it only be a package-name changes:

git grep -lz 'javax.media.opengl' | xargs -0 perl -i'' -pE "s/javax.media.opengl/com.jogamp.opengl/g"
git grep -lz 'javax.media.nativewindow' | xargs -0 perl -i'' -pE "s/javax.media.nativewindow/com.jogamp.nativewindow/g"

The minimal API changes (such as getHeight() to getSurfaceHeight()).

As well as the GLU.destroy() omissions?

Have you managed to get it working in Java 10 with modules?

The community fork is located at: https://github.com/WorldWindEarth/WorldWindJava

[gbburkhardt]

It's been working for us with the changes described since Nov 2018. Also, we are in the middle of migration to Java 11 for our WorldWind based project.  One of our other team members is working on that, and I don't know all that's been required for changes. But I do know that we aren't using the module feature, just Java 11.

…

On 4/7/2019 1:32 PM, Wiehann Matthysen wrote: @xranby <https://github.com/xranby>, @gbburkhardt <https://github.com/gbburkhardt>, @sbwong <https://github.com/sbwong>. Hi guys. We want to get these changes into the community fork of WorldWind as soon as possible. As far as I understand from the discussion here, would it only be a package-name changes: |git grep -lz 'javax.media.opengl' | xargs -0 perl -i'' -pE "s/javax.media.opengl/com.jogamp.opengl/g"| |git grep -lz 'javax.media.nativewindow' | xargs -0 perl -i'' -pE "s/javax.media.nativewindow/com.jogamp.nativewindow/g"| The minimal API changes (such as |getHeight()| to |getSurfaceHeight()|). As well as the |GLU.destroy()| omissions? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFHjlHb8-tihdhopOzAgo6v2Sew3BVC2ks5veiuggaJpZM4HEz1o>.

[wcmatthysen]

Ok, if we can get it working without modules for now, then it would be great. We just have to keep in mind what @sbwong mentioned with regards to the resource-loading across jars that could be an issue. This is probably something that we'll have to address in the very near future seeing as Java 8 is already on its way out and we really need to make WorldWind work on Java 9+ if we want to take this project forward.

I went through the changes and it doesn't look like there are any major issues besides the OGLUtilTest merge conflict. If we can get that sorted out we can probably go ahead and merge it into the community fork.

[wcmatthysen]

Ok, these changes were merged in the develop branch of the community edition.

See this closed pull request: WorldWindEarth#5

I had to make a change to an import here and there that were not covered in the original pull-request. Everything compiles and looks fine.

[markpet49]

Thanks for the submission. WWJ has been upgraded to JOGL 2.4, so this PR is no longer relevant.