J2EE Platform Independence: Have We Regressed?

Once upon a time there was a dream. The dream was of creating cross platform products. Ones that transcended the boundaries imposed upon us by entities known as Intel or DEC or even Silicon Graphics. From that dream, two technologies were inevitably born: those of Java and CORBA.

Once upon a time there was a dream. The dream was of creating cross platform products. Ones that transcended the boundaries imposed upon us by entities known as Intel or DEC or even Silicon Graphics. From that dream, two technologies were inevitably born: those of Java and CORBA.

CORBA was the first. The idea was to make languages and platforms irrelevant. To realize the potential of building enterprise wide, heterogeneous systems that are not dependent upon any one specific vendor. Out the door it wasn't perfect, but it was a step in the right direction and for this reason, perfection was something that could be attained through greater effort. Microsoft tried to copy it with DCOM but the inevitable march of the cross platform movement first weakened and then brought down the giant. On one knee, he proclaimed that he would cooperate with a bridge between DCOM and CORBA; however, CORBA wasn't the end of the story: far from it indeed.

Java took over where CORBA left off, though not sequentially of course. Sun had the vision to write a cross platform language and distribute it free of charge to anyone and everyone from student to corporate developer. Initially, Java displayed the same halting baby steps that CORBA did, but like all children of good parentage, it grew and matured. Now, for the first time in computing history, we have a truly ubiquitous cross platform method of building applications. With the introduction of Swing and the Java Foundation classes, we blossomed into a true revolution in software engineering. C++ still had its place, but anyone who wanted to produce world-class programs had Java on their lips. Java was where the jobs were, and still are.

Java had initially competed with CORBA using RMI. RMI was shallower and not as useful as CORBA. RMI restricted a program to Java, in stark contrast to the tide of the revolution. Although Java was a great technology, it couldn't counter the billions, perhaps trillions of dollars of investment in non-Java software. RMI, clearly, wasn't the way out. Then came marriage.

With the union of Java and CORBA, the world took on a whole new light. Cross platform, vendor independent solutions sprang into being and the promise of Object Oriented Engineering started to be realized and even extended. One of the most important extensions was EJB.

EJB was almost immediately recognized as a powerhouse of software engineering. Now we had a truly global, federatable, and powerful solution to common computing problems. However, this is where the story turns ugly.

Recently we have seen a regression back to our old platform war days. However, this time the platform wars are among EJB platforms. Further, we see a regression in programmer thinking. So where did the dream turn into a nightmare?

In the last two years, the EJB market has flourished. The application server vendors rush to keep up with the changing specification and ever more imposing demands of its users. At the same time, there seems to be a post-Microsoftian psychology that has gripped the tool vendors. Application server vendors are now inevitably packaging their application servers with a proprietary IDE. At an alarming rate, in fact, these IDEs are becoming so tightly woven to the application server product that it is difficult to separate them. The effects are easily perceptible and completely devastating.

Currently, if you take a look at the market, you will see BEA with Visual Cafe, Web Sphere with Visual Age for Java, and Borland Enterprise Server with JBuilder. This would not be so bad if it weren't for the powerful forces that these integrations have been applying to the market. Now if you aren't using the development IDE of the company, you get strange looks from support personnel of that company when you call about their application server. The number of support personnel issuing comments like "if you would only use our IDE" is frankly disturbing. Add to that a constant wave of bombarding propaganda from the marketing departments to go with a fully "integrated" solution and the situation becomes critical. We are being pushed out of our independent development tools and funnelled down cattle shoots. Would you like number one, two or three? Even worse, all of us console, vi and emacs 'freaks' are left out in the cold.

