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:
Plan B was promised for fall ’12. Then became fall ’13 and now one of its key features becomes fall ’15. Boy, what a mess! #jigsaw
— Bert Ertman (@BertErtman) July 17, 2012
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.
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.”
Reference: Plan B? That is Plan N … Nothing. Jigsaw follows in 2015 from our JCG partner Markus Eisele at the Enterprise Software Development with Java blog.
Bulletproof Java Code: A Practical Strategy for Developing Functional, Reliable, and Secure Java Code
Use Java? If you do, you know that Java software can be used to drive application logic of Web services or Web applications. Perhaps you use it for desktop applications? Or, embedded devices? Whatever your use of Java code, functional errors are the enemy!
To combat this enemy, your team might already perform functional testing. Even so, you're taking significant risks if you have not yet implemented a comprehensive team-wide quality management strategy. Such a strategy alleviates reliability, security, and performance problems to ensure that your code is free of functionality errors.Read this article to learn about this simple four-step strategy that is proven to make Java code more reliable, more secure, and easier to maintain.