The thing is we've moved on from the days when a couple of extra megabytes were a problem, now that video streaming and gigabyte game installs are the norm, JVM size (even with the extra crap) is insignificant, so even though its possible with the OpenJDK licence there just isn't a need to jump through the extra hoops.

@kappa - generally agree with your point. My question was more in response to what Cas said, and the fact that it's been legit for ~5 years to fork OpenJDK and do what he mentions - haven't seen much evidence myself of people doing that. Possibly too late to be worth the hassle, from a size point of view at least (on desktop anyway). Targeting other hardware would possibly be more interesting.

@cas - not aware of any OpenJDK Windows binary builds easily available (of 7, anyway - there is one of 6). However, is that relevant to what you're suggesting - surely you're talking about ripping loads of stuff out and building anyway?

Seems like we're losing sight of that fact that any size reduction and extra benefits for apps embedding java are just a single bullet point. Versioning of libraries and merging of the various additions are more generally useful bullet points for the community at large.

Isn't all this library interdependence thing largely a self-licking lollipop anyway? The whole thing about trying to just magically get a whole bunch of libraries to talk to each other no matter how you throw them together... it's just anathema to product development as I have practised it in the last 20 years.

Maybe I'm just weird and nobody else does this but... I pick the bare minimum of crap to get a job done, stick it together, and test the hell out of what I've got, finding all the issues and throwing out stuff that's broken or that has some sort of weird incompatibility problem. I thought the concept of the classpath was just utterly awesome compared to picking up random modules from anywhere arbitrarily configured on a user's path. I can guarantee at deployment time that what runs is what I've tested. Well, I can on Windows anyway, with the Mac and Linux I've been hobbled by the annoying tendency to have system JVMs and therefore a major component almost completely beyond my control.

I suppose it's the enterprise types with their insistence on being able to - pointlessly, I might add - bung piles of jars and webapps in the same process, which are causing all of these mysterious headaches over versioning and modularity. In the meantime the baby circled the drain and went out with the bathwater - the mini JVMs that would have been useful only 4-5 years ago never happened, nobody managed to make a nicer plugin for applets to compete with Flash because of this, etc. and Google made Dalvik and stuck two fingers up at the whole lot.

I think this is what annoys me about Aptitude and Linux repos as well.

Maybe I'm just weird and nobody else does this but... I pick the bare minimum of crap to get a job done, stick it together, and test the hell out of what I've got, finding all the issues and throwing out stuff that's broken or that has some sort of weird incompatibility problem. I thought the concept of the classpath was just utterly awesome compared to picking up random modules from anywhere arbitrarily configured on a user's path. I can guarantee at deployment time that what runs is what I've tested.

Definitely agree with the "picking the bare minimum". As I've stated before, Praxis is built using the NetBeans platform - having a decent module system is great for ensuring you're running only what you need to be running, and for ironing out incompatibilities. Having a decent module system by default is IMO a really good progression.

I suppose it's the enterprise types with their insistence on being able to - pointlessly, I might add - bung piles of jars and webapps in the same process, which are causing all of these mysterious headaches over versioning and modularity ... I think this is what annoys me about Aptitude and Linux repos as well.

I'm having difficulty squaring up these comments with your comment on "bare minimum of crap". Surely modularity and versioning are the best way to achieve that?

