No, S3TC has been specifically supported for 10000 years.
Cas 
JogAmp includes some useful features that LWJGL does not. For example: GPU text rendering, texture IO.
The latter feature is probably what had you mistaken about texture compression. It includes a DDS format, which means it can decode a DXTn (S3TC) compressed image. LWJGL doesn’t include any image decoders, and so you need to write your own DDS decoder (a basic decoder is fairly simple). However, the actual process of using compressed textures on the GPU has been supported by OpenGL (and thus LWJGL and JOGL) for ages.
Note that these aren’t “missing features” of LWJGL. The library is designed to be a “thin wrapper,” without the fluff of textures, fonts, etc. This is why Slick-Util tends to be a popular starting point for decoding.
Ideally one day a library more suitable than Slick-Util will take the stage.
Eh, sorry for being the trigger that caused this thread to derail 
I was referring to JOGL being “only” an OpenGL binding and LWJGL more a complete set.
@gimbal it’s the other way around. LWJGL tries to have as little utilities as possible. It’s only job is to have bindings for OpenGL, OpenAL, and OpenCL. Any other utility is for higher level wrapping libraries.
And mouse, keyboard and controllers. And a simple display API.
Cas
Does that include applet/Swing support?
I’m not helping. Why use LWJGL in stead of default JDK stuff. Go!
It does include Applet support, but Swing things can be included too, since you have the Display.setParent(Canvas), but in my opinion it’s easier with JOGL’s GLCanvas 
I don’t see the point of relying on at AWT anymore. LET IT DIE!
Why that? I like awt…
I used to like AWT, then I took an OpenGL to the brain.
AWT’s fine. Well the windowy bit is anyway. Rather complex though, and the Display API was conceived as something ultra simple that “Just Worked”. It’s a bit lacking nowadays with the prevalence of multi monitor displays and the subtle encroachment of LWJGL into general application domains instead of just games. There are musings of a rewrite for LWJGL 3.0.
Cas
Yeah… your right about the Java2D part of AWT. But the window Toolkit is rather good (IMO). And I think it’s even better as a combination with JOGL (since this is the OpenGL you took to your brain 
).
OH! awesome. I have problems with the DisplayModes from LWJGL. I can only play LWJGL-games on super-fullscren, which means: over 2 screens… And that does not look good. Not at all 
Bad thing too is, that many LWJGL-Users just allow the game to be fullscreen and that, well, sucks.
Oh, and I can’t wait for the LWJGL 3.0 release
That’s gonna be a looooong while
I forgot to say that JOGL has a SWT heavyweight canvas and a kind of fully OpenGL-based Java2D implementation (GLG2D on Github). If you don’t need some utilities, you are not forced to use them during your deployment, you can use the “atomic” JARs.
The most important file to distribute your game is not an installer, not a webstart, applet or zip.
Its : tada :
a screenshot.
and/or a Youtube clip
The more people get interested into the game, the more effort they will invest to
get it running.
Getting a leaked Demo of Halflife 3 running will make users invest a lot more time to get it running,
than a 500MB Casual Pongclone without any screenshot and distributed in a tar.gz file with uncompiled sourcecode.
So easy installation is the more important, the less interesting your game seems.
You should optimize on both fronts. (Presentation and Access)
In doubt, have at least a decent zip, with .bat and .sh(linux) batchfiles to run the game without much
hassle.
BTW: is here a “how to arrange and distribute your game files” Tutorial somewhere?
Would be very usefull.