Feature for feature, the development platforms are virtual peers, but philosophically they remain poles apart
By Jennifer deJong
April 15, 2005 – It’s a long, slow cold war, with no winner in sight.
That’s partly because the J2EE and .NET platforms are neck and neck in terms of what they let developers do, but also because a truce has been established between the two parties. Both camps have essentially called off the battle, opting instead to embrace the now firmly entrenched reality: Most companies have committed to both application development and deployment environments.
“I don’t see either one taking out the other in the near future,” said Henry Bowers, a director of product marketing for Mountain View, Calif.-based ILOG, which sells business rules management and other development tools for both environments.
Which one will win is no longer even a question, added Yaacov Cohen, president and CEO of San Jose-based Mainsoft, which sells J2EE and .NET interoperability software. In terms of training and skills, many companies would prefer not to support both development technologies. But the heterogeneous computing landscape is a reality, he said. “Companies have both. Banks are merging. One is .NET; the other is J2EE. And it’s the same in [other industries],” Cohen said.
Some organizations know that they will never be a pure shop, added Tom Bice, vice president of product marketing at Seattle-based WRQ, which sells integration tools that tie Java, .NET and other applications to the mainframe. “So why fight it?” Instead, they develop a strategy around both platforms. J2EE may be more applicable in some areas, while .NET is a better fit in others, he said. “They bring a mixed bag to the table.”
Asked to weigh in on the relative strengths and weaknesses of each platform, toolmakers that sell software for both said that many of the longstanding stereotypes-.NET on the desktop, and J2EE on the server-still hold true. They also commented on the cultural and business factors that have shaped and continue to influence each development environment, and noted how competition between platforms benefits both. One camp innovates and other responds, and the opposite is also true, said Borland’s chief technology officer, Pat Kerpan. “We are moving toward a friendly fifty-fifty.”
J2EE and .NET offer a “semantically identical set of features,” said Kerpan. But they are poles apart in terms of the philosophies that govern them. With the J2EE application server, there is a platform that sits up above the operating system, offering a large but complex set of capabilities. “Microsoft has never clumped [those capabilities] together in the same way,” he said.
Put another way, the J2EE application server is essentially the next generation of APIs built into the operating system, added Roger Thornton, chief scientist at Palo Alto, Calif.-based Fortify, which sells application security tools that test code written in Java and the .NET languages, among others.
.NET’s deep integration with the operating system accounts for the most obvious difference between the two environments: For the most part, an application developed in .NET will run only on Windows. But a J2EE application can also be deployed on Linux, Mac OS, Solaris and Unix without having to be recoded, said Scott Westfall, director of software development for SlickEdit, a Morrisville, N.C.-based company that sells editing and debugging tools for Java and the .NET languages, among others.
That flexibility is a great thing, said Kerpan. “But if all I need is access to the message queue, Java can be unnecessarily complex.”
That Windows-only drawback is also .NET’s greatest strength. It beats J2EE hands-down on the desktop, industry experts acknowledge. “Microsoft has a huge edge on Java [in terms of] visual development for the front end,” said Mike Sawicki, OptimalJ product manager at Detroit-based Compuware, which offers J2EE and .NET development and testing tools.
Java presentation layer technologies AWT and Swing still have a tough time integrating with Windows, added Daniel Selman, a product manager at ILOG. .NET is also easier to use, enabling developers to accomplish more, faster, they say. Compared with JavaServer Pages, ASP.NET is more productive, said Ken Cowan, product manager for Compuware’s DevPartner offerings for .NET.
Thanks to wizards and prewritten code in Visual Studio, “you can get something up and running in .NET quicker than in Java,” echoed Colin Doyle, a product manager at Waterloo, Ontario-based MKS, which sells configuration management and other tools for both environments. In terms of coding, database access, even installation, .NET is easier to use, added Mainsoft’s Cohen. “Try to install JBoss or Eclipse. You have to be a computer scientist.”
Stereotypes Still Apply
To some degree, that longstanding stereotype-Java is for computer scientists, while Microsoft caters to programmers who learned to code in Visual Basic-still holds. But today it’s largely a misperception. “Java developers tend to be more skilled,” said Joe Fernandez, a director of product marketing at Empirix, which sells testing tools for both Microsoft and Java developers. But while .NET is easier to use and offers more productivity tools, building serious enterprise applications in either environment requires a high degree of skill, he said.
“But when you hire a trained J2EE developer, you know exactly what skills that person will have,” said Compuware’s Sawicki. “You are working against a standard.” By contrast, as a group, Microsoft developers possess a wide range of programming abilities, he said.
J2EE’s key strength is that it is more mature and is perceived as more enterprise-ready than .NET, said Jonathan Cortez, a product manager at ILOG. Despite the gains .NET has made in the enterprise, questions about the scalability of applications built in the Microsoft environment persist, he said. It’s a stigma based on earlier evolutions of the technology, he said. “But the perception has been inherited.”
J2EE is also perceived as more mature in terms of mainframe integration, said Compuware’s Cowan. That capability is built into the J2EE stack, he said. But he noted that .NET also provides mainframe integration support through its Host Integration Server.
J2EE’s strong hold on the server and .NET’s tight grip on the desktop have led to what Fortify’s Thornton calls a standard blueprint in the enterprise development landscape today: .NET client going through Web services to J2EE on the server. “When you walk down Wall Street, you keep tripping over that architecture.” For Microsoft, that has been an entry point, he said.
One area in which J2EE and .NET are both weak is data access, said Chris Keene, vice president of caching for ObjectStore, a division of Bedford, Mass.-based Progress Software. “Both are trouble but for different reasons.” .NET’s ADO.NET still forces developers to write a lot of code to overcome the row and column limitation of accessing a relational database. In the J2EE camp, there are so many data binding standards-JDBC, JDO, among others-that aim to solve this problem, it’s not clear which one will prevail. ObjectStore provides data access and caching tools for both development environments.
Democracy? Benevolent Dictator?
A host of cultural factors also holds sway over the two development environments.
“.NET is a benevolent dictator, and Java is a democracy,” said ILOG’s Selman. And both forms of government have drawbacks.
The J2EE development community is big, dynamic and active and offers hundreds of open-source tools, such as Hibernate, Ant and JUnit, which are only just now making their way into the .NET camp, he said. And while the Java Community Process is democratic, it’s also slow and chaotic. “It’s like herding cats,” Selman said. Java vendors-BEA, IBM, Oracle, Sun-have their own agendas, and that spills over into the process and slows innovation.
The .NET camp has problems of its own. It has been hurt by product delays, particularly that of Longhorn, said ILOG’s Cortez, noting that Microsoft does not expect to deliver the next generation of Windows until 2006. “There was great excitement among developers when Microsoft first talked about Longhorn late in 2003,” he said. And some of that momentum has been lost.
What’s more, Microsoft is still an all-Microsoft environment, said Chris Fedorko, vice president of product management for Burlington, Mass.-based Klocwork, which sells testing and other tools for both development platforms. “If you are pure Microsoft, there are magical things you can leverage, such as the ability to integrate with other Microsoft servers and applications, such as Office.” If you commit to Microsoft, there is a lot to take advantage of, he said.
“But .NET has a fundamental problem,” added Adam Kolawa, CEO of Monrovia, Calif.-based Parasoft, which sells testing tools for J2EE and .NET. “It’s an all-or-nothing strategy. And in my view, people are not going to lock themselves into one environment.”
No Godzilla vs. Rodin
As Microsoft prepares to deliver Visual Studio Team System, its life-cycle development platform expected this summer, the competition may move to a new arena: Team System versus Eclipse.
“The openness of Eclipse has forced Microsoft to open up Visual Studio,” said MKS’ Doyle. “With Team System, Microsoft has put in more APIs that make it easier for vendors like us to expose our products in Visual Studio,” he said. In the past, third-party vendors had to do more of the integration work themselves.
However the J2EE versus .NET drama plays out, things have turned out better than expected. “If you think back to the initial fears, before Microsoft released .NET, [the industry thought] this would be Godzilla versus Rodin, and we would all be collateral damage from the war between the two.” said Borland’s Kerpan. “It’s evolved more positively than that.”
Klocwork® offers a portfolio of development productivity tools designed to ensure the security, reliability and maintainability of complex code bases. Using proven static analysis technology, Klocwork’s tools identify critical security vulnerabilities and reliability defects, optimize peer code review, and help developers create more maintainable code. Klocwork’s tools are an integral part of the development process for over 1000 customers in the consumer electronics, mobile devices, medical technologies, telecom, military and aerospace sectors.
Klocwork and the Klocwork logo are registered trademarks of Klocwork, Incorporated in the United States and other countries. All other names are trademarks or registered trademarks of their respective companies.