.
Before any flame war starts out here:
I’m really interested in an opinion from the community true (about what the advantages and disadvantages for JOGL and LWJGL are), but. I really want people to comment, who have both tried out JOGL and LWJGL. I (personally) think, many people haven’t even tried out JOGL and suggest LWJGL without even having tried out the alternative.
Don’t get me wrong, feel free to contribute your opinion on one of both if you haven’t tried out the other, but please say so 
On topic:
Personally, I’ve found that JOGL (or better, JogAmp) has a cleaner, OOP, API than LWJGL, which uses a lot of static, even in the Windowing code (so not only in openGL code, where it kind of ‘makes sense’ to be static).
But, they’re working on it! The development of lwjgl3 is in process.
And, lastly, Hello, and welcome back 
If you are deploying it on android and desktop you might wanna have a look at libgdx: http://libgdx.badlogicgames.com/
It has some great features and still allow basic opengl code.
I tried jogl and lwjgl, in my opinion lwjgl has a better documentations and more examples. Maybe I just haven’t found the jogl once, but because of that I have chosen lwjgl
Please, no flame war and no FUD.
Most JogAmp APIs (especially JOGL 2.x) support both mobile (Android 2.3 and later) and desktop environments. Our native windowing toolkit NEWT has been very helpful. JOGL OpenGL-ES support is very mature, this thread explains how to use JOGL 2 under Android. You already know JOGL, we can give you some help, feel free to contact JogAmp contributors and users on our official IRC channel and our forum. If you need some help on any framework, library or engine relying on hardware acceleration based on Java, let us know. Most popular ones already has a JogAmp backend, I updated those of LibGDX, Ardor3D and JMonkeyEngine last week. I advise you to go on using JOGL. The public API has changed a lot since JOGL 1.1.1 but we can guide you and the necessary modifications are simple. There are tons of examples using JOGL especially in jogl-demos, most of those of the Red Book have been ported and the API documentation is quite correct. The wiki is nice too. The native libraries are now automatically loaded without setting the Java library path.
I still think that maintaining 4 Java bindings for the OpenGL/OpenGL-ES APIs (AndroidGL, JGLFW, LWJGL and JOGL) is a waste of resources.
Edit.: Most JogAmp users no longer want to come here.
It works, just use the very latest version, JOGL 2.1.4 RC. Mac support has never remained broken more than a few days. Of course, JOGL 1 is obsolete and it doesn’t work on recent OS X. Tons of developers using Java3D 1.6 pre 9 (based on JOGL 2) are under Mac and frequently give us some feedback under Mac, don’t worry.
The irony. :
Riven, is there anything wrong about my posts in this thread? Xerxes (xranby), Sven and Michael Bien (bienator) rarely post here, some other JogAmp users have chosen not to register here but they sometimes read some posts and it doesn’t prevent us from quoting JGO, for example when we talked about the picking. Sven already told me several times that posting about JogAmp here is a bit pointless, we had some (good?) reasons to create a separate forum for JogAmp instead of using only the JOGL subsection here. JGO is a nice place to talk about Java game programming, probably the best place on the Internet for that purpose except when it deals with JogAmp.
There are no advantages or disadvantages to either API, honestly. They both just work. From a “metaperspective” on the existence of both APIs, it was at first sight fuckwitted to reinvent the wheel instead of consolidating efforts in the beginning, but good eventually came of it and JogAmp has helped give LWJGL a kick up the arse to get the API improved through competition for hearts and minds.
Cas
I switched from JOGL to LWJGL a few years back (http://www.java-gaming.org/index.php?topic=20496.0). While there are differences, whatever your need is I’m sure that either will suit you just fine.
Kind regards,
Mike