We are considering splitting the LWJGL deployment up into separate .dlls and .jars for core, input, opengl, openal, and vector.
Our reasoning is that it’s entirely probable you won’t be using all of the features - particularly the vector code. Or if you’re just doing tiny graphics demos you might not want to ship the OpenAL stuff. Etc. Perhaps all you want is a hires timer?
So votes please: to SPLIT or NOT TO SPLIT?
Cas 
I have yet to have a chance to look at this but it seems to me that unless the code base is already getting large (> 2 meg) splitting it up right now just wouldn’t be worth the trouble.
Heh - it said Lightweight jgl ;D
alpha 2 is ~ 440 kb, this includes:
lwjgl.jar - jar file - needed (156kB, compressed)
EaxAC3.dll - OpenAL Eax + Ac3 Support - not needed, I am speculating (24 kB compressed)
lwjgl.dll - Actual native implementation - needed (64kB Compressed)
lwjgl_d.dll - Debug native implementation - not needed (131 kB Compressed)
OpenAL32.dll - OpenAL Implementation - needed, since most don’t have OpenAL installed (61 kB compressed)
So we end up with:
lwjgl Jar file + native dll + OpenAL32.dll = 281 kB
Rather small. But if someone where to do an OpenGL application, not using vector code or OpenAL or Input, why should the user then dwl it?
I am a bit torn on this one - theoretically I am all for splitting it up, but is it worth the effort?
Definetely: SPLIT!
Think of a webstart application and rapidly changing LWJGL implementations. Splitting will reduce d’load times…
I personally don’t think it’s worth it. Especially to the extent Cas it talking about.
Maybe just consider splitting out OpenAL from the rest…but again, if it were me, I really wouldn’t bother.
Well, we’ll try an experiment and see.
Cas
Split… personnally, i use all features (openal, input, vector) but it would be better for people who don’t…
LWJGL is a great lib…
Ch*man
Hi,
I think it’s a good idea to split it up. I consider it similar to the apache’s large repository of projects/libraries, it would be painful if I had to download all of apache.org’s software just to get at something simple. Unfortunately, the name ‘Lightweight Java Gaming Library’ implies a sort of monolithic chunk of code that you use to build games with. I’m not sure exactly how to address this, but the concept of ‘packages’ comes to mind. You could still keep the ‘Library’ name (in the sense that a real library has many books in it) but break out the components of the library into packages, such as OGL APIs, timing, sound, Graphics, Vectors, Pathing, etc. It could be that there are dependencies between these packages, but I don’t think that should mean you need to bundle it all together. (for example, the FOP project form apache requires many other packages from other apache projects for it to operate (xalan, xerces, batik, ant (compile only), some SVG stuff, etc). It’s the responsibility of the developer to know what package dependencies exsist if you are going to use a certain package. This also means that improvements can be made to very localized sections of an entire library…in addition to being ablet o pick and choose the sections of the library you needed (Could you imagine if you only wanted information in volume X of an encyclopedia but they said you need to chck out the entire encyclopedia if you want it! would suck…)
-Chris
Right now the library is organised in a way that makes it highly amenable to being split, and also provide the full distribution as well because it’s just not that complex.
There’s a “core” LWJGL, which contains a few basic utilities required by most users of the library, such as pointer fiddling and hires timers. Currently the vector maths is in there too (but not the vector packages).
As dependents of the core LWJGL package we’ve got input, OpenGL, and OpenAL, which are easy to split out of the Java distribution although it’s slightly fiddlier removing the C++ parts because you need a C++ compiler to hand.
I think I’m right in saying that we never intend to add more to the LWJGL than the bare minimum required to write a high-performance Java game in Java without having to code your own C++ to do something for you, so it is unlikely to ever grow significantly larger than it already is. A lightweight monolith…
Cas
Spplit it… that way when it reaches 1.0 I only have to worry about porting the portions of the system that I really want to port
Since someone trying to play my 48-hour game has it crash out straight away with “The procedure enty point alcGetEnumValue could not be located in the dynamic link library OpenAL32.dll”, despite me no having any sounds at all :o I’d say a split would be preferable if only to avoid such situations.
Hmm
The OpenAL part shouldn’t be loaded, unless you reference it?
and even though you do, ‘alcGetEnumValue’ should be defined in the dll:
section 6.3.5 of the OpenAL Sepcification:
uint alcGetEnumValue (const ALCdevice * deviceHandle, const ubyte enumName);
Does your friend have his own OpenAL.dll, which somehow got loaded instead of the one you’re supplying?
Can you reproduce the error, and if so - get the full source codes to lwjgl, and run org.lwjgl.openal.test.ALCTest and tell me the results…
the following works fine here at my end:
//get an enumeration value
System.out.println("Value of ALC_MAJOR_VERSION: " + alc.getEnumValue(device, "ALC_MAJOR_VERSION"));
???
Personally I would have preferred that most of this stuff was just set up using SPIs (service provider interfaces) so I could replace the OpenAL stuff with easier to use and more capable platform specific sound engine (for OSX).
well, then it wouldn’t have been Lightweight 
Anyhows - the library is specifically tied to OpenGL and OpenAL - what would the point be of a SPI?
If one was to do what you’re talking about, then we would be talking about a completely other game library, one which didn’t expose how it played sound or draws graphics. This just isn’t what we wanted to do. We wanted to create a library that is a fast as possible to use, from within java - we acknowledge that some might be turned of by having to use OpenGL or OpenAL (and any of the other packages), but we did this to allow for people to do it as fast as possible. That said, we do expect people to build a library on top of lwjgl for easier usage. (see: http://sourceforge.net/projects/spgl)