Seeing as how the download page on the LWJGL website shows LWJGL 3 downloads. I’m wondering if I should use LWJGL 3 yet, or stick with 2 for the time being?
I’ve been using LWJGL 3 for the past month. Working great for me.
Same, I’ve been using it for the redo of my game engine
If you go with LWJGL 2.x, expect to find a lot more resources on using it. If you ever run into a problem, you’ll probably have better luck with finding solutions for them online.
I don’t plan on moving to LWJGL 3 for a long time since I don’t think it would speed up development for me.
If you think it’ll help you, then go right ahead.
As for stability, there have been a number of reports of it being buggy across different platforms. However, I’m not really in the right position to make a final judgement since I haven’t used it that much yet.
Cheers.
- Jev
I’ve seen that the API from LWJGL 3 is VASTLY different from 2, which is ironic because I just got used to the LWJGL 2 API, I’m just wondering if using LWJGL 3 would have any benefits at all, because if not, i don’t see the need to use it.
I know.
Just because it’s different doesn’t mean it’s better. 
The reality is that you’ll be perfectly fine if you continue to work with LWJGL 2… nobody is going to care in the end.
Don’t waste your time throwing away everything you learned about LWJGL 2 just so you can learn 3. Your players aren’t going to care about what framework you use. 
- Jev
While this is true, development of 2 will be discontinued unless someone picks it up. Right?
In the long run, it would be smarter to learn 2, seeing as how when an official release of 3 is out, 2 will be ousted. So it would be smarter to learn it, but also they did say something about bringing in the legacy api to 3?
You missed the sticky!
[quote]LWJGL 2.9.2 has been released today. […]
This will most likely be the last LWJGL 2 release.
[/quote]
I did a direct copy and paste of a game pretty much from LWJGL 2 to LWJGL 3.
the only error I had (that I remember) from the copy and paste was my Shader loading class, which was horrible in a way, so I changed it.
for changing the display to GLFW, well I pretty much just followed the LWJGL 3 GUIDE, when I did it there was one mistake in it, but I managed to work that out by just checking out the LWJGL3 wiki.
I think if you have a little bit of experience in LWJGL or just OpenGL in general, it should not be really much of a difference.
SHC has also been writing LWJGL3 tutorials on his website, so you could follow his tutorials to learn how set up GLFW.
But that brings up 2 questions,
- Would switching to LWJGL 3 with the new API’s be better in the long run?
- Is LWJGL 3 even stable enough for use?
Better in the long run?
Yes, LWJGL 3 has a bigger plan then just target desktop. And is going to be adding other stuff such Occulus rift support. Also, LWJGL 2 is no longer being maintained, so any bugs will most likely stay in it for ever, while bugs will be fixed in LWJGL 3.
Stable enough, I think it should be, if it was not stable enough, I do not think they would of started to release builds for use.
Nah I didn’t miss it. I know its over. But Spasi said:
[quote]If anyone is interested in taking over maintenance of the project, send me a PM
[/quote]
[quote]Stable enough…
[/quote]
Everyone is encouraged to use LWJGL 3. Being a community project, which not many developers currently rely/build on, it is vital for the project to be used more widespread. LWJGL 3 does not mature/get stable on its on.
It relies on the community to use it and (honestly) find, report (and possibly fix) bugs.
The current stability only results from early developers already using it and parts of it (namely GLFW) and detecting bugs in them.
For me, one of the very great things about the LWJGL’s authors is that they are really eager to take care of any issues found within it.
They simply do not have the time to thoroughy test LWJGL, so they are more than happy to hear about any issues you report and are very eager to fix them!
Regards,
Kai
You can think of LWJGL 2 as two parts; the bindings to native libraries and the cross-platform window/context/input/controller API.
The bindings in LWJGL 2 are a very thin layer on top of the native libraries they expose. The bindings in LWJGL 3 are just as thin (thinner actually) and are very compatible with LWJGL 2. They are not 100% compatible because of some bug fixes here and there and the OpenCL bindings redesign. They are much nicer though; you get unsafe bindings (direct access to the JNI functions), more convenient overloads and, best of all, inline documentation.
The rest of LWJGL 2 is (relatively) a lot of code, written in both Java and C/ObjC. It is what it is, does the job for which is was designed well, but has the known problems and limitations. LWJGL 3 on the other hand, does not have anything like that. There are some classes, like the GLContext and the ContextCapabilities, but that’s it. There is nothing there to be stable or not. Everything related to windows, monitors, contexts, keyboard, mouse and controllers is being done with GLFW. Which is yet another library binding in LWJGL 3. So, the real question is if GLFW is mature enough. Well, it’s a library almost as old as the original LWJGL, but has been rewritten in version 3.0, just like LWJGL. We’re currently close to the 3.1 release and I’ll quote its developer:
[quote]GLFW 3.1 has closed more issues than every previous release combined since GLFW moved to its current home on GitHub. Two issues remaining.
[/quote]
Other than, I’ll just say you’re going to have to try it and judge for yourselves. Disclaimer: GLFW does everything (much) better than LWJGL 2. There is only one feature missing and that’s setting window icons programmatically. It will be added in GLFW 3.2.
With that said, I’ll repeat here that LWJGL 3.0 has not been released yet. There’s not even an official “alpha” build available. There are many users trying the nightly builds though and many platform/environment-specific issues have been resolved. I’m pretty confident that the first official release (scheduled for when GLFW 3.1 is out) will be stable enough for everyone to enjoy. Of course, it would be irresponsible to say right now that you should start porting your applications to LWJGL 3. The bindings are incomplete (e.g. many OpenGL extensions and OpenGL ES are missing, OpenAL needs work) and we’d like to be open to feedback for the rest of the API right until the final 3.0 release (the API will freeze then). The non-binding API is so small though, that any breaking changes will have minimal impact to early-adopters.
My unofficial/personal/humble opinion is: If you don’t need AWT/applet interop, there is no reason whatsoever to stick with LWJGL 2. 
thanks for the heads up.
only reason why i did not dig into 3.0 yet is the missing swing-interop. opengl is not only used for games, so it is a bit of show-stopper in certain projects.
once you “release” 3.0 i’d dig into swing/awt interop and see if it’s possible to mimic 2.x behaviour without too much hassle. i did not catch the full info on the LWJGLX features but afaik swing is not planned, right ?
Well, the Swing/AWT/JavaFX/(insert other Java window managing systems that I don’t know of) isn’t necessary, you can still use GLFW for other things than games. Yes, you do have to write or find a GUI system, but it’s not that hard. GLFW is kinda like Swing/AWT without Component classes combined with OpenGL. Well, not really, but it’s pretty similar to OpenGL.
I have been using LWJGL3 since a month, and I haven’t stumbled upon a single bug, it is really really stable. As of now, AWT will only work with LWJGL (yes, but only a certain part of it) in headless mode. You have to add this to your class to get access to Fonts, ImageIO and BufferedImage classes.
static
{
System.setProperty("java.awt.headless", "true");
}
The reason for this behaviour is that both GLFW and AWT needs to start on the first thread to gain access to windowing stuff on OS X. Also, you need to run your application with [icode]-XstartOnFirstThread[/icode] JVM option if you want it to run on Mac OS X.
Other than those, it is pretty stable. The best proof on the stability is my SilenceEngine, it runs on LWJGL3. In my opinion, you should really consider moving to LWJGL3 if you haven’t still. And, coming to GUIs, I think you have to implement it on your own for now.
[quote=“basil,post:16,topic:52956”]
Correct, it is not planned for 3.0. If there’s enough free time after 3.0, I’m still interested in exploring interop solutions, especially for JavaFX. Obviously, I’ll be glad to help if you need assistance.
Note that LWJGL 3 exposes all platform-specific context management functions and you can even call anything missing using libFFI. There will also soon be bindings to the Objective C Runtime (for interacting with Cocoa).
[quote=“Spasi,post:19,topic:52956”]
Incidentally, has there been any movement on that front since your lwjgl/jfx integration demo? Or are you going to wait and see what happens with the interop feature request?