I’m more interested in the lambdas than I am in Jigsaw but still not great news. I also wish they’d be a bit more aggressive with their release cycle and be less afraid to push things out when they are ready and not wait 2 years.
Oh no… but what about that beta version of Java 8 that had a functional version of jigsaw? What’s their excuse for making them take this long?
In the article he doesn’t give a specific reason for the delay, only saying that a change of this magnitude needs more time.
Presumably there were issues with the preview of jigsaw. I have no problems with them pushing it back as long as lambdas and extension methods are a go.
The longer they wait, the less relevant it becomes.
In 2015 we’ll have digital photos the size of the JDK.
Very true. What was once a major issue is already irrelevant. What’s relevant now is what’s happening to OpenJDK on MacOS. Funny how the world turns.
Big Java’s changes are almost always too little too late, however I’d say its a good move to push Jigsaw back until its mature as it is a massive change with long ranging consequences for the platform, so best its designed and done correctly rather than something that is rushed out.
It’s a bummer in so far as Jigsaw seems to be related to their future iOS JVM version. They demonstrated JavaFX on an iPad at last years Java One in SF. Oh well…
Note that runtime size is only one of the points mentioned in that rather excellent article. Jigsaw brings far more important things to the table, such as making the classpath obsolete.
I’m not too knowledgeable about modular programming, but does mean that the java library would be split into essentially mix and match pieces?
Isn’t it already like that?
No, the JDK is one big mother that keeps on growing too
And yes, that is what it would mean. I see it more that you get a sort of super libraries composed of several smaller ones, each within their own private breathing space. You could have a module with library version 1.0 and a module with library version 2.0 and use both modules in the same application without library conflicts. Enterprise systems such as JBoss already have such a module system by making very precise use of the classloader system, but the “jar hell” remains regardless.
Ok, thanks for the clarification jonjava.
Also be interesting to see AWT/Swing moved into a separate module where those libraries will be left to die with a JavaFX module to replace it.
Could be interesting for third party libraries too who would just provide something like a SWT or LWJGL module.
Indeed, although modules tend to linger where they shouldn’t because to get such a system to work you still create dependencies which can turn into legacy dependencies. Even younger platforms such as Ruby suffer from it.
Another really interesting aspects of Project Jigsaw is the many optimisations it’ll enable as discussed in this video, which if implemented can potentially provide 60% faster startup time.
sorry. was using an ipod touch
You know this keeps echoing in my brain because I can’t really place why you make this particular comment. What IS happening to OpenJDK on the Mac? Is there anything I missed or are you referring to the fact that OpenJDK has in fact landed on the Mac now (albeit 64 bits only for some reason)?
Aside: I can’t think of any reason to want a 32-bit version.