Hi. Dumb question, but I am not on a computer at the moment.
Can I use lwjgl3’s stb image loading library with LWJGL2?
I think the answer is no
You can use LWJGL2 and 3 at the same time AFAIK. And LWJGL3 is modular so you should be able to use just the image loading lib.
Cas 
actually it looks like princec is correct, I haven’t downloaded the modular setup before. The only thing you need to be careful on is the fact that you might have the same class in both lwjgl.jar’s (2 version and 3 version)., I don’t know what conflicts you might have or even if they matter, I’d just be weary
I’m afraid, LWJGL2 and LWJGL3’s core and stb modules are not interoperable.
The first problem you’ll run into is that LWJGL2’s jar files are sealed, so no other jar file is allowed to define classes in the org.lwjgl package. This can be circumvented by editing the jar file’s MANIFEST.MF and simply removing the Sealed: true attribute.
The second problem is that the PointerBuffer and BufferUtils classes conflict and they are used throughout LWJGL3’s core module.
So, when you have LWJGL’s jar files specified in the classpath before LWJGL3’s jar files, you’ll run into JVM bytecode verifier errors because PointerBuffer in LWJGL2 does not implement CustomBuffer (expected by classes from LWJGL3).
If you have LWJGL3’s jar files before LWJGL2’s jar files in the classpath, you’ll run into a NoSuchMethodError when working with OpenGL methods, since LWJGL3’s BufferUtils does not implement getElementSizeExponent() needed by LWJGL2.
Another problem is the natives. Not, that they have conflicting function exports, but that the shared library files have conflicting names. LWJGL2 uses ‘lwjgl’ and ‘lwjgl64’, whereas LWJGL3 uses ‘lwjgl32’ and ‘lwjgl’.
If you are not very careful and load LWJGL2’s natives from the file system (via java.library.path or LWJGL’s alternative) and load LWJGL3’s natives using the SharedLibraryLoader, you’ll get native method not found exceptions.
For example, when you extract LWJGL2’s shared libraries into one directory and LWJGL3’s into another then either bootstrapping LWJGL2 or LWJGL3 will fail depending on the order of the file system paths in the java.library.path property.
Ah, that’s a bit of a pain.
I seem to recall mutterings about how all this stuff should have been hived off into totally separate projects a while ago…
Cas
The class incompatibilities can be solved by using a separate ClassLoader for LWJGL 3.
The native library name is not a problem either. You can rename it in the jar and use -Dorg.lwjgl.libname to specify the new name.
But then you get into some wankery with System.loadLibrary that I didn’t have the patience to solve. For something like this, I’d use a separate JVM and an IPC solution to transfer data.
I’d not bother trying to use two separate and incompatible versions of the same library, why not just drop LWJGL2 and update the project to use LWJGL3?
I haven’t been following lwjgl3 lately. Last time I tried it, I couldn’t change from fullscreen to windowed dynamically, and that made me upset.
Then I guess it’s time to give it a try again