It's actually a historical irony that no one has, as of yet, come up with an editor better for programmers than emacs or vi. Over thirty years old and both of them are still the co-kings of the text-processing heap. Sure, the two camps razz each other and tout the advances of the other. However, one thing we can agree on is that the multi-thousand dollar software sitting on our desk is a child when it comes to power editing. Some of them barely have the ability to find a matching brace and none of them have the power to do regular expression search and replace. The irony really hits home when one considers that not one major tool vendor has ever had the fleeting idea of integrating vi and emacs emulation into their product. A feature that would, undoubtedly, be a huge bonus to their offering is strangely absent. Not JBuilder or Cafe or Visual Age has done it. For the first time in history, the vi and emacs camps are being driven out into the cold.

Another thing the integration has accomplished is the instillment of laziness in coders . We sit and open our graphical GUI editor, draw some things on the screen and hit "generate." We don't even know what is happening in our GUI code and we don't even bother to proofread the code being spewed out. Senior programmers of the old school look at this generated code and have to swallow to keep from retching. The current debate around the issue centers on just exactly what hallucinogenic drug that the ex-MFC coders were taking when they designed the GUI builders of today. The LSD argument seems to be winning with PCP running a close second. What is worse is that the new junior developers are forgetting how to use a layout or catch a mouse event or even effectively handle model-view-controller separation. "Why bother when you have [insert your GUI builder product here]?" is the current lame expression among the new and uninitiated. Elegant code and efficiency are being given a kick in the teeth.

The kick reaches astounding proportions when we consider web development. We now have web developers that couldn't understand the raw code with a road map and two hunting dogs. To put up a shopping cart, they buy thousands of dollars in expensive software. One is forced to wonder if these same developers contemplate using nuclear weapons to kill that pesky fly in their apartments. The object-oriented line of "Why develop if you can buy it?" has been horribly perverted. It was never meant to make people throw 50 times the resources that they need towards a project. Application servers are the gods of n-tier computing. As a web platform the word "overkill" leaps to mind.

However, the worst thing about the integration is the push back into camps. There is a Borland camp and an IBM camp and a BEA one. We seem to have forgotten that the whole dream was about integrating multiple platforms. We seem to have forgotten that what pushed us into Java and CORBA in the first place was the need to escape from dependencies on single vendors. As developers, we want to mix and match the tools. We choose the best IDE and the best UML tool and the best language and roll them into a smoothly functioning development environment attuned to our needs. However, these companies have now come knocking at our doors with cheese in hand, willing us to walk into the trap.

In an alarming quantity, developers are taking the bait and realizing it only when the door is slammed shut, the cheese is found to be moldy, and the salesman is walking off laughing at the tens of thousands he just milked us for. If our one platform solution doesn't work, we can no longer toss out one piece and exchange it. We are stuck with the one product solution. The real question is, when are we going to wake up and slam the door in the face of the salesman and demand they give us what WE want for a change?

What we want as programmers of the industry is for product makers to stop trying to pigeon hole us into this or that platform. Let us mix and match. If we like your application server but not your IDE, roll with it. Sell us the application server and not the IDE. Let us build our own solutions according to our needs and not according to yours. Allow us to decide on the tools for our departments. If we don't buy your IDE, take a look at the one we do buy and try to figure out why we bought it instead. Are the editors better? Are there more tools? Is round trip engineering better? If we don't buy your application server, consider its features, stability, scalability and ease of use.

If we as an industry continue to let the tool vendors govern us, we are destined for failure. Tool vendors are already increasingly realizing that they have us stuck, that they can charge ridiculous amounts of money for support and put out shoddy products and defective releases and there isn't a thing we can do about it.Just to get a working product, we fork over thousands of dollars. Would you have really bought that application server if they had quoted you four times the price for the working model as opposed to the defective one? They also realize that we wont find their documentation to be faulty until we get into their product and are already stuck. Similarly, the other "features" of their products will take time to rear their ugly heads. On our limited time scales, we jump for their solution and, about two weeks before release, we are snapped back into the grim reality that we have been sold yet another lemon.

Its time for a change. Its time to get the train back on track.

Dig Deeper on JSRs and APIs

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.