J2EE or .Net? It's a question that seems to scream from the cover of every trade magazine and conference brochure. Sun's Java 2 Enterprise Edition (J2EE) and Microsoft's next-generation .Net framework are widely regarded as the future of enterprise application development.
Together, these two platforms represent a shift away from the traditional, centralized application development model to one that emphasizes distributed, network-centric applications based on XML. This evolution is particularly significant for larger enterprises, which are often faced with the challenge of integrating a variety of disparate applications and legacy systems.
While industry debate about the relative merits of J2EE versus .Net has at times taken on the tenor of a holy war, the argument over which technology will triumph is largely moot. The .Net developer strategy is remarkably similar to Sun's Java strategy in many ways. Each has merits, and their common goal is a laudable one. There's no real reason why either platform should emerge as the sole victor; in fact, many organizations will ultimately use both. A survey of six hundred developers conducted in October by Santa Cruz-based Evans Data reported that 61 percent of developers would target .Net in 2003, while 63 percent would code for J2EE.
Though a migration to one or both of these platforms may seem inevitable, it should still raise some concerns. A technology shift of the magnitude of a move to either J2EE or .Net calls for careful consideration and planning, and the tendency of Java or Windows platform loyalists to "leap before they look" should raise a red flag for any conscientious IT manager.
Name Your Terms
The underlying ideas behind both J2EE and .Net are fairly straightforward. Often, it's not the technologies that confound technology managers when they evaluate these new platforms, but the respective vendors' marketing campaigns. Microsoft's .Net, in particular, has always had something of an image problem: Exactly what is it, anyway? Is it network-delivered, subscription-based software? Is it Web services? Or just another application for XML?
Adding to the confusion, Microsoft announced a host of new .Net-branded products since it first publicized the strategy in 2000. Some of these, such as Windows .Net Server, have yet to arrive (as of this writing). Others, like the proposed Office.Net, seem to have a tenuous relationship to the underlying development platform at best. (In fact, as this issue goes to press, Microsoft has announced that it will be removing the .Net brand from several of its products, to avoid confusion.)
Sun's J2EE branding is similarly murky. Older APIs like servlets and JSP are now grouped under the J2EE specification umbrella, even though they predate J2EE as a whole. But many third-party products offer servlet containers or JSP engines without supporting some other J2EE concepts, like Enterprise JavaBeans (EJBs).
Does this mean that any tool that supports servlets and JSP is a J2EE environment? According to Sun, the answer is no. Sun requires that any product to be marketed as a J2EE solution must first pass its elaborate (and costly) certification process. As a result, open source implementations like JBoss (www.jboss.org) and Enhydra (www.enhydra.org) typically lack the budget for J2EE certification, despite full support for EJBs and other core J2EE technologies.
In the end, the actual extent to which Microsoft's and Sun's most cutting-edge technologies are deployed in real-world applications is difficult to gauge. According to Evans Data, only 40 percent of developers surveyed were working on the .Net platform in October 2002, and less than half were working with Web services of any kind. Given the onslaught of marketing associated with both .Net and J2EE, separating the reality from the hype should remain foremost in the mind of any technology manager evaluating these products.
Too Many Tools?
For the moment, let's forget about which Microsoft software has or hasn't been branded ".Net," and concentrate solely on the .Net framework itself. The portion of the platform that concerns developers consists of several main components. One is the Common Language Runtime (CLR), an environment that compiles and runs intermediate byte code on the fly, similar to Sun's Java Virtual Machine (JVM). There are also new class libraries and APIs like ADO.Net and ASP.Net, as well as Visual Studio .Net (VS.Net), the primary development tool for the platform.
There can be little doubt that, eventually, nearly every Windows programmer will write applications using some portion of the .Net framework. When Microsoft announces a strategy shift of this significance, developers have little choice but to come along for the ride. Still, the learning curve could be daunting; enough so that your organization may want to wait a while before discarding older development methods completely.
Java reinforces its development model by demanding adherence to a strict syntax and clearly defined code security guidelines. But when Microsoft designed its CLR environment, it wanted to give developers more flexibility. Unlike the JVM, the CLR lets developers write to the .Net framework using a variety of languages. The "preferred" language is C#, a sophisticated successor to Microsoft's Visual C++, but there are several others, including C++ and even Microsoft's own approximation of the Java syntax, called J#.
Microsoft also allows programmers to designate portions of their C# as "unsafe." While Java insists on a strictly defined security model in which the virtual machine controls all system resources, unsafe CLR code has access to low-level memory manipulation features that closely resemble C's pointers. (See "Unsafe At Any Speed," August 2002, for more information.)
The downside of all this flexibility is that it makes it easier for .Net developers to learn bad programming habits that traditional Windows developers haven't had to confront. While it may be tempting to let individual coders write for .Net in the language of their choice, failing to standardize on a single language can lead to code maintenance nightmares. It shouldn't take long for experienced C++ developers to get up to speed with C#, but you'll want to build some additional time into your project to accommodate the transition.
The concepts of frameworks and the managed code model may also be new ones to developers accustomed to traditional executables, DLLs, and ActiveX controls. Unless a .Net migration project is carefully managed, the temptation for developers to fall back on old ideas and training can be strong, and there is little in the design of the platform itself to discourage them from doing so.
