• Java Bindings for OpenGL – The Java Community Specification Request which JOGL provides an implementation for.
• LWJGL : An alternative open-source OpenGL wrapper library.

• Ardor3D : a high performance, professionally oriented scene graph that uses LWJGL and JOGL
• Xith3D : a scene graph based graphics API that uses JOGL and LWJGL
• Elflight Engine : a high performance 3D game engine optimised for the web
• JMonkey Engine : a high performance scene graph based graphics API that uses LWJGL and JOGL

• Poxnora, an online multiplayer game that uses JOGL
• Wurm Online, a fantasy MMORPG that uses JOGL
• RuneScape, another MMORPG using JOGL

• Jake2, a Java port of Quake II using JOGL or LWJGL for its low-level graphic API
• Scilab, a numerical computing software using JOGL for 2D & 3D rendering

 http://en.wikipedia.org/wiki/JOGL

Since the Java SE 6 version of the Java programming language, Java2D (the API for drawing two dimensional graphics in Java) and JOGL have become interoperable, allowing it to :

• Overlay Swing components (lightweight menus, tooltips, and other widgets) on top of OpenGL rendering.
• Draw 3D OpenGL graphics on top of Java2D rendering (see here for a button with an OpenGL icon).
• Use 3D graphics anywhere where ordinarily a Swing widget would be used. (Inside a JTable, JTree, …)
• Draw Java2D graphics on top of 3D OpenGL rendering.

 http://en.wikipedia.org/wiki/JOGL

As of 2007, JOGL provides full access to the OpenGL 2.0 specification.

The last 1.1.0 version is the reference implementation for JSR-231 (Java Bindings for OpenGL).

The 1.1.1 release gives limited access to GLU NURBS, providing rendering of curved lines and surfaces via the traditional GLU APIs.

The 1.1.1a release fixes a critical buffer overrun issue, and is otherwise completely compatible with 1.1.1.

A 1.1.2 pre-release was temporarily available but appears to have been abandoned.

Version 2.0 is currently in beta 10, which includes a minor API re-factoring and support for OpenGL profiles GL 1.3 – 3.0, GL ≥ 3.1, ES 1.x and ES 2.x.

 http://en.wikipedia.org/wiki/JOGL

The base OpenGL C API is accessed in JOGL via Java Native Interface (JNI) calls. As such, the underlying system must support OpenGL for JOGL to work.

JOGL differs from some other Java OpenGL wrapper libraries in that it merely exposes the procedural OpenGL API via methods on a few classes, rather than attempting to map OpenGL functionality onto the object-oriented programming paradigm. Indeed, the majority of the JOGL code is autogenerated from the OpenGL C header files via a conversion tool named Gluegen, which was programmed specifically to facilitate the creation of JOGL.

This design decision has both its advantages and disadvantages. The procedural and state machine nature of OpenGL is inconsistent with the typical method of programming under Java, which is bothersome to many programmers. However, the straightforward mapping of the OpenGL C API to Java methods makes conversion of existing C applications and example code much simpler. The thin layer of abstraction provided by JOGL makes runtime execution quite efficient, but accordingly is more difficult to code compared to higher-level abstraction libraries like Java3D. Because most of the code is autogenerated, changes to OpenGL can be rapidly added to JOGL.

 http://en.wikipedia.org/wiki/JOGL

 http://en.wikipedia.org/wiki/JOGL

JOGL allows access to most features available to C programming language programmers, with the notable exception of window-system related calls in GLUT (as Java contains its own windowing systems, AWT and Swing), and some extensions.

• CrossFTP – a user friendly FTP client and server
• Genie Workbench – a set of film production automation tools.
• PowerFolder – a popular network sync and sharing freeware.
• PowerTeacher – a gradebook program for student scores: part of the PowerSchool student information system used by schools
• PoxNora – a 3/4 perspective, turn-based strategy, collectible card game
• Wurm Online – a 3D Massively Multiplayer Online Fantasy Simulator.

 from http://en.wikipedia.org/wiki/Java_Web_Start

Some of problems with JNLP are:

• Developer has to write server URI in JNLP file, so it is not possible to use same JNLP descriptor file in production and testing environment. Developer cannot just drop .jnlp file into server shared directory, he or she has to edit it. This problem could be solved if .jnlp file opened directly by web browser plugin (which is done when using the Java Deployment Toolkit, deployJava.js)[1] (as for applets), or by introducing jnlp: URI scheme, so .jnlp file descriptor opened by URL like jnlp:http://my-site/app.jnlp. jnlp: URI scheme may be handled by JNLP handler.[citation needed]
• Developer has to sign with certificate all jar files used by JNLP. Although it is not a problem for serious production applications, it complicates learning and small applications development. Certificate may be self-signed, so this does not really solve security issues.[citation needed]
• Bad user experience: user downloads .jnlp file into temp directory or Downloads folder. Browser may ask user, if he really wants to save that .jnlp file, and then has have to open downloaded manually. This again could be solved by browser plugin (which is done as of Java 6 Update 10 and using the Sun Java Deployment Toolkit, deployJava.js), or by introducing jnlp: URL scheme.[citation needed]
• Permission checking is too simple. Developer hardcodes required permissions into .jnlp descriptor (for example, developer may request “all permissions”), and user has to confirm permissions once at application start, or perhaps during runtime.
• 64-bit Windows support added only in Java 6^[3].

 from http://en.wikipedia.org/wiki/Java_Web_Start

By default, Java Web Start applications run “restricted”, which means that they do not have access to some system resources such as local files. But publishers can remove these restrictions by signing their Web Start applications with the jarsigner tool that comes with the JDK.

 from http://en.wikipedia.org/wiki/Java_Web_Start

To reduce the size of a Java Web Start application Sun Microsystems introduced a compression system called Pack200 in Java 1.5.0. It reduces byte counts so efficiently that it can compress a large jar file to one-ninth of its original size if it contains only Java classes.^[2]

Java Web Start has supported Pack200 since it first appeared, but initially this feature required server-side cooperation and a certain amount of expertise to set up. When SUN introduced Java SE 6u10, Pack200 support became available without the need for special server support. Application designers can enable or disable this feature within JNLP files.

On slow connections Pack200 gives a performance boost in application startup time and download time.

 from http://en.wikipedia.org/wiki/Java_Web_Start

Any computer user can use JNLP by simply installing a JNLP client (most commonly Java Web Start). The installation can occur automatically such that the end user sees the client launcher downloading and installing the Java application when first executed.

JNLP works in a similar fashion to how HTTP/HTML works for the web. For rendering a HTML webpage, after the user clicks on a weblink, the browser submits a URL to a webserver, which replies with an HTML file. The browser then requests the resources referred to by this file (images, css), and finally renders the page once it has received enough information. Page rendering usually starts before all resources have downloaded; some resources not critical to the layout of the page (such as images), can follow on afterwards — or on request if the “Load Images Automatically” browser-setting remains unset.

JNLP mirrors this process; in the same way that a Web browser renders a webpage, a JNLP client “renders” a Java app. After the user clicks on a weblink the browser submits a URL to a webserver, which replies with a JNLP file (instead of a HTML file) for the application. The JNLP client parses this file, requests the resources specified (jar files), waits for the retrieval of all required resources, and then launches the application. The JNLP file can list resources as “lazy”, which informs the JNLP client that the application does not need those resources to start, but can retrieve them later on when/if the application requests them.

 from http://en.wikipedia.org/wiki/Java_Web_Start