I can reproduce this issue and briefly tried a hack which seemed to work but I have a feeling that the non-Pack200-compressed version of this jar will be served up, if at all. I’ve contacted the site administrators asking about this issue. Hopefully it will be cleared up soon. Please post if you don’t see something in the next week or two. You can use jsr-231-webstart-current as a workaround in the interim.
JSR-231 1.1.1 release candidate 1 has been released on May 7, 2007. This is a bug fix release; the JSR-231 specification has not changed. This release contains fixes which make it possible to use the GLCanvas in the NetBeans GUI builder (“Matisse”), as well as fixes to the TextureIO classes which allow them to work on an OpenGL 1.1 implementation.
The Java Web Start binaries at jsr-231-webstart-current have been updated.
Please try the new build and post if you see any problems.
I’m guessing that the main web page needs to be updated to say Current Release build 1.1.0 instead of Current Release build 1.0.0. Good job on getting that release out.
Hey Ken,
I have a scientific application that uses JOGL that people all over the world are using (via Java Web Start). Just yesterday I began receiving complaints from my Linux users that it stopped working. There seems to be a problem with the jogl.jnlp maybe? Doesn’t seem to affect windows and macs yet.
For reference the application is available at:
Error stack:
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.sun.javaws.Launcher.executeApplication(Launcher.java:1161)
at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1108)
at com.sun.javaws.Launcher.continueLaunch(Launcher.java:951)
at com.sun.javaws.Launcher.handleApplicationDesc(Launcher.java:515)
at com.sun.javaws.Launcher.handleLaunchFile(Launcher.java:218)
at com.sun.javaws.Launcher.run(Launcher.java:165)
at java.lang.Thread.run(Thread.java:595)
Caused by:
java.lang.UnsatisfiedLinkError: /home/k/katsonis/.java/deployment/cache/javaws/http/Ddownload.java.net/P80/DMmedia/DMjogl/DMbuilds/DMarchive/DMjsr-231-webstart-current/RNjogl-natives-linux-i586.jar/libjogl_awt.so:
Can’t load IA 32-bit .so on a IA 32-bit platform
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1660)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:993)
at
com.sun.opengl.impl.NativeLibLoader$DefaultAction.loadLibrary(NativeLibLoader.java:78)
at com.sun.opengl.impl.NativeLibLoader.loadLibrary(NativeLibLoader.java:101)
at com.sun.opengl.impl.NativeLibLoader.access$100(NativeLibLoader.java:47)
at com.sun.opengl.impl.NativeLibLoader$2.run(NativeLibLoader.java:130)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.opengl.impl.NativeLibLoader.loadAWTImpl(NativeLibLoader.java:116)
at com.sun.opengl.impl.JAWT.getJAWT(JAWT.java:91)
at
com.sun.opengl.impl.x11.X11GLDrawableFactory.lockToolkit(X11GLDrawableFactory.java:551)
at
com.sun.opengl.impl.x11.X11GLDrawableFactory.isXineramaEnabled(X11GLDrawableFactory.java:676)
at
com.sun.opengl.impl.x11.X11GLDrawableFactory.chooseGraphicsConfiguration(X11GLDrawableFactory.java:134)
at javax.media.opengl.GLCanvas.chooseGraphicsConfiguration(GLCanvas.java:409)
at javax.media.opengl.GLCanvas.(GLCanvas.java:117)
at javax.media.opengl.GLCanvas.(GLCanvas.java:86)
at etviewer_2.ETViewer2.(ETViewer2.java:162)
at etviewer_2.ETViewerFrame.jbInit(ETViewerFrame.java:147)
at etviewer_2.ETViewerFrame.(ETViewerFrame.java:102)
at etviewer_2.ETViewerFrame.main(ETViewerFrame.java:737)
… 11 more
I am using this in my jnlp file:
Any way to fix this elegantly?
UPDATE:
Java Web Start demo JOGL applications are also crashing on Linux all of our Linux platforms…
thanks Ken!
i’ve been running 1.1.1RC1 now for a couple of hours and everything seems to work fine.
say, what are the long-term future plans for jogl?
what features are planned for the next major releases?
Thanks for pointing this out; I’ve updated the page.
Sorry about this. We upgraded the machine used for our Java 3D and JOGL Linux nightly builds (to a recent version of Ubuntu, I think) and it looks like it has a more recent version of libc than many of the Linux distributions out there. This was reported recently in another thread. You should be able to work around this problem for the moment by changing your JNLP file to point to one of the earlier JOGL release JNLPs:
http://download.java.net/media/jogl/builds/archive/jsr-231-1.1.0/webstart/jogl.jnlp
http://download.java.net/media/jogl/builds/archive/jsr-231-1.0.0/jogl.jnlp
(note the slight difference in naming convention – we’re going to go with the 1.1.0 convention from now on)
A couple of people have also reported problems with the 1.1.0 extension JNLP above due to an issue with Pack200 compression support on the server. If you run into the same problem then please post.
Good to hear.
I anticipate more work in the area of mixing between JOGL and Swing / Java 2D. We are also doing some work on higher-level libraries and applications. Keep an eye on these forums in the next couple of days for some exciting information from JavaOne.
Thanks Ken. I tried:
http://download.java.net/media/jogl/builds/archive/jsr-231-1.1.0/webstart/jogl.jnlp
And had immediate errors on my windows machine so I rolled back further to:
http://download.java.net/media/jogl/builds/archive/jsr-231-1.0.0/jogl.jnlp
Which seems to work for Windows. I will update this post when I find out about my Linux users.
UPDATE:
This fix appears to resolve the issue for the Linux users. Hopefully they can take advantage of the jsr-231 updates in the future.
http://download.java.net/media/jogl/builds/archive/jsr-231-1.1.0/webstart/jogl.jnlp
Should be working now. This was a misconfiguration on my part. Please try it and let me know if there are issues.
JSR-231 1.1.1 release candidate 2 has been released on May 24, 2007. This release is aimed specifically at addressing the problems Linux users have encountered with 1.1.1-rc1 requiring glibc 2.4. Our Linux nightly build machine has been downgraded to a glibc 2.3 distribution thanks to Chien Yang of the Java 3D team, so this problem should now be solved.
The Java Web Start binaries at jsr-231-webstart-current have been updated.
Please try the new build and post if you see any problems.
JSR-231 1.1.1 release candidate 3 has been released on July 4, 2007. This release adds support for the new JNLPAppletLauncher, which is a significant improvement and generalization over the previous JOGLAppletLauncher and which enables arbitrary extensions like Java 3D, JOGL, JOAL and JMF to be used with applets. See the JNLPAppletLauncher home page for more information on how to use it.
The JOGL applet examples on the jogl-demos page have been updated to use the JNLPAppletLauncher.
Please post here with any questions or comments about the new build.
A couple Mac OS X problems with the applets:
On Firefox, the applet is always displayed on top, even if the tab containing the applet is hidden.
On Safari, switching to a different tab permanently hides the applet - I have to reload the page to see it again.
Also, I think you should encourage others to use the object tag instead of the applet tag, since it allows the masses (Windows+IE users) who don’t have Java to easily install Java 6 without restarting the browser or leaving the page. Here’s a good example: http://ww2.cs.fsu.edu/~steele/XHTML/appletObject.html
I’ve heard there are lots of problems with applets in Firefox on the Mac in general due to how the plugin for it is written. The second issue sounds like a bug in Safari and its Java Plug-In. I think you should report it to Apple. I haven’t personally tried tabbed browsing in Safari with JOGL applets.
Sun is in the process of developing some JavaScript to assist with this (the Deployment Toolkit) which will be released soon. In the meantime since the applet tag is well supported and very portable I think it’s a good option. Also I think the percentage of Windows machines out there with at least JDK 1.4.2 is pretty high.
[quote]I’ve heard there are lots of problems with applets in Firefox on the Mac in general
[/quote]
Yeah, LWJGL applets have the same problem. Regular Java2D applets don’t have that problem, but they do have other problems.
[quote]The second issue sounds like a bug in Safari and its Java Plug-In.
[/quote]
Hmm not convinced its a plug-in bug… getting “GLException: already started” when switching back to the tab. Safari calls stop() when you switch away and start() when you switch back to the tab (which is a different behavior from the other browsers), so that may be the issue.
[quote]Sun is in the process of developing some JavaScript to assist with this (the Deployment Toolkit) which will be released soon.
[/quote]
Looking forward to it!
We just switched to the 1.1.1 RC3 version and so far it’s running fine.
Three issues to note:
1st: If I decide to host all files on my webserver, I have to grab the JNLP files from the Sun server. They aren’t included in the distro packages.
2nd: The webserver is queried for a file /java/jar/META-INF/services/javax.xml.parsers.SAXParserFactory. (/java/jar being my classpath). Is this intended? The requests ends up 404 (I don’t have that file), but everything works fine.
3rd: The new Launcher is way cool! But: It doesn’t solve my Problem (https://jogl.dev.java.net/issues/show_bug.cgi?id=306) with initial download size. All the OGL stuff still get’s loaded long before I need/want it. It would be nice to have some way to use lazy download for the extensions. AFAICS this is possible with vanilla JNLP, but not through the JNLPAppletLauncher.
True. If you feel strongly about this then file a bug. This isn’t the primary intended use case.
This was probably caused by some legacy behavior of the Java Plug-In. I’ve added documentation and usage of the “codebase_lookup” applet parameter to the JNLPAppletLauncher and the examples. If this doesn’t solve this issue let me know.
With the JNLPAppletLauncher we’re still working within the constraints of the current Java Plug-In. It’s only an interim solution. I believe it should be theoretically possible for you to order the resources in your archive tag to achieve lazy loading of the later ones and to use the earlier ones (like the applet launcher and a very slim applet) to do an animation while touching the classes for the full applet, pulling down the rest of the resources. However I don’t have any experience with this. Try it and see if it works.
A new Java Plug-In implementation is in development which is going to solve this problem completely. Stay tuned.
Under JOGL 1.1.0, if you load a texture from a file and if you write it into a file, you obtain a different image! It is vertically inverted!!! The consequence is that when you display texture, you don’t see what you expect… Has this bug been corrected on JOGL 1.1.1 ?
Before JOGL 1.1.0 we would automatically flip the contents of BufferedImages loaded as OpenGL textures into TextureIO. In JOGL 1.1.0 we stopped doing this for performance reasons and in order to enable some of the sub-image updating routines which are key to the new Java 2D interoperability classes (TextureRenderer, Overlay and TextRenderer). We will not be reverting back to the old behavior.
Okay, I will change my code when I use JOGL 1.1.0. Does JOGL really take into account glPrioritizeTexture ?