CTO Blog

CTO Blog

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

The Real Java Milestone

Categories : Open SourceTechnology

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

Ron Tolido

Leave a comment

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