Plan B? That is Plan N ... Nothing. Jigsaw follows in 2015.

Markus Eisele
5
what a day. When the typical European is winding down people in the States are starting with coffee. This is why I had a good night sleep over the recent news by Mark Reinhold. In a post titled "Project Jigsaw: Late for the train" he proposes to "defer Project Jigsaw to the next release, Java 9." With the modularization efforts being one of the key topics of Java's future on recent conferences and blog-posts this was a quite surprising move. Yesterday everybody was speculating about if there will be an JSR for Jigsaw or not. Today we know why this didn't happen. And I am disappointed about that. Here is why.

Early notification? No - it's salami slicing! Or? 
My first impression was: Hey, you guys don't get it. Dropping features late in the timeline isn't good for the community. But Donald made me realize that Java 8 is scheduled for May 2013.
That basically means, we are informed 18 months ahead. But you guessed right. The reason for me being disappointed isn't the time. It's about the way the future of Java has been communicated and used for marketing. Bert Ertmann naild it for me with his tweet:

It seems to be a pattern here. Slicing everything until nothing relevant remains. But wait. Haven't we all seen the save harbor slides? Have we been ignoring them? Or aren't we aware of their real importance? Could all this be an agile planning process which simply isn't communicated in the right way? The community as the most important stakeholder (beside Oracle internal interests) obviously wasn't aware of the true reliability of the statements and plans. I have seen that before. And struggled with the same approach. Outlining the planning a bit more or even adding a burn down chart for the progress would be a very helpful instrument for a sneak into what's actually happening with the development. No, I'm not proposing to see all the little numbers, but I would love to have an indicator about stuff that is working like it was planned and stuff that is ... being postponed.

I don't want to miss the chance to say thanks to Donald and Mark and also Dalibor and the many others from the OpenJDK/Oracle team for listening to the community. I am thankful to see them on Twitter, Email, Blogs, Forums and everywhere around to gather feedback and try to work on the way Oracle is communicating proposals and decisions.

The real reasons?
Are there any more reasons behind that than the ones Mark expressed in his blog? "some significant technical challenges remain" and there is "not enough time left for the broad evaluation, review, and feedback which such a profound change to the Platform demands." Following Mark's twitter stream also reveals some more insights here. "Started on a shoestring at Sun, barely survived integration into Oracle, only fully staffed about a year ago …" (@mreinhold) For the external person the news sounded like ... wow that stuff has been started years ago and nobody was actually coding there? With the insights from Mark about I hope he is doing another blog-post about this does actually sound a little different. It might be that the truth is much simpler here. And it also would be good to know what the community can do to help. Mark: Go on! Keep lifting the former secret parts and try to facilitate what  the community has to offer!

Dreams of Java on iOS over?
Do you remember what has been said at last JavaOne? The iOS and Android versions of JavaFX? Mobile goddess is back with Java since Java ME never really lifted up? Awesome. One of the most prominent requirements for that to happen was the ability to repackage the JDK to the right size for the job. Jigsaw was the idea behind that. As of today Mark proposes to introduce "one or more compact Profiles in the Java SE 8 spech http://mail.openjdk.java.net/pipermail/java-se-8-spec-observers/2012-July/000001.html to solve the missing module system. This in fact wouldn't be a "module" system but simply "just different ways to build the JDK, resulting in different-sized JREs." (@mreinhold). Yeah. Ok. And asked for the implications that might have the answer was: "We’ve already been preparing for the complexity of building and testing a modular platform." (@mreinhold) Seems as if the building blocks of that proposal are in place and no additional overhead is needed to get the mobile promises on the road.
So we will not have to fear >100 MB downloads for the JavaFX based apps. I don't know if they will meet the proposed distribution size starting at 10 MB. But anyway I expect it to be at a reasonable size.

We don't need Jigsaw!?
Really? We already have OSGI, JBoss Modules, HK2 Kernel abstraction. A lot of stuff is in place and Jigsaw would only have helped the JDK. Really? I'm looking at it from a slightly different perspective. Even if it is true that a module system would have helped the JDK in the first place, the dependent platform specifications (like Java EE) also are in big need for a module system. And Java simply hasn't anything to over here. At least nothing that is in the reach of the JCP. So, looking for modularization approaches as of today would mean to embrace non JCP technologies. And we all know that this will not happen. So, looking at Java EE 7 and beyond we are quite sure that this proposal is putting a lot of pressure on the internal discussions. Not to forget about the additional years the competitors gain in entering and deciding the field. If you ask me, the worst thing that could happen is that Jigsaw ends up with being used JDK internally only. There is a good chance for exactly that to happen.

What is left of Java 8?
With Jigsaw being stripped of the Java 8 time-frame the most important question here is about the what is left. Even still under the save harbor statements that's basically:
- Project Lambda (JSR 335) will bring closures to the Java programming language.
- New Date/Time API (JSR 310)
- Type Annotations (JSR 308)
- A couple of smaller feature
With the new scope Java 8 will ship on time, around September 2013 according to Mark.

Feeling better now?
I don't know. Even a good night sleep didn't bring back that comfy feeling I had a few days ago talking about modularization with Java. But I think I have to get over it and this is still another one of those "bad-hair" days which don't have a real reason for feeling sad. Seems as if I personally have to look at the alternatives. Waiting until 2015 is not an option. OSGI, JBoss Modules ... Here I come.

Update 20.07.12
Alexis has put up an interesting piece about motivation and the true debacle behind Jigsaw:
As I wrote above, Oracle has the resources to declare Jigsaw a strategic goal. I can agree that it may be hard to deliver by late 2013 but waiting for 2016 is effectively killing Jigsaw and encouraging everyone to look at alternatives which will jeopardize yet even more Jigsaw’s chances of ever seeing the light of day. In fact, even Oracle is considering profiles in Java 8, an ugly band-aid if you ask me. One you’ll need to painfully tear off to get proper modularity in the platform. Jigsaw really shouldn’t be seen as “a new feature”, to me it’s really the Java reboot some people have been calling for a long time. Only a compatible one.

Post a Comment

5Comments

  1. OSGi is (also) standardized by the JCP as JSR 291. Granted, this process was considered by many as "rubber stamping" and not an official JCP creation. However, for now, it is the only JSR with real-world backing for some time to come...

    ReplyDelete
    Replies
    1. Hi Karel,

      That's kind of a glue JSR.
      But you're right. This will be the stuff to look at for the next few years.

      -M

      Delete
  2. Markus, thanks for taking the time to write out all your thoughts, there's some good nuggets in here. FWIW, regarding my '18 month' quoted tweet, that was actually directed to an earlier part in the tweet thread, not at you or your comment.

    Thanks again for this!

    ReplyDelete
  3. Late delivery for a software project!? I guess someone had to ruin this industry's record.

    Just shows that even the the big shops can mis-estimate large and complex tasks.

    ReplyDelete
Post a Comment