Computerworld - You'd have to be living in a vacuum not to be aware of the debate that rages between proponents of the two dominant development platform contenders: Java 2 Enterprise Edition and .Net. Many articles have been written declaring one or the other the winner based upon performance, scalability, features, portability, vendor independence, ease of use, lines of code, robust security, productivity tools and enterprise connectivity, just to name a few of the hot issues.
The tale of the tape is long and confusing, but does it really get at the heart of the issue?
You Say Potato, I Say ...
Much of the debate has sought to differentiate the two in order to convince customers that one is the clear and obvious choice. The most obvious conclusion seems to be that the architects are most skilled at conceptually copying and enhancing the best of one another's platforms. As a result, J2EE and the .Net Framework are far more similar than many people realize and will probably become even more so in the future.
Sun Microsystems started things off when it made the Java language syntactically similar to C/C++, but improved it by making it object-oriented from the ground up, by adding its own features and by employing common design patterns in the Java Development Kit (JDK).
Not to be outdone, Microsoft made its own improvements with .Net and the Common Language Runtime to enable code that's written in many languages but deploys as if written in one. Microsoft embraced object-oriented programming instead of using a pseudo-object-oriented notation. Its most important language, C#, is amazingly similar to Java, and the .Net Framework employs many of the same design patterns embraced in the JDK.
The Stacks and Just the Stacks, Ma'am
We can look at each as a "stack" of common services that each platform provides to applications that are built with or run on the platform. There are plenty of articles out there comparing and contrasting the stacks of .Net and J2EE. Here's a list—not necessarily an exhaustive one—that begins to make the point that these technologies are growing together conceptually and support a similar set of services, albeit implemented differently.
|
It's getting harder, not easier, to pick a clear winner, because J2EE and .Net are so similar. Consider the cola wars—Coke or Pepsi. As fundamental products, they're not that different. Both are colas, with carbonation, caffeine and celebrity endorsements.
With J2EE and .Net, selection may be based less upon intrinsic merits of the platforms and more on your existing environment (e.g. resources, investments) and personal preference or style.
Don't blame Sun or Microsoft—they are companies in a free-enterprise system. They want market share and need to provide their shareholders with a return on their investment, but there's no need to get caught up in the hype or allow these superficial debates to cloud your judgment on the more important issues that we all face.
At this point, many of you are probably asking yourself, "If my selection of J2EE or .Net isn't as critical as I thought, what is?"
From the Victrola to the MP3
Replacing your favorite music every time the industry changes formats is one thing, but can your company really afford to rewrite every application each time technology changes? J2EE and .Net are hot right now, but they will eventually be replaced by the platform du jour. It's not "if," it's when. The only real question is whether it will have already emerged by the time this article is published.
Free Insider Guide