OK, how many people are maintaining LWJGL for comparison?
I don’t know but they have no bug tracker and in my humble opinion, when it comes to Linux, they often quickly conclude the bug comes from the driver rather than their library… It happened at least twice in the past, I succeeded in proving once than I was right. Look at the LWJGL section here:
http://www.java-gaming.org/index.php/topic,19786.0.html
This is proving to be a very difficult choice indeed! There are pros and ons on both sides of the equation. I guess I am concerned about the long term future of JOGL but that may be only a result of FUD as you say. On the contrary, if the LWJGL team are not prepared to acknowledge bugs/faults in their own product and instead shift blame to external factors then that’s a real worry too.
In the end I want something which just works (at least 90% of them time!), is supported, has a reasonable long term future and has the functionality I need it to have. There doesn’t seem to be anything in it on the functionality side so I guess it’s going to come down to which library makes the most sensible and safe business decision.
That part is not so obvious, at least not yet.
Actually I think what that post tells you is that the LWJGL devs are extremely quick and thorough and responsive when we get any bug reports, at all. We fix things as fast as possible and do a new release as soon as we can, as opposed to JOGL, which has been apparently frozen for quite some time.
And yes, gouessej does present some unusually pathological cases with weird versions of Linux with ancient graphics cards and OpenGL drivers. LWJGL is committed to providing stability for the vast masses and if we can’t reproduce bugs because they’re on fringe hardware the only solution is for gouessej to fix them himself and commit a patch once he’s found out what’s wrong. However, as we maintain, most of his problems come from buggy drivers (for example, his repeatedly documented display corruption from LWJGL fullscreen applications should simply not be possible from a desktop application, yet instead of bugging the driver writers he keeps hassling us instead - and so it will never be fixed).
Business wise, LWJGL is in safe hands. At the very least it’s the foundation for Puppygames.
A list of contributors can be found on http://lwjgl.org/credits.php - we are many. The bulk of the coding work was performed by underground Danes, who receiving almost no visible sunlight for most of the year, have little better to do except maintain OpenGL bindings. These days much of the work is done by Spasi of these parts, who being Greek, has to turn out a monumental effort just to get out of bed most days let alone turn the computer on, yet somehow he has implemented all the OpenGL interfaces since 2.0 or something.
Cas 
Yes, you get to choose which side to be on in a pointless flame war.
No! I have asked some people to test on recent machines (gamers machines with some very recent ATI graphics cards) and I have tested at work with my workstation (NVIDIA Quadro FX, Intel Core 2 Duo, CentOS 5.3). I have tested with several distros, Ubuntu, KUbuntu, CentOS, Mandriva, Fedora, the results is the same. I have tested both with Gnome and KDE, the result is the same. I’m fed up with repeating the same thing.
Chagma, I encourage you to check it by yourself with a Live CD, it is highly probable that you will reproduce this bug.
This is not my decision, this is Michael’s decision.
Concerning the maintenance, there are 3 people that share most of the job but there are some occasional contributors too. JOGL needs less maintenance effort because some painful steps have been automatized, the code that deals with JNI is generated, it does not use any hand-written template. Kenneth Bradley Russell now works for Google and as far as I know, he does not work on JOGL anymore. Sven Goethel left Sun some months ago and is currently a bit busy. Michael is very busy with JOCL.
This more like a flame pillow fight. 
LWJGL FTW!
That’s interesting, there is quite high variety in your tests. What is your exact testing procedure? Weird thing is that I didn’t observe such thing, nor did any of my users mentioned it to me. Also didn’t saw anything like that from anyone other on this or other forums.
No reports either from any of the several thousand Linux players of my games. Except gouessej.
Cas
We test the demos on lwjgl.org, especially “FullScreenWindowedTest”. When we have some more time, we test some free demos including Puppy games. We are already 3 programmers to experience this problem with completely different hardwares. The only workaround I have found is to force AWT to reset the good display mode.
Chagma, why don’t you write two smaller “demo” apps with lwjgl and JOGL just to get an idea. You may find the decision easy after that.
One of my main reasons for using LWJGL is its great community.
The LWJGL irc channel (#lwjgl on freenode.net) is probably one of the most friendly (provided you are too ) and best places to get help for almost any java problem (yes, even JOGL problems :)). Some of the ppl that hang around there are the most talented and genius java games programmers I’ve seen
Are you seriously insinuating the code in LWJGL is handwritten?? FUD alert!
Indeed, it’s mostly auto-generated.
Cas
For me, it’s a pretty easy choice: LWJGL. I’m making games, and LWJGL includes much more than just openGL bindings. I get graphics, sound, input, and a great community.
I have tested several Puppy Games games on Ubuntu 9.1 with no problems. All of them in fullscreen mode.
from a personal point of view.
what helped me decide, was by the games that were made in each. at the time I was very impressed with LWJGL success with higher quality games.
I dont know what the difference is ATM. but I have since commited to LWJGL.
Also 1 handy thing with LWJGL is the timer. Im not sure if JOGL has any good equal (or better) version of this.
No, I’m not saying that LWJGL is handwritten.
If your xorg server supports several bit depths simultaneously and if the refresh rate is unknown, the bug is always reproducible. I will give another try on Mandriva Linux 2010 when I have some time to install it.
personally, i have written an interface for all GL functions and can now choose between a jogl and lwjgl implementation, i could also add a new binding easily, if one would exist.
behind that, i mostly choose LWJGL, since it just seems to be faster, the framerates are not so spikey and it has that high precision timer!
The bug of the straight lines is no more reproducible on my workstation whereas the OS has not been updated since the last time I tested LWJGL. Good job! ;D I don’t know how you fixed this bug but it is nice I will test on my own computer at home to check if it is completely fixed.
I’m currently testing other older LWJGL applications to determine when it has been fixed.
The native canvas of JOGL 2 gives interesting performance and I don’t have a spiky frame rate even with JOGL 1.1.1a as far as I know.