Skip to main content

What do you think of Java 7's "Project Jigsaw" plan to modularize the JDK?

I think it's a good idea
71% (418 votes)
I think it's a bad idea
6% (37 votes)
I don't care either way
7% (41 votes)
I'm not sure yet
15% (86 votes)
Something else
1% (5 votes)
Total votes: 587

Comments

Project Jigsaw

I think this is such a good idea for standard modularization system on Java SDK - many things could be done better

Willl JDK parts be versioned ?

Modularization for selective downloads is good, but versioning part of the jdk would be fantastic. Imagine a Swing with painters without worrying about backward compatibility. JavaFX isn't Swing2. Stop that nonsense. We want a Swing 1.1, then a 1.2, then a 1.3....without backward compatibility. Olivier Allouch

Willl JDK parts be versioned ?

> We want a Swing 1.1, then a 1.2, then a 1.3....without backward compatibility. Are you kidding? Remember on the version hell of Java 1.2.x.. The backward compatiblity is one of the best features of Java and Swing. How many Java-Versions do you want to install to run all still existing Java-programs? And with how many Java-Versions do you want to try any Java-program until you have find the right Java for your program?

Willl JDK parts be versioned ?

All I want is 2 incompatible versions of Swing. Note that you already have it. It's called the UI Component of JavaFX (the one we'll see next year, I'm sure), with all the great layout, animations, transitions, painters customization and treetable, and accordions, and... Oups, we already had all this in SwingX and miglayout. Maybe you're right, and the real mistake was that SwingX carried all the Swing burden with it. Hope you enjoy your IE4 and all your no-more-supported applications.

what needs to come from it

What needs to come from modularization is the final solution to permgen leaks (classloader leaks) in containers. I don't know why we still have them, it has something to do with some open source lib we are using, but we can't cut any of them. We would rather allow the JDK to be clean enough to chop the classes off at their tails and be allowed to continue. A modular JDK would also be easier to test. Also I laughed when this was announced because a couple months ago a couple of us at our company created a modularization framework for our code and we called it Jigsaw. The project makes lots of usage of interface based design, and discovery of implementing classes, and generating GUIs displaying configuration options to users based on what is available in the classpath.

what needs to come from it

modularisation won't do what you want. Permgen leaks are almost universally called by calling String.intern() excessively, the use of which is almost always a design or implementation flaw in copying or cloning operations.

Project Jigsaw

When Jigsaw was first announced I thought it was a good idea. As the dust has settled, I've changed my mind. I like that Sun is pushing modularization but there are also a few things I dislike. I don't like that Jigsaw is an extension that is proprietary to the Sun JDK. I don't like that Sun is making this extension available to developers and apparently encouraging its use. This breaks the WORA principle of Java because again, this is proprietary to the Sun JDK. JSR 294 doesn't make any sense at all now. It's going to extend the Java language to facilitate modularization yet JavaSE doesn't have a standard modularization system. Can we get some clarification on this?

Project Jigsaw

quite apart from that (which I don't mind all that much as the Sun JVM is thee de facto standard all others (should) comply with), it will introduce a whole new level of DLL hell.

Imagine a dozen applications on your machine, all using the same JVM, but each requiring a different subset of different versions of the modularised core libraries.

You'll no longer be able to rely on anything being available on a user's system, which is especially worrying when that machine is situated byhind a strict firewall that doesn't allow for downloading of components you need (which is the reality for a large portion of the professional developers creating Java software for use in companies and government departments).

Instead of just telling the sysadmins that JVM version X or better is required (which they can easily provide for, after several months of testing to ensure it is "safe" for use on the network), you'll have to provide a comprehensive list of which subversions of which jars of the modular system are required, each requiring that testing cycle. Before you know it those sysadmins will decry they'll no longer approve any Java software for deployment because the process is impossible.

It's happened in the past when even the need to have a JVM at all was seen as an insurmountable obstacle by sysadmins. They've gotten over that, don't bring it back now.

And then there are the people who don't have uninterrupted internet connections at all, relying on slow modem connections. A modular JVM that downloads (or tries to) libraries on the fly as needed will cause those people lots of headaches, and may not work at all if they have to rely on physical media for software distribution.

Project Jigsaw

Don't you already need many external libraries at a certain version ? On my main project, I use between 15 and 20 libraries, each having a specific version. And when they don't want to bother about backward compatibility, they give a version less than 1 (like 0.9.6), but tell, at the same time "ready for production". But I understand the initial fear of having many version of the same library on your hard drive. Olivier Allouch

Project Jigsaw

External libraries I can control and ship with my product, core operating system libraries (which core JVM components effectively are) I have no (or far less) control over.

And it's not just ending up with many versions of those libraries on your system (I hope the JVM will keep track of them and give me the one I need), but having to have an active internet connection whenever a Java application is being run just in case at some point during program execution my program (or some internal or external library it depends on) calls a class that's in a core library that's not yet available and thus needs to be downloaded on the fly. That not just slows your software down (though less and less as the application is run more often) but fails (causing things like "NoClassDefFoundErrors") when there's no internet connection (which is a common things in many places (third world, remote locations, laptops, handheld devices, just to name some scenarios). The alternative is to ship a complete JVM with every library in the correct version that might be needed with every application, and for every conceivable operating system. And I thought this was intended to make deployments easier and smaler?

Project Jigsaw

Indeed, there seems to be some declaration overhead. In our (the library users) side, we may need to declare somewhere "I need this library with this version", so that it gets downloaded at first run. And at the library's side, they may need to declare "OK, this release is backward compatible with those and those versions". The first time I used Subversion in NetBeans, I had to download it (press OK in a dialog). But I'm a coder. My fear is the way Sun is used to interface with the user (the tray icon, the Yahoo Toolbar in the installer or the Java logo everywhere). I agree this is tricky. Olivier Allouch