Is there any links to a thread that has comparisons between these two api's? i wish to produce a table that shows differences, advantages, disadvantages of each language, as i am using lwjgl i am hoping that it has more advantages. oh yes and the context of this question is in relation to making games but all advantages and disadvantages are welcome, thanks guys

Take a look at http://jogl.dev.java.net/JOGLGlueGen.pdf , slide 4. It has a table which compares significant attributes of LWJGL, GL4Java, Magician, and JOGL. This was presented a while back (May 2004) to the JSR-231 and 239 expert groups.

I've been trying to get a serious, complete, lengthy, accurate comparison of the two for over a year now .

With the new JGF, I've had comments from quite a few people that suggest an automated comparison table between technologies would be useful.

What do you think about a page where you could do something like:

1. Click "add new feautre"2. Type in description + details3. Select the feature-type from a drop-down (so that it gets compared like-with-like with other techs)

?

How much detail would be needed? Any extra fields? Obviously, the more detailed the features could be, the less description, the better (lets viewers just choose the particular features they're interested in).

3. Select the feature-type from a drop-down (so that it gets compared like-with-like with other techs)

There's no way you'll be able to come up with a feature list that's detailed enough but still usuable!

I've never found two pieces of software (or hardware) that can be easily compared using bullet-point lists. One-line descriptions are rarely enough to enable people to understand the ramifications of an API difference. And trying to get rival developers to agree on common feature-types or the wording of each API's entry... *shudder*

Might be better to just have a specific area where user-described API comparisons can be posted - a couple of paragraphs from three different people should be enough for most people to understand the differences.

There's no way you'll be able to come up with a feature list that's detailed enough but still usuable!

....is my default expectation too. But, since the other thing doesn't seem to work (c.f. below), and JGF is heavily moderated, I'm holding out hope that some compromise could be done that is useful even if it has obvious imperfections.

Perhaps...if users could propose features, and a moderator ACCEPT'd those that they thgought applied, and the JOGL, LWJGL, etc authors could fill in their own 200 words on each "feature" proposed this way?

Quote

a couple of paragraphs from three different people should be enough

So far it's proved impossible to find people of even approximately equivalent knowledge about the different API's who are also willing and also able and also *actually do it* to do this.

....is my default expectation too. But, since the other thing doesn't seem to work (c.f. below), and JGF is heavily moderated, I'm holding out hope that some compromise could be done that is useful even if it has obvious imperfections.

Well, if you think it'll work - go for it!

Perhaps I'm being a little too negative here. It's not necessary to get everything absolutely 100% concise - any central source of information on relative API merits will be a good thing, even if it doesn't quite apply in some circumstances.

Actually the only feature you'll find in JOGL which is not present in LWJGL is the embedding with AWT. If you don't need that feature, I suppose you won't find the killer feature in one or the other library that you search for.

All other things are more or less a matter of opinion. JOGL is more modular. You need to download more libraries for sound and control (e.g. joal and jinput). Also JOGL is more instance oriented. That means you get more the feeling of OO in JOGL. Even the fact that JOGL talks about games, it's also useful for other things e.g. in Swing.

LWJGL puts everything in one distribution. It seems to me more like a "best of breed" library for games (graphics, sound, control in one place). It's developed for games and nothing else in mind. You'll get everything you need from one place. LWJGL uses heavily static methods (as far as I see that). This looks more like C and that means also the layer in LWJGL is slightly thinner than in JOGL. Thats cool for all those who need that transparent approach.

Fact's are: Both libraries are well developed, both have reached mature stability and both have enthusiastic support from their developers.

I suppose you search the library for a game. ;-) Games usually don't have the requirement for a long term maintenance track.So I think you can't go wrong. Just use the library that looks useful for you and that supports your programming style.Sometimes it's better just to begin... ;-)

In functionality terms, LWJGL = Hires Timer + JOGL + JOAL + JInput - AWT; LWJGL is not directly integrated with AWT but JOGL is, which means LWJGL is less of a candidate for CAD/CAM applications right now

