The Real Java Milestone

I honestly don’t know what to think of it. Sun finally released its Java base code to the open source community. According to Sun’s Executive VP Rich Green this signifies nothing less than a ‘milestone for the whole industry’. That’s definitely one way to put it. Others might add that it is also confirming something we already knew for some time: there is simply no way you can make money with developing and maintaining a programming language.
Anyway. So it’s a milestone. I guess that fits seamlessly in the huge pile of remarkable moments that we have shared with Java in the past ten years or so.
It’s just that I’m still hesitating to determine what exactly are the most impressive milestones.
Maybe it is the appearance of the first applets: these miserable pieces of code that took far too long to load in your browser and then treated you to mannered animations or a laughable attempt to make something resemble like an input dialog. With the advent of applets, the still young principles behind the lightweight browser lost their innocence for good. And judging by the screaming cacophony of non-standardised, yet very arty ‘plug-in’ user-interfaces in the browser of 2006 (thanks to all the enthusiastic followers that brought us ActiveX and Flash), this historic Java moment still echoes every day.


Or wait, was it the breakthrough of object-orientation? With Java becoming popular, everybody really dedicated themselves to inheritance, dynamic polymorphism and other er, complexity reduction concepts. One of the most uplifting achievements of object-orientation is the almost perfect incompatibility with the principles behind relational database systems. That has lead to a sheer number of awkward and sometimes also brilliant solutions in the form of object-to-relational mappers. Solutions to a problem that we introduced to the profession ourselves without even blinking an eye.
Forcing a big pumpkin into a narrow, metal cube and then be proud of it: it can only happen in IT.
But let’s be honest: the most memorable milestone must have been that almost indefinable moment in which Java (and right afterward its Microsoft baby-sister C#, give credit where credit is due) became the rightful successor to the 4GL programming languages of the nineties. Think about it: we just had found ways to use simple, highly productive languages to develop powerful systems that were close to user interfaces, databases and the business. And then we voluntarily threw ourselves back to the Spartan scenes of more than a generation ago: an almost pre-3GL world in which over-engineering and traditional coding from the command line (real men indeed!) were once again the cultural standard.
Would Java been as popular if it would have kept its original name ‘OAK’? Better not think about that too long.
In all fairness, Java is a well-structured, clearly defined programming language that leaves relatively little room for security breaches and memory leaks. Also, there is a huge amount of well-optimised application servers that can run Java code quickly, efficiently and platform-independent. So the challenge really, is to ensure a higher productivity in coding Java solutions. And there is only one way to achieve that: avoid coding Java. Dedicate an inconvenient amount of time to finding and establishing frameworks – there’s abundance in open source – so that building solutions merely consists of filling in the parts that are not yet complete finished. Furthermore: definitely, seriously consider model driven development. If what we see in practice is really persistent, than it is becoming more realistic than ever to generate the bulk of Java code from – graphical and non-graphical – business models. And on the horizon, we already see the dawn of Domain Specific Languages: languages that are specifically designed to define solutions for a certain domain, rather than being general purpose. It means that through very powerful, targeted language constructs you only use a bare minimum of wording to even design the most complex system. And just before completion, you may want to have that code generated. A detail, really.
It bring us right back, through a confusing stopover, to where we once were moving towards with 4GL’s. And it is time to make next steps.
Will that be the real milestone, the day that we don’t code Java anymore?

About the author

 The Real Java Milestone Vice-president and Chief Technology Officer of Applications Continental Europe, Capgemini. Director, The Open Group. Blogger for Capgemini’s CTO blog and SlowPlanet, the international hub of the Slow Movement. Lead author of Capgemini’s TechnoVision. Speaks and writes about IT strategy, innovation, applications and architecture (and anything else, if he is asked to). Based in the Netherlands, Mr. Tolido currently takes interest in topics such as application rationalization, cloud, BPM and simplicity.




This entry was posted in Open Source, Technology. Bookmark the permalink.

5 Responses to The Real Java Milestone

  • LAB says:

    A little bileblog’ish post (http://www.jroller.com/page/fate), and a good one ;) I think it pin points the major java problem; productivity. But, MDM is often mentioned as a silver bullet concerning productivity, my experience though is that one suffers under the 80/20 rule much too often. That is; the mdm-toolkit often just solves 80 percent of the “problems” and the remaining 20 percent you must figure out how to solve yourself. And because youre stuck with the mdm-tool in the first place it’s a little like puzzling a puzzle where 80 percent of the pieces fit just fine but you have to carve out the remaining parts. It’s also a worth while experience to examine code generated by these mdm-tools. I once bumped into a generated Java Swing class file containing over 50000 lines of code… That can’t be a good thing by any measure relevant for good code practice ;)

  • JWO says:

    It’s hardly fair to blame Java for the demise of the 4GLs. Most of them have became irrelevant because they just couldn’t keep up with the major paradigm shifts in the nineties (procedural -> OO, monolithic -> C/S -> distributed, etc.)
    As for MDA, I think this article pretty much sums it up:
    http://www.martinfowler.com/ieeeSoftware/mda-thomas.pdf
    Personally, I don’t see any Silver Bullets ™ on the horizon at the moment. Just more of the same bullets we’ve been shooting ourselves in the foot with over the past few decades :-D

  • Ron Tolido says:

    @JWO: then again, maybe we made 4GL’s ‘irrelevant’ ourselves, introducing paradigm shifts (like OO) that were completely incompatible with earlier paradigms. The link to Martin Fowler’s article is a good one! And please note his current interest for domain specific languages, clearly moving one step further to a rich, powerful notation that may not be a Silver Bullet but certainly will bring back some much needed productivity. I wonder what the first, new domain specific languages will look like. Like 4GL’s…?

  • JWO says:

    By the way, here is an interesting analysis of Java’s future as a platform:
    http://www.davidchappell.com/HTML_email/Opinari_No17_10_06.html
    Enjoy!

  • Torun says:

    “Forcing a big pumpkin into a narrow, metal cube and then be proud of it: it can only happen in IT”.
    Well, if you do it the other way around, it’s called giving birth…

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>