Skip to main content

Poll Result: Mixed Views on Project Jigsaw Removal from Java 8

Posted by editor on August 11, 2012 at 7:25 PM PDT

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.

For example, 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..."

dutchiedave noted, "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."

Meanwhile, 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."

But marrs didn't stop there, offering Oracle two interesting counter-proposals to continuing a massive Project Jigsaw effort with much delayed delivery:

  1. 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).
  2. 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)?


Java.net Weblogs

Since my last blog post, several people have posted interesting new java.net blogs:


Java News

Here are the stories we've recently featured in our Java news section:


Spotlights

Our latest Java.net Spotlight is James Sugrue's Have Your Say on Java 8 Default Methods Syntax:

Brian Goetz has just published a one question survey where you can indicate your preference on the syntax to be used for default methods in Java 8. Default methods will be used to allow an interface method to provide an implementation used as default in the event that no concrete class provides an implementation for that method. The choice presented is fairly subtle...

Prior to that, we featured Markus Eisele's The Heroes of Java: Çağatay Çivici:

Staying strong, the "Heroes of Java" series reaches the 18th edition. This time it is about Çağatay Çivici who is the inventor and lead developer of my favorite JSF component library Primefaces, a member of JavaServer Faces Expert Group, and PMC member of open source JSF implementation Apache MyFaces...


Subscriptions and Archives: You can subscribe to this blog using the java.net Editor's Blog Feed. You can also subscribe to the Java Today RSS feed and the java.net blogs feed. You can find historical archives of what has appeared the front page of Java.net in the java.net home page archive.

-- Kevin Farnham

Twitter: @kevin_farnham

Related Topics >>