Thursday, September 9, 2010

JDK 7 Delayed Again

Did I get a laugh out of Mark Reinhold's announcement that Java 7 is further delayed? No, I did not; it actually made me rather sad. Java 7 contains a lot of improvements and my life would be simpler if I had those improvements available. Java is still a tremendous platform but we're losing our advantage over other platforms and the main reason is lack of a modularity.

Java is slowly being broken by the misconception that the bigger the Java platform the better it becomes. However, bigger means more internal dependencies and these dependencies tend to increase the complexity of a platform quickly. The more rope you have, the more tangled it can get. Repeatedly slipping schedules are one of the symptoms. In the nineties I've seen Ericsson waste staggering amounts of money to create a telecom application platform only to finally succumb to defeat. The simple fact is that developer needs are way too diverse to ever be captured by a single platform. Platforms that still try to satisfy these diverse needs always get torn between features and bloat. When I explained how I loved Java to my fellow Smalltalker Ralph Johnson (around '97) because it was so small, this wise man said: "Just wait." He was right. Worse, though the Java platform obtained the kitchen sink but still always requires me to include external libraries anyway.

Modularity is the only mechanism that allows us to have our cake and eat it too. If Java consisted of a core Java platform we could easily include the JSR implementations as separate modules. I never use Swing , so why does my platform have it? And maybe I need it in another version if I use it. Modularizing the JSRs would maybe complicate the life of trivial applications but for any real application handling external dependencies is already part of their complicated life. Complicated because surprisingly Java provides no support whatsoever for handling these dependencies.

Neither JSR 277, JSR 294, Jigsaw, nor Qwylt was a proper solution for handling external dependencies. Jigsaw was too simplistic for large applications and Qwylt and JSR 294 would have given us the headache of handling multiple module systems on your compiler module path. Both would have caused a packaging nightmare due to the combinatorial explosion of module system x operating system variations.

What we need is a core platform that is minimal but understands true modularity. Instead of including all these javax packages, this minimal Java should only include well defined core packages and also a mechanism to properly handle modules from (remote) repositories that make it trivial to add libraries and applications to my desktop machine and servers. Perl can do it, Ruby can do it, Python can do it, why does Java have such a hard time doing the same thing? Or live up to its promise and do it better?

Oracle should focus their Java effort in shrinking the platform and modularizing anything that is not used by most applications. Depending on the functionality of those modules, many of them can actually be compiled for 1.4 VMs (with generics), Java 5 or Java 6, making them available today and not until 2013 or even later. This decouples the life cycle of the components from the life cycle of the platform, which can never be faster than the slowest constituent component.

We do have the technology, all the parts are there. Please Oracle, this delay provides an opportunity, can we make Java agile again?

Peter Kriens

2 comments:

  1. Peter,

    I agree completely with you on this. I have been banging on about this to anyone who will listen for years.

    It sounds like Sun/Oracle are making moves in the right direction with the Java Kernel Installation (recognising you have a problem is the first step to recovery).

    See: http://www.oracle.com/technetwork/java/javase/kernel-135055.html

    Keep the pressure up! OSGi is the best answer we have to Java platform bloat.

    - Chris

    ReplyDelete
  2. I think we should also use this as a chance to simplify the usage of OSGi. For example I very much like the ease of use of services introduced by the Eclipse e4 project. A simple @Inject ServiceInterface is sufficiant to get a service injected.

    To see an example http://www.vogella.de/articles/EclipseE4/article.html

    ReplyDelete