(I could sort the Linux one out more easily but MacOS has some problems with OpenJDK and LWJGL right now so I'm stuck)

A decent module system, as I saw it, was one where I simply said, here are the jars containing the code I want run. This is a commandline that says these jars are the only place you look for code. Go! And it was - is - as simple as falling off a log. I just don't get why we needed anything more complicated... I am aware I may sound rather obtuse but maybe someone with more experience in the big bad world can explain to me why this fascination with modules and dependencies and versioning solves a problem better than just picking the code you want to run and using it.

Cas, I think the major difference in how you and a JEE developer approach a problem would be that you try to write it yourself, because what you need for 'simple' games is probably doable in a limited timeframe, whereas a JEE developer thinks: what has already been done - because it might take a few man-months to code similar functionality - what can I hook into and how can I couple different pieces of libraries. Say this typical JEE developer ends up including 3 libraries 'to quickly shelve out a prototype' (or whatever), and 2 of those libraries have a dependency on different versions of the same library. Are you going to tell your boss that you are (or he is) screwed, or are you going to install some tool that supports resolving these incompatible dependencies through classloader hacks in a matter of minutes?

Needless to say that 'bare minimum of crap' also applies to your time.

Note: I always stuff libraries in the classpath, I have yet to encounter this problem of incompatible dependencies...

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

@Cas: What I do is pretty similar. In C or C++ I never touch standard libraries (except for quickly banged out tools). To a lesser extent I do the same in Java. It's not because I insist on re-inventing the wheel...it's because I already have a wheel (maybe in a different language, but porting most stuff is a breeze). So I don't waste time looking for someone elses wheel which probably doesn't do exactly what I want anyway. But that's exceptional. Most people will heavily rely on system provided libraries. And infinite backward compatibility (which is a myth anyway) is a real drag as there's no real way to avoid bit-rot. Simple example: hashing in java blows but were pretty much stuck with Bernsteins for backward compat. If you allow versioning of libraries then it would be reasonable to move to CityHash or MummerHash(2,3) or whatever else.

Gotcha. I can see where the problem lies now. Even with the most amazing It Just Works modularity system in place I can see it turning into a maintenance nightmare if you've got multiple versions of the same classes floating around in the same application though :S Believe it or not when I used to do this sort of stuff (and indeed, was the manager) I stipulated that if you had two versions of the same library causing a problem you made it work with one or the other or ditched it.

The thing with JEE is that you don't have choices; you can't be minimal, you can't cherry pick, you-just-cannot. As soon as you install the application server you're already married to a cool 100 libraries that are delivered as part of the implementation of the specification, are transient dependencies of said libraries and to just get the server to do stuff. Then you have that which you would like to do in your application which might just require libraries not delivered by the application server - the fun and "jar hell" starts there.

In that respect Jigsaw can help a lot because you could for example define the server as a module (or a set of modules) and each application deployed through it as a module of its own. You could define the components of each application (different webapp wars, EJB modules, etc.) as their own separate jigsaw modules. Application servers are now forced to use complex classloader schemes to get isolation working, with nightmarish problems as a result when you do it wrong and many limitations in what you can actually do.

Not to mention the biggest load of dung in JEE land: reloading of resources upon redeployment. Even 12+ years later it is still not great unless you fork over cash for JRebel. Classloaders are not my friend.

Related - was the application partitioning stuff part of Jigsaw? (The one where you can effectively run multiple Java lightweight processes inside a single JVM OS process, each with their own heap, garbage collector, etc)?

I've done a few OSGi apps, quite simple, but multiple versions did sometimes creep in. The answer whether that's a nightmare or not is ... it depends. If one app depends on two versions of Spring, then Yes, You Are Royally Screwed. However, if two libraries have dependencies on two different versions of, I dunno, commons-lang, then it's no sweat at all. Eclipse plugins are another example here, where you can have different plugins using different libraries without interfering with each other.

And beyond plugins and libraries with skewed versions, remember you can have multiple apps outright. I never bother with that feature (I just spin up Jetty on a new port) but it's still handy for a lot of people.

Going beyond multiple apps and having entirely separate java environments in one JVM is called multitenancy. That was not one of jigsaw's stated goals, but it'd certainly give it a boost. One of the best uses of multitenancy is in mobile apps, and Dalvik has some support for it (but it's kind of crude). Sun actually wrote a multitenant VM a ways back and Oracle makes noises about merging it into openjdk, so we might see it in java version, I dunno, 15 or so?

I wish a module system had been there from day one, i see lots of 'svn projects' with the dependencies in the repository as binaries that inevitably get out dated or their dependency unused (but still in the classpath because no one wants to 'break' things).

It's just pathetic in the age of apt-get and maven (and the advantage of being able to test the new versions of the libraries easily is not to be overlooked either).

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org