Poll Result: Mixed Views on Project Jigsaw Removal from Java 8
Developers expressed disappointment regarding the proposed removal of Project Jigsaw from Java 8 in the most recently completed Java.net poll, and had mixed views on whether Java 8 should proceed without it. A total of 445 votes were cast, and four people posted comments. The exact poll question and results were:
What's your view of the proposed removal of Project Jigsaw from Java 8?
- 23% (103 votes) - It's a good decision: the most important thing is to deliver Java 8 on schedule
- 29% (131 votes) - Java 8 without Project Jigsaw is pretty useless; Java 8 should be delayed until Jigsaw can be included
- 20% (87 votes) - Project Jigsaw is so late it's becoming irrelevant; developers should just use other modularity technologies like OSGi
- 12% (53 votes) - I don't know
- 16% (71 votes) - Other
The posted comments were effective elaborations on the poll options.
rdohna commented: "I'm quite undecided... Java 8 has a lot of cool features (mainly Closures) that are well worth getting out of the door as soon as possible. But still it's a pity that Jigsaw won't make it on time..."
dutchiedavenoted, "It is essential to modulize the jre as soon as possible because it makes all future code added to the jre more efficient. Modulizing the jre will massively decrease loading time and memory use for the majority of java applications, everyone should be pushing for Jigsaw as soon as possible."
marrs said, "Project Jigsaw was already too late when it started, and having it part of Java 9 means that only developers that can actually use this version can take advantage of it. That means adoption will take a long time. OSGi is here, it is proven technology and it works on any JVM out there."
marrs didn't stop there, offering Oracle two interesting counter-proposals to continuing a massive Project Jigsaw effort with much delayed delivery:
- Modularizing the class libraries. This is not that difficult at all. Apache Harmony basically already did it for them. The benefit of modularizing these is that you can choose to not even deploy the parts you are never going to use and, maybe even more importantly, you can choose different implementations of the same module (more focussed for example on embedded or server usage).
- Implementing "Isolates". This is also something that was already done years ago in the Sun Labs, even though it never made it to the main stream JVM. Isolates allows you to manage modules better, forcefully stopping them or limiting their resources.
The lack of modularization in Java is indeed almost surprising, when you consider languages like C and C++ that were mainstream when Java came into existence, and languages like Python that became mainstream later. For so many modern languages, either it's easy to make a very small, fast-loading executable; or your application can be constructed such that it loads only the language modules/libraries that it actually uses. Even though Java started out much smaller than it became over many years of enhancement, that modularization would be beneficial was always a fact. For example, recall the typical PC on an office worker's desk, or in people's homes, in the late 1990s. There wasn't much power or memory there; so, a modularized Java would have been useful even during Java's early days. Undoubtedly, at the time, other Java platform objectives seemed more critical. For example, Java was increasingly being used for server side programming in those days, making EJBs, containers, and application servers of critical interest...
I suppose you could call the division into Java EE, Java SE, and Java ME a form of "modularization"; but, then again, this really isn't modularization. And clearly the EE/SE/ME division doesn't address all of today's needs.
New poll: Timed Java release schedule, or not?
Our new Java.net poll generalizes the discussion into whether or not new Java releases should come out on a timed schedule. At last year's JavaOne, Oracle announced that this in fact would happen going forward. Specifically, the poll asks Should Java have a timed release schedule (for example, a new major release every 18 months)?
- Rex Young, FastMessenger makes coding concurrent sub tasks in a main task a breeze;
- Juliano Viana, Samplr: embedding the power of Visual VM in your application;
- Larry Fernandez, Creating the Transaction Monitor - it's all about the message; and
- Gabriele Carcassi, Building in the cloud.
Here are the stories we've recently featured in our Java news section:
- Tim O'Brien describes Best Strategy for Migrating from Apache Ant to Apache Maven;
- Emad Benjamin examines 3 Key Trends in Middleware Virtualization;
- Partha Bhattacharjee demonstrates Spring Integration with Gateways;
- Henrik Stahl announces Java 6 End of Public Updates extended to February 2013;
- Chris Mayer continues Talking Java with Gil Tene, Azul Systems;
- Dustin Marx presents A Slicker Typesafe Stack: Q&A with Martin Odersky;
- Roger Brinkley presents Java Spotlight Episode 94: Kirk Pepperdine on Java Performance Tuning;
- Micha Kops demonstrates Creating a Windows Executable from a Jar using Maven;
- Andreas Grabner continues Top Performance Mistakes when moving from Test to Production: Deployment Mistakes;
- Chris Mayer presents Talking Garbage Collection with Gil Tene, Azul Systems;
- Axel Fontaine presents Optional Dependency Strategies for Java Libraries;
- Ben Wootton highlights How Maven Enforces Good Habits:;
- Johannes Th
Related Topics >>