JOGL2 or lwjgl?

[deepthought]

should i use JOGL2 or LWJGL?

Jogl2 pros: it's easier to use with the texture utils and such.
cons: it's harder to port c++ examples to, it took forever to even get working

Lwjgl pros: it's closer to the actual opengl API, c++ porting is easier
cons: no utilities like texture and shader loading

which one should i use?

[Riven]

LWJGL anytime.

Texture loading is hardly difficult. Shader loading is like 40 lines of code (with error-handling).

You can grab such code from any tutorial website.

[deepthought]

how easy is it to do multiple display areas with a shared context? or maybe even different contexts?

Games published by our own members! Check 'em out!

[ryanm]

Just to counter your LWJGL cons:
Texture loading: have a look at Slick-util
Shader loading: Here is some code that I orginally appropriated from the princec's SPGL. Extend Program to define a new shader, as in this example

[kappa]

should i use JOGL2 or LWJGL?
which one should i use?

Not really a fair comparison, since LWJGL is a small gaming library designed help you create fast modern accelerated games in java (covering gfx, sound, input, native window system, etc), while JOGL is an OpenGL binding.

I'd pick LWJGL, since its small, fast, regularly maintainer (last release 2 days ago) and the community around it is just excellent.

cons: no utilities like texture and shader loading

Not really true, theres tons of utilities for it, probably more so then JOGL. You just need to know where to look.

how easy is it to do multiple display areas with a shared context? or maybe even different contexts?

By default its recommended that you use the native display, since its fast with minimal (almost none) AWT bloat but its designed for only one window, as that is what almost all games use. However you can pretty easily use LWJGL with AWT which allows support for multiple displays.

[gouessej]

regularly maintainer (last release 2 days ago)

JOGL is regularly maintained, the latest GIT commit has been done 2 days ago:
http://github.com/sgothel/jogl/commit/18bf27fa86da1f26fd085565f501736816d2f2e9

JOGL 2 is not yet completely stable but JOGL 1.1.1a is still available and works fine.

Not really a fair comparison, since LWJGL is a small gaming library designed help you create fast modern accelerated games in java (covering gfx, sound, input, native window system, etc), while JOGL is an OpenGL binding.

Therefore, compare LWJGL with JogAmp (JOGL/JOGL-ES, JOAL, JOCL, OpenMAX binding).

JogAmp handles sound (JOAL -> OpenAL binding is unfortunately not maintained enough), native window system and input (NEWT/NativeWindow), computing language (JOCL -> OpenCL binding), embedded support (OpenGL-ES is supported in JOGL 2)...

JogAmp and LWJGL are quite similar. LWJGL native window system and input have been more tested and used than its JogAmp equivalent, the OpenAL binding of LWJGL is better maintained than JOAL but the OpenGL-ES binding and the OpenCL binding of JogAmp seem less young and more tested than their LWJGL equivalents and sorry to remind you this some bugs impacting low end graphics cards and/or some window managers on Linux have been fixed after (3?) years of complain whereas JOGL has an excellent Linux support even on crappy on-board graphics chips and graphics cards sold in 1998 (Matrox Millenium G200).

I don't know the situation of LWJGL in this area (LWJGL is used in very famous video games like Poisonville and Minecraft) but JogAmp is used by several private and public organizations including universities, miscellaneous corporations, foundations:
NASA, IBM, Eclipse Foundation, SRA International, Ankama Games, Agency9, Masa Group, Sculpteo, Previznet, ...

JOGL can work easily with safety critical systems and is used in both scientific and military applications.

That's why I still advise the use of JogAmp and I'm personally invested in the JogAmp project, I keep an eye on the JOGL support of various API and engines (Ardor3D, JMonkeyEngine, GEF3D, jzy3d, NiftyGUI, ...). In my humble opinion, the latest stable release of JOGL (JOGL 1.1.1a) is more stable than LWJGL. Both sets of API should have been merged because it would allow to have a single stronger and more maintained unified set of API integrated in all 3D engines written in Java instead of having some engines that are more focused on one of them. Sorry for my very long reply. Sven and Mickael, keep up the good work

[kappa]

Therefore, compare LWJGL with JogAmp (JOGL/JOGL-ES, JOAL, JOCL, OpenMAX binding).

Yes that was what I was implying.

JOGL can work easily with safety critical systems and is used in both scientific and military applications.

So can LWJGL, you mention all these big corporations using JOGL but LWJGL is used by many big corporations too.

In my humble opinion, the latest stable release of JOGL (JOGL 1.1.1a) is more stable than LWJGL.

Doesn't sound very humble, but odd how a project that was abandoned and hasn't been updated in almost two years can be more stable, got any evidence to back that up?

[SimonH]

I'm working on JOLWJGL, a project that should settle this JOGL vs LWJGL niggling once and for all! 

Meantime I'd go with LWJGL. It worked straight out of the box for me, whereas I had a lot of hassle getting JOGL to work. LWJGL also seems to be better keyed in to other projects (jME, jPCT, jbullet &c).

[Nate]

LWJGL. The APIs should not merge, because JOGL has a ton of AWT cruft.

[gouessej]

Yes that was what I was implying.

I know that.

So can LWJGL, you mention all these big corporations using JOGL but LWJGL is used by many big corporations too.

I don't really know exactly which corporations use LWJGL but I never said no corporation uses it.

Doesn't sound very humble, but odd how a project that was abandoned and hasn't been updated in almost two years can be more stable, got any evidence to back that up?

JOGL has never been abandoned, look at the different repositories. However, problems with Oracle have complicated the situation and there were some problems of visibility. I complained about several bugs on Linux that have been fixed very recently whereas I have never had such problems with JOGL on Linux. I remember that the computer of my parents crashed when I tested the LWJGL version of Jake 2 in 2008 with Microsoft Windows XP, VIA on-board graphics with an up-to-date driver.

Meantime I'd go with LWJGL. It worked straight out of the box for me, whereas I had a lot of hassle getting JOGL to work.

I see, it works straight out of the box, I even had a pretty black screen some months ago (because of a regression with ATI graphics cards) when launching Space Invaders. Is it what you mean by "straight out of the box"?  If so, you're right.

LWJGL also seems to be better keyed in to other projects (jME, jPCT, jbullet &c).

Ardor3D has an excellent support of JOGL and looks like JMonkeyEngine. 3DzzD, Xith3D and Aviatrix3D use JOGL too.

LWJGL. The APIs should not merge, because JOGL has a ton of AWT cruft.

It is wrong as NEWT/NativeWindow does not depend on AWT.

Games published by our own members! Check 'em out!

[Riven]

Everybody please consider we are supposed to be trying to be informative about the choice between LWJGL and JOGL for somebody that already jumped the LWJGL wagon. Nobody really cares anymore.

[SimonH]

Everybody please consider we are supposed to be trying to be informative about the choice between LWJGL and JOGL for somebody that already jumped the LWJGL wagon. Nobody really cares anymore.

+1

15 programmers in United Kingdom have stated to be startled by SimonH's cod

Not half as startled as me! Down boy!

[Riven]

<offtopic>

Damn, sorry SimonH, I accidently modified your post (and restored it). I'm just awake and clicked the wrong button. I really shouldn't be president.

15 programmers in United Kingdom have stated to be startled by SimonH's cod

Not half as startled as me! Down boy!

It's a mix of random stuff and an educated guess. Stop worrying, I'm not after you. Yet.

[Nate]

Unfortunately JOGL 1.1.1a is no more maintained [snip]

[snip] I hope that we will advise everyone to switch to JOGL 2 in a few months when the whole API will be reliable enough [snip]

[gouessej]

It is a community project, we do what we can, we are only human beings.