How to include JOGL in a released product?

OpenGL Development JOGL Development
#1

I’ve just finished a project using JOGL. For development I set it up as the readme says and it works fine. But now I’m at the point where I want to package it all up and release it to users. I don’t really want users to have to go around editing classpaths, etc. so I was wondering what 's the best way to include JOGL in my release? Should I install JOGL into it’s own directory somewhere and set the classpath globally? Or would it be better to put the JOGL binaries in a sub folder of my application and set the classpath at runtime?

I’m thinking the latter, but I’m not sure if there’s a standard way of doing this.

#2

I would strongly recommend you use Java Web Start to deploy your product. One click on a web page and your program runs. No installation by the end user at all. It’s a very different way of thinking about application releases. See the JOGL demos for small, concrete examples of how to do this and how to reference JOGL as an extension in your JNLP file.

#3

provided, that the end user has java installed. and i noticed that, a majority of the games target audience, especially for casual games (which a lot of java games are) has not installed it.

the team i work with uses install4j to deploy games, which might be no option since it’s rather pricey.

#4

Not to mention the numerous bugs JWS currently has. Quite often it fails the first download, and succeeds the second attempt. The “download stalled” introduced in Java 6 is also annoying, because often the download is still processing, and eventually succeeds, but by then the user already has clicked [cancel] because of the ‘stalled’ indication and frozen progressbar.

I would advice against JWS, for anything targetted at an audience that doesn’t (want to) know about these problems. And indeed, getting the user to install (a recent version of) Java in the first place is only adding to the problem.

#5

I haven’t seen the behavior of Java Web Start failing the first download and succeeding the second time. The only times I’ve seen “download stalled” have been when there were issues with the server hosting the app. If you host on a provider with good reliability I don’t think you’ll see any issues. The JOGL demos in particular should launch quickly and reliably – the folks at O’Reilly who host the content have been very responsive in fixing latency problems we have had in the past.

#6

If you’re after ease-of-installation, and don’t want to use JWS, you could always make a downloadable installer. For WIndows, create a Windows Installer for it (there are a few scripting programs out there to help you build one) and maybe even look into using one of those EXE-for-Java programs so that everything is just a simple double-click. You can embed classpaths, library paths, and other complicated command-line parameters in those EXEs.

To keep away from the whole ‘WIndows-only’ approach above, you can just use one of your original options and put JOGL in a sub-dir of your app, and within a shell script or batch program, include JOGL and the DLLs in the classpath / library path respectively.

#7

We’re using JWS to deploy software to emergency call center operators (112, the european 911) in the south of Spain. Currently this is for a couple of dozen systems but this will finally run in most hospitals, police stations and fire brigades. So far we haven’t had any problems in production. We did have problems during development but like Ken said they were always related to wrong information in the JNLP or badly configured/functioning servers. (I’m not syaing there are no bugs in JWS, I’m sure there are, just that in our controlled environment we haven’t run into any problems)

For another application for the same client we tried the All-on-one-EXE solution but this gave us so many headaches we gave up after trying several products that are supposed to be able to do this. It seems to work okay for simple cases but for products with many dependent JARs and native libraries it was just classpath-hell (we were even unpacking all the JARs and putting them into one directory, this worked but we still had problems with the native libs).

In the end we’re just using a Windows installer which works in this case because all target systems will run Windows. Never figured out why they didn’t decide to use JWS for that application too.

NB: I talked about the classpath-hell for the All-in-one-EXE solution but I must admit that getting JWS to work for non-simple applications can cause headaches too. We never spent as much time on the All-in-one case as on JWS because there wasn’t a fixed requirement for that particular application, so we went with what was easiest to get working. But once you get JWS working it really easy for the user and you don’t have to worry about updates to the software because they’ll get installed automatically (well, in our case at least because the software does not run off-line).