Actually I agree. Look what the whole 32 bits / 64 bits co-existence madness has done to the pc; what a maintenance nightmare.
I’m not 100% sure of what’s going on with OpenJDK on the Mac but I do know that getting a smooth transition from the Apple-maintained framework to using OpenJDK is of particular interest to me. Also there are problems with LWJGL and OpenJDK which need to be resolved urgently but so far nobody is able to do it AFAIK (unless Mojang have made some progress).
Cas 
Ah, I get it now
And again I agree - OpenJDK moving to the Mac I see as one of the highlights of Java integration and acceptation progress as now it covers the big three without fragmentation. I don’t want to diss Linux being one of them Linux freaks but Mac is simply a more important platform nowadays - in that respect I feel that Oracle is a bit… silent. You hear that stuff is going to happen, you perhaps get a preview but its basically just “there” all of a sudden. Here it is, download it, have a nice day and if you have trouble… static noise.
I’d expect a more open way of providing and getting feedback on something as exciting and new. But that’s just Oracle I guess. The best they do ‘for free’ is that one person keeps an eye on specifically named OTN forum threads twice a week.
Nice read. Although I am a bit tired of people blogging what they think is the truth and then hide behind the “but its only me, I may be wrong!” argument. No! Stand behind your opinion and get it into the brain of others, or at least suffer the consequences of your failure to understand and be corrected in public for everyone to see and smirk about.
That being said, I am inclined to agree what the dude has to say up to the “this is a compatible java reboot” part. Naw its not, its more a progression of what already exists (the classpath system) and what others have built (OSGi). On that note, I think I’ll just have to give up hope for Jigsaw to exist any time soon and just go look into applying OSGi for now…
All they damn well needed to do was just shuffle a couple of classes about into packages and separate each package into a jar with any dependent dlls and change the terms of the license to allow distribution thusly in “embedded” projects. You know like how several of us managed to just chop our JVMs down to 2.4mb download payloads, 10 years ago. Grrr. Pointless complexity and politics and overengineering to solve such a trivial problem (“it’s too big because it’s full of crap we don’t need or use!”)
Cas
Yeah that’s all they needed to do except for the part about it not working even remotely like that. There’s more to a module system than just “chop up the jars”, like versioning and dependencies. Or would you like to be stuck with more half-assed hacks for the next 15 years?
I get more than a little tired with all the armchair architects who claim that everyone else’s job is always so trivial that any idiot could do it.
I think my point is that they are solving a problem hardly anyone had and ignored a huge problem that lots of people had, and now they’ve spent so long on it no-one really cares that much any more.
Also - it really was that simple, and it wasn’t even a hack. The issue wasn’t even technical - it was purely legal. So desperate were Sun to prevent people using their IP in a way they didn’t approve of they got to the situation where Dalvik was created and now owns the world.
Cas
You still seem to believe jigsaw was solely about minimizing the JRE size, and that’s simply not what it was primarily about. The target audience is JavaEE platforms which all tend to do weird classloader hacks that aren’t really standardized, and are all moving to OSGi, which has its own set of issues. I’m sure the mere mention of EE will provoke a new round of scoffing, but that’s the way it is.
Or I should say “was” the target audience, because I now have my doubts jigsaw will ever ship. I could live with a little “half-assery” that at least broke goofy crap like CORBA out of rt.jar. They already do that sort of thing for XML parsers after all.
Ah - you kinda agree with me. I could live without AWT, Swing, RMI, etc. etc. as well. I don’t think it was all about reducing JRE size, but that was my own personal issue with it. Various others have had issues with being forced to include (or specifically “port” stuff) that was irrelevant in order to get a license etc. Simply being able to chop all the crap out of the VM and add whatever you wanted to it would have probably led to a plugin like Unity being built from Java instead of Mono but it doesn’t really matter any more.
Cas
@Cas - doing that should be perfectly legit post OpenJDK. So, is anyone doing it?
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.
Who knows… is there a properly maintained OpenJDK build for Windows anyone uses though?
Cas
@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.
Cas
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.
What’s the difference? You can ship your own VM on Linux too, and I assume on Mac.
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
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…
@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.