J2EE vs .NET: Developers, Microsoft and platform choices
Developers take up the reins
And jockey they have. Yet while Sun and Microsoft have been fiercely contrasting their two offerings, they have yet to offer compelling evidence that will, on its own, push executives to support one model over the other.
After all, both .NET and J2EE ultimately provide a standards-based architecture for deploying distributed, online, enterprise applications to any device, anywhere. And both Microsoft and Sun recognise that this time, it will be the developers who will be making technology recommendations to their business associates.
Just what they’re going to like depends on personal taste. Owing to its roots in the well established Java development language, J2EE is perceived by many to be more mature—and, therefore, a safer bet—than its rival. Java, after all, has become ubiquitous within university programming courses, something that should guarantee a large and available pool of Java-skilled developers for the long term.
Having said that, .NET’s intrinsic support for most major programming languages means that developers may find that environment more accommodating than J2EE, which only supports Java. Support for multiple languages is particularly important in companies with a significant code base that needs to be moved online: instead of having to rewrite aging COBOL, C++, and Visual Basic applications in Java, those applications can be ported to .NET with minimal effort.
Developers are also coming to appreciate the Microsoft-authored C# language that debuted with Visual Studio.NET last year. “Java programmers like C# in ways they don’t like C++,” says Eyal Aronoff, chief technology officer with Quest Software. “It’s a modern development language with all the key concepts of Java, whereas C++ is trying to take an ancient language and make it modern. People that never went for Java get very excited about [.NET].”
Anecdotal evidence supports Aronoff’s observations. Visual Studio.NET encapsulates many complex Web application components into easy-to-manage function calls, maintaining detailed lists of interdependencies between applications. These lists ensure that modules communicate properly no matter how they’re moved. The end result is that developers often get up and running with .NET in virtually no time. Software vendor MXL, for one, saw productivity increase four-fold when it jumped from C++ to C# and .NET (see case study on page 36).
Charles Sterling, .NET developer evangelist with Microsoft Australia, has a simple explanation for the improvements: “I don’t think we’ve had anything that’s truly fun to develop in since Visual Basic 3,” he says. “The developer community has embraced and loves .NET. It’s not painful; you can just go out and develop. We’ll have to [win developers by] focusing on productivity: you can get apps done faster because you’ll have to write fewer lines of code.”
Smarter J2EE tools are delivering efficiency improvements on the other side of the scale, too. One business analyst, working with US consulting firm E-SoftSys, recently tried out Compuware’s OptimalJ development system to rewrite a J2EE-based workflow application. He was able to complete the work in 248 hours, compared with the 400 hours it had taken a two-person team the first time around. That’s a significant improvement, given the inherent complexity of J2EE and its component Enterprise Java Beans (EJB) architecture.
Whether those improvements came from the development tools or were the result of the specific developer’s technique is not clear. The point to take from their experiences is that with the right approach to development, both J2EE and .NET can help developers produce fully Web-enabled applications far faster than they could in the past. As they come to favour the nuances of one environment over the other, they’ll be able to formulate concrete arguments as to which direction their company should go.
In the long term, however, those preferences may well change as J2EE development tools follow the lead of Visual Studio.NET, and other .NET development environments.
“It’s currently easier in Visual Studio.NET to build a Web service than it is under Java,” says Andy Cooper, brand manager for information management solutions with Computer Associates Australia. “But that’s now as opposed to three months down the track. By the time Web services become really used, a year from now, both will probably have similar ease of use.”
Microsoft: learning to be open?
While it’s easy to reduce the J2EE versus .NET question to one of platform—choose Windows and you’re tied to .NET, pick J2EE if you’re using Unix—recent changes in the industry mean that’s no longer a guarantee.
For example, a US judge’s recent decision to force Microsoft to incorporate Java into Windows could revitalise Java’s role in that environment, paving the way for a better J2EE platform running under Windows. If customers took that approach, they would tap into the innovation around the Windows environment without being locked into .NET and Microsoft’s other applications.
At the same time, the obvious need for Microsoft to avoid seeming heavy-handed has seen its representatives surprisingly open about the possibility of moving .NET off the Windows platform. It was quick to submit its Common Language Interface (CLI), a key component of the CLR, to the European Computer Manufacturers Association (ECMA). ECMA standardised the CLI, along with the C# language, in 2001, paving the way for third parties to build other versions of the applications on other platforms.
As if to prove the point, Microsoft partnered with one-time Linux advocate Corel—which owes its very existence to Microsoft’s US$135 million stake in the company—to build shared-source versions of C# and the Common Language Interface (CLI) for Windows and the FreeBSD operating system. Linux was intentionally left off the agenda, a move that suggested Microsoft was testing the waters of Unix but wasn’t yet ready to give in to longtime nemesis Linux.
Recognising that playing in the world of standards removes the strength of leverage, Sterling concedes that Microsoft’s desire to promote .NET has forced a different mindset. He’s even accepting of the possibility that Linux and Solaris will play a role in .NET’s success, thanks to the efforts of the Ximian-headed Mono project (www.go-mono.com). The developers working on Mono have already ported the CLI to Linux on Intel and PowerPC processors as well as S390-based mainframes; versions for StrongARM (used in handheld computers) and Sun’s SPARC computers are also underway.
Not encouraging .NET on Windows’ arch rivals, but not discouraging it either—it’s a strategy that will ultimately allow Microsoft to extend .NET’s reach without having to overtly support its philosophical arch rival Linux. And with low-cost or free alternatives to .NET out there, Sterling says Microsoft is committed to playing the game right this time around.
“Operating systems now have to compete on their own merits,” he says. “They don’t get to compete on history, momentum, or existing investments. If we’re going to compete with OSes that cost 20 times as much as us, and compete with OSes that are free, we have to show we’re much more cost-effective and provide more value than either. This is what’s going to cause us to become a much better company. I like to think of it not so much as competing, but as playing well with others.”
A kinder, gentler Microsoft? Maybe. But James Eagleton, enterprise architect with Sun, believes Java’s openness and support across multiple platforms—the standard is progressed by a 400-strong worldwide community of software vendors building all kinds of applications—will make it the emotional favourite for developers long sceptical of Microsoft’s way of doing things.
“.NET is relatively untested, but it’s a recognition from Microsoft that object-oriented based languages are a step forward in better componentisation of code, and that a runtime environment is a good step,” Eagleton says.
“It will make development much easier in terms of interoperability between business logic and internal operations. But there are other reasons that big enterprises want to run their systems. A lot of it comes down to the maturity of the language and framework. Compatibility between all three application tiers is a compelling factor for Java.”
There is one area where many fear Microsoft hasn’t learned new tricks, however. Its disastrous Licensing 6.0 pricing program, launched to widespread criticism last August, raised the cost of Microsoft products so much that it’s been credited with convincing many companies to evaluate non-Microsoft products for the first time. With Windows Server 2003 poised to become the linchpin of Microsoft’s future application strategy (soon to include enterprise applications like its Great Plains ERP and a forthcoming Microsoft-built CRM package) many fear the company will impose an equally onerous pricing model this time around.
Among the changes is a new per-processor External Connector license, says Microsoft Australia Windows server product manager Michael Leworthy, that will cover access to .NET Server “for business partners, customers, alumni—anyone who’s a non-employee of the company”. In other words, anyone who’s not an internal, salaried employee needs to pay for even occasional use of Windows Server 2003-driven resources (see www.microsoft.com/licensing/resources/server_overview.asp for more details of the licensing scheme).
That approach may prove unpalatable for companies seeking to build large .NET applications extending to a large number of business partners. Implications for individual companies will obviously vary, but it’s worth your time to carefully weigh up current and future licensing obligations when considering long-term application costs.
Making the platform choice
In the early days of .NET, its close ties with Windows meant the choice of platform was a simple one: .NET for Windows environments, J2EE for everything else.
With cross-breeding between Sun, Microsoft, Linux and other platforms now well underway, the decision is very much about personal taste—that of your developers—rather than being an exercise in technical isolation. Also important in the decision is your existing allegiance to IT suppliers: strong involvement with IBM, for example, may push you in the direction of J2EE simply because that’s where the company’s skills are.
Since both frameworks are built to interface with industry-standard Web services, integration between the two should (theoretically) be a relatively simple matter. This will make it entirely feasible for companies to apply a horses-for-courses approach and teach J2EE and .NET to live together in something resembling bliss.
That’s one theory, at least. In practicality, the expense of sourcing and keeping dual-skilled developers may drive many companies towards the platform that’s best supported by strategic application partners. If more Microsoft-loving software companies build their applications more for .NET than J2EE environments, natural selection will start to play a role. But if application developers can maintain parity in their support for the two, tomorrow’s enterprise applications market should support both for the long term.
“I think a lot of organisations who are currently saying they’re going to choose one or the other, will probably end up using both,” says CA’s Cooper, who says the company wants to be “the Swiss of the platform battle. You tend to find hard and fast rules only tend to appear when the business gets involved.”
Companies with relatively few legacy environments and a strong investment in Windows may gravitate towards .NET for its ease of use and ability to consolidate their applications around Windows servers. Certainly, companies wanting to roll out rich applications integrated with client desktops may find .NET’s tight Windows integration to be a real benefit.
But that doesn’t mean it’s the only choice. J2EE is universally recognised (even by Gosling) to be harder to work with and more complex to get up and running, but once it’s up it is highly secure, tremendously scalable, and extremely robust. That was one of the key factors behind Telstra’s decision to use J2EE as the basis of its future development, although .NET will still play a role in scattered parts of the organisation.
The use of Java also allows encapsulation of business logic into highly portable application modules that mirror individual business functions. Those modules can then be assembled in different ways to follow the company’s change over time. This, says Compuware’s Pritchard, could tilt the scales in J2EE’s direction.
“The whole J2EE model architecture is a nice thing for large applications where you can have business analysts write the program,” he explains. “That’s been one of the big problems of IT projects from back in the dinosaur ages: business analysts would design something but couldn’t code it, and it was done by technical people who did not know what the code means. They would code something wonderful that didn’t do the job.”
Ultimately, doing the job is exactly what these platforms are all about. Thanks to Sun’s years of experience with Java and the ongoing pressure on Microsoft to conform to standards, corporate customers now have two extremely robust, well-received application platforms on which to base their future Web-based businesses. That’s not a clear answer to the question “which platform is better”—but it may help many managers sleep well knowing they no longer have to sell their souls when making the choice.
Shouldn't you change 'Microsoft has changed' to 'Microsoft has to change'? A small but great difference, imho...