I decided to tackle the issue of image loading in jME. Specifically, its dependance on AWT. I’ve come up with what I think is a cleaner implementation.
The architechure is pretty simple: a single singleton class ImageLoader now handles the creation of com.jme.image.Images from image files. Its primary method, loadImage(), is responsible for determining the format (unless specified), loading the image data, and creating the Image object with the appropriate data.
The LWJGL implementation uses the newly-introduced DevIL to load the images. This means that jME now supports a whole ton more image formats, hopefully making the API more flexible. It would also be simple to transfer the old AWT code out of TextureManger to make an AWTImageLoader. Finally, if we write our own loaders, we could implement an IndependantImageLoader. All the user sees is the familiar ImageLoader exterior.
You can check out the source for ImageLoader and LWJGLImageLoader. Both formatted and coloured, of course. 
It’s not quite finished yet, but it works correctly. The code for TextureManager is a lot cleaner now. All the demos I’ve tested continue to work perfectly.
So… thoughts? One thought that I’ve had is the additon of a method that accepts a java.awt.Image and returns a com.jme.image.Image. (However… I’m hesitant to add any reference to AWT in ImageLoader.)
What’s the chance of DevIL being ported/written for JOGL?
My thoughts would be that the chances are low. However, given JOGL’s existing dependance on AWT, I would have no qualms making the JOGL ImageLoader based on AWT. (Essentially, taking the current code and wrapping it in the new API.)
actually - lwjgl-devil should work just fine with JOGL }