In API terms, LWJGL exclusively uses direct ByteBuffers to pass data to native code and we have removed methods that are just C shortcuts for efficiency; JOGL also uses heap arrays, for convenience at the expense of efficiency and high performance programming techniques.

- LWJGL is miles ahead in terms of reliability and compatibility. I couldn't seriously expect any professional game to be satisfied with the current reliability of Jogl.

- Jogl's display creation is clumsy, awkward and not nearly as flexible as LWJGL's. Also, when it goes wrong it tends to core dump instead of throwing anything you could recover from.

- Jogl has the object access to GL, LWJGL uses the static interface. In theory that means Jogl has the handy-dandy composable pipeline. In reality both end up doing error checking (LWJGL substancially more on buffer args) but Jogl makes you pass round an annoying GL object constantly.

- Jogl allows for GL contexts that can be resized.

- Jogl has a clumsy Animator interface for actually displaying anything that forces you to do things how it wants. Although I believe that there's now a proper swapBuffers interface now?

- Both are going to have heavyweight vs. lightweight issues when embedded in a Swing app. Theoretically Jogl has a lightweight display that doesn't suffer from these problems. Realistically it performs so slow its just not practical for anything useful.

- Both have almost useful documentation. But the LWJGL examples/tests do provide a working base. By contrast the Jogl demos seem to be constantly out of sync everytime I look at them (and consequently broken).

- LWJGL is miles ahead in terms of reliability and compatibility. I couldn't seriously expect any professional game to be satisfied with the current reliability of Jogl.

I don't think this is a fair assessment of the JOGL project. 1.1 b08 (and in particular the revised single-threaded workaround) has addressed basically all open stability issues, most of which were ultimately caused by OpenGL driver bugs exposed by multithreading. If you are still seeing stability issues on a given vendor's card with JOGL, I would appreciate it if you would file a bug.

Quote

- Jogl's display creation is clumsy, awkward and not nearly as flexible as LWJGL's. Also, when it goes wrong it tends to core dump instead of throwing anything you could recover from.

Could you provide an example of how LWJGL's display creation is "more flexible" than JOGL's? The current JOGL source base does enforce a factory method for the construction of OpenGL widgets, but this restriction will be removed in the forthcoming JSR-231 API implementation.

Quote

- Jogl has the object access to GL, LWJGL uses the static interface. In theory that means Jogl has the handy-dandy composable pipeline. In reality both end up doing error checking (LWJGL substancially more on buffer args) but Jogl makes you pass round an annoying GL object constantly.

JOGL supports concurrent rendering to multiple OpenGL contexts; LWJGL does not. If LWJGL used an object and per-context function table to represent OpenGL function pointers than it could more easily support multithreaded OpenGL rendering. As it stands the native code for LWJGL would have to change substantially and do a lookup in thread-local storage per OpenGL function call in order to support multiple contexts. See the GLEW library for more information on how to do this in straight C code.

Quote

- Jogl has a clumsy Animator interface for actually displaying anything that forces you to do things how it wants. Although I believe that there's now a proper swapBuffers interface now?

JOGL has exposed a swapBuffers API for nearly a year.

Quote

- Both are going to have heavyweight vs. lightweight issues when embedded in a Swing app. Theoretically Jogl has a lightweight display that doesn't suffer from these problems. Realistically it performs so slow its just not practical for anything useful.

JOGL 1.1 b08 adds hardware acceleration for its GLJPanel widget, and there are fixes in the CVS repository which will be present in 1.1 b09 which address performance issues on ATI cards. The GLJPanel is now fast enough and featureful enough for application use.

Quote

- Both have almost useful documentation. But the LWJGL examples/tests do provide a working base. By contrast the Jogl demos seem to be constantly out of sync everytime I look at them (and consequently broken).

This has not been my experience. The JOGL demos are tested on all platforms before each major release of the library and consistently show off the most advanced features of OpenGL like vertex and fragment programs.

First, I am not on one side or the other. I just use what works. I started my project with the one I saw the most demos for, JOGL, but will probably add LWJGL support later on.

