This is why I waited for the 3.0.0 release before merging the LMDB branch. I expected some controversy and wanted to see if enough users would find it useful first. Currently LMDB only exists in a nightly build of 3.0.1. No harm has been done. This is also the 3rd time I have to mention in this forum that 3.0.1 will not be released without a solution for #100
, which will break the LWJGL distribution in separate artifacts for each binding; you will be able to choose what you want or don't want in your application.
I think you're being a little defensive about my observations, Spasi! I'm quite aware of the 3.0.1 goals already. What I am questioning is that LWJGL is, as a whole, becoming quite a sprawling mess of functionality, and that (as you allude to below), it appears to be largely driven by you and your own personal needs and as such seems to me to have become a giant git repository with all of your open source work in it. This is an important observation, which I'll get to...
What it definitely isn't, modular or not, is a lightweight Java games/graphics library! It's no longer a lightweight project
as it covers everything from GUIs to compute to audio to in-memory databases to hacking the Java language to get structs in. It's not Java any more as it now contains multiple binary libraries. It's not a single library now but a whole multitude of libraries. So there's that to think upon.
I bet no more than 5 users have ever used LWJGL's OpenCL bindings, yet I find them super-important and have spent countless hours working on them. Why aren't there any complains about those?
Because it still satisfies the original premise of LWJGL, which is the minimum and most direct binding to a native API possible to achieve something vaguely game-related. Personally I wouldn't have included it either, but I'll get to why in a mo...
or even in a Java context... I'm very reluctant to bind to native code to do stuff that Java code can do. The LWJGL was all about binding to native APIs that could not otherwise be done in Java
I don't agree with this either. Just because something can be implemented in Java does not mean it should.
There are many ways to implement functions, but the question is not which language something should be implemented in, but whether it should be implemented at all. The crux of the matter hinges on a comment you made about LWJGL 2:
- Look at the mess LWJGL 2 was in. There were dozens of bugs and no one to fix them. Who's going to write a decent windowing system in Java (or anything that touches lots of OS-specific APIs like GLFW and LMDB) and maintain it?
What LWJGL 3 is now is a vast collection of bindings, most
of which are irrelevant to most
people. What this means is that maintenance effort is going to be simply non-existent on it, and once you (eventually) grow tired of it, and you will, it'll just stagnate and get bitrot and become a large legacy which will distract people from otherwise creating separate efforts to solve specific issues.
I lost interest in maintaining LWJGL after a few years of developing on it, largely because it did everything I needed it to by that point, and also because I was seeing virtually no return on my efforts. I watched Markus accumulate two and a half billion dollars on the back of the literally months and months of effort I'd put in on the library he used to catapult himself into the realms of the unspeakably rich with barely so much as a thankyou, and that, for me, was the point at which I decided I couldn't be arsed with open source any more. I only have so much time left in the world and a lot of things I'd like to do, and making Markus richer wasn't on the list, so I diverted my efforts elsewhere. At some point, you too will find something more interesting and distracting, and you'll be leaving behind a huge, huge pile of stuff which no-one except you really cares too much about.
I strongly advise you to split LWJGL up into the bare minimum and then create separate, independent projects that build on top of or besides LWJGL for GUI libraries, structs, OpenCL, in-memory databases, vector math, etc.