Quote

Also:

- LWJGL is miles ahead in terms of reliability and compatibility. I couldn't seriously expect any professional game to be satisfied with the current reliability of Jogl.

I have found JOGL to be very stable and have had no issues in this regard. The only problems I have ever really seen in running open gl java were actually LWJGL, but probably because it is more prevelant out there (an even more likely it was due to bugs in the program using the API). From what I have seen both are stable enough for real use.

Quote

- Jogl's display creation is clumsy, awkward and not nearly as flexible as LWJGL's. Also, when it goes wrong it tends to core dump instead of throwing anything you could recover from.

I have found the API pretty easy to use. In terms of core dumps, I am doing some pretty advanced stuff with it and have not seen any core dump that wasn't my fault.... though I would like to blame the API, it hasn't been an option so far

Quote

- Jogl has the object access to GL, LWJGL uses the static interface. In theory that means Jogl has the handy-dandy composable pipeline. In reality both end up doing error checking (LWJGL substancially more on buffer args) but Jogl makes you pass round an annoying GL object constantly.

At first I didn't like this, but I found it made me do better code. My project is a multi-threaded engine and not having access to the GL reference has made me avoid temptation in the engine thread... Of course if I really did want it, I could make it available any time. However, I can see why that might be annoying to some. It's a necessary evil for multiple GL contexts. Unless you had some kind of set active context method added that had to be called before executing any GL commands...and it would make threading between contexts a bloody nightmare.

Quote

- Jogl has a clumsy Animator interface for actually displaying anything that forces you to do things how it wants. Although I believe that there's now a proper swapBuffers interface now?

What's this Animator you speak of? Kidding. It's very easy to write your own buffer swap in JOGL. There is no trick, just shut off the autoswap and then swap at the end of a render loop.

Quote

- Both are going to have heavyweight vs. lightweight issues when embedded in a Swing app. Theoretically Jogl has a lightweight display that doesn't suffer from these problems. Realistically it performs so slow its just not practical for anything useful.

Not sure, haven't used it like that yet.

Quote

- Both have almost useful documentation. But the LWJGL examples/tests do provide a working base. By contrast the Jogl demos seem to be constantly out of sync everytime I look at them (and consequently broken).

I found the Jogl demos to work perfectly, maybe it wasn't always so? Dunno. They're great now though.

It's very personal but I don't like external game libraries because IMO they make things more difficult ,except for the creators of said libraries.That's why I chose JOGL, I prefer to create my own library from scratch with a clean base that lets me access OpenGL as I need to, it actually lets me save time.With a game library or "framework" you have to spend a lot of time learning the library and how to use it.

It's very personal but I don't like external game libraries because IMO they make things more difficult ,except for the creators of said libraries.That's why I chose JOGL, I prefer to create my own library from scratch with a clean base that lets me access OpenGL as I need to, it actually lets me save time.With a game library or "framework" you have to spend a lot of time learning the library and how to use it.

Do you think LWJGL is a "external game library" in contrast to JOGL? Or are your comment just off topic?

lwjgl is a lot easier to just pick up and use, there really is no learning; if you know opengl you know lwjgl. In contrast, jogl forces you to learn a bit more api specific stuff: should you use a glcanvas or a gljpanel? whats the best way to design your system so that everything that needs to have access to ogl can use the GL object? what should I put ean each of the 5 or so methods you have to implement when using the GLEventListener interface. Of course all that stuff is trivial, I'm just trying to point out that its sort of silly to say that you have to learn more to use lwjgl than jogl.

p.s. I don't actually think your silly I'm sure it was just a misconception about what lwjgl is, which is why it would be good to have all the facts in a single location.

It's very personal but I don't like external game libraries because IMO they make things more difficult ,except for the creators of said libraries.That's why I chose JOGL, I prefer to create my own library from scratch with a clean base that lets me access OpenGL as I need to, it actually lets me save time.With a game library or "framework" you have to spend a lot of time learning the library and how to use it.

Wow, you really don't know what LWJGL is?There is no "learning" curve or framework you have to adhere to, to use LWJGL - you just plonk it in, and use OpenGL.

At most, you could argue that LWJGL forces you to use it's display system - but it's hardly difficult:

Comparison of JOGL and LWJGL seems pretty pointless to me, as their design goals are different. JOGL is supposed to be a generic and object oriented binding of opengl for java, that is, be able to handle every kind of opengl usage : games, CAD/CAO, etc. Thus, opengl context management makes sens in JOGL. On the other hand, LWJGL purpose is to provide a direct, lightweight and game oriented binding of opengl for java. Context management is of no use in games, as for AWT/Swing widget, so, what's the point adding it ?

- On display creation:Jogl's system means you must 'guess' at what might or might not be avalible, which would be ok if failing actually triggered an exception. However what you really get is a core dump so you can't do jack about it. LWJGL's method of giving you a list of modes allows you to be much more confident of picking a working display.

A very surprising number of people jumped straight at JOGL to write games with, probably because it got that golden halo from Sun. But it's not a gaming oriented API, it's a completely integrated AWT solution for general purpose OpenGL. Similarly JInput is a hugely complex Swiss-army knife of an API. We just cut out everything that 99% of us don't need and left it at that.

When we get AWT rendering some eyebrows will be raised I should think.

There seems to be this image that because something is a semi-official Sun API it must magically be better, more reliable and more likely to be maintained over any 3rd party library.

The grim reality is that Sun don't care about gaming, and so don't care about its related technologies. Being an official Sun API didn't help Java3D any. And the GTG seem to have vanished without even the customary wisp of smoke.

A very surprising number of people jumped straight at JOGL to write games with, probably because it got that golden halo from Sun. But it's not a gaming oriented API, it's a completely integrated AWT solution for general purpose OpenGL. Similarly JInput is a hugely complex Swiss-army knife of an API. We just cut out everything that 99% of us don't need and left it at that.

When we get AWT rendering some eyebrows will be raised I should think.

Cas

Well, the problem is not the halo, but the focus.

You changed lots of things in LWJGL 0.95, removing something, too, and leaving lots of unresolved issues to whom want to upgrade (like the ILU.DLL dependancies just to be able to run a LWJGL game).

This left me uncapable of using JME with LWJGL 0.95 since I figured the fix, fix that when first appeared not even the development team wwas aware of (look at your forums).

This is not way a finger pointed in your direction but it's an hint to fly low with the ego... Cross platform support was clumsy from time to time (like in the donation drive for mac support), if also the architecture (well, it's not the exact term since LWJGL/JOGL are substantially wrappers) fails to remain stable and consistent there's no way to define it professional. Hacky may be a more appropriate term.

JOGL has focus on a subset of what LWJGL does but does it trying to remain compliant with old code. It has a slower development process, but it is also more harmonic.

You'll not see many: "I at the moment don't need it, so I will put it on the backburner", from the JOGL team.

Sure, Alien Flux drained some attention to the lib (but also spotlighted some issues in the deploy, like you admitted), but the aims are different. JOGL is a reference implementation, LWJGL is an hacky tool made to satisfy Puppygames needs, just like my Basilisk and the non OS Stirge engine were.

Don't get edgy when people spots the differences, the projects have different aims and intents, if decide to drop Java like many times you used to claim in the Indiegamer Forum, LWJGL will suddenly be without a huge part of its committment (but I'm pretty sure the project will continue).

These are the factors that are relevant when you are developing real software (that spans years, not a couple of months) and have to make choices.

Rest assured that I've nothing against JME, LWJGL, JOGL or Xith3D, but if one has to *rely* on a mature technology for a real project he has two choices: fork an existing project, or adopt a support license. For professional needs I'd like to use AgentFX, more than rely on unsure & unstable specifications, for example. If I've the money I'd like to try to get my in-house one. And for that I thank you all to release the libs in the OS-friendly BSD instead of the zealotish GPL.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org