How the J2EE and .Net platforms perform

November 30, 2001 —

While a "90 percent overlap" exists between .Net and J2EE (Java 2 Enterprise Edition), differences in the low level language, the presentation tier and the handling of portability may influence a developer's choice of software platform.

Roger Sessions, chief executive officer of distributed software training specialist ObjectWatch Inc., noted that in J2EE, the low level language is the Java byte code whereas with .Net, it is the Microsoft intermediate language (MSIL), which ships with Microsoft's new Web services development tool VisualStudio.Net later this year.

"The design in the underlying language is different," said Sessions, who was one of the speakers at the Microsoft Developers' Fest in Singapore last week. ObjectWatch specializes in advanced training for software architects.

"Java byte code is very tightly tied to Java, and works very well for Java. MSIL, on the other hand, works with all programming languages except Java," said Sessions.

Although Microsoft recently released J#, a full implementation of Sun Microsystems' Java language specification that will run many existing Java applications after a simple recompile or binary conversion, Sessions is not convinced. "Microsoft may say that its J# is Java compatible, but it is not just a matter of syntax. It's also the Java APIs (application programming interface) and J# does not support these," he pointed out.

Depending on its existing skill sets, therefore, a programming shop may favor one technology over the other. "A programming shop with Java experience can work more effectively with J2EE, using Java byte code. But if it has Visual Basic experience, it would be more productive with .NET, using MSIL," said Sessions.

Another difference between J2EE and .Net lies at the presentation tier, which interacts with the browser, said Sessions. For Microsoft, the programming framework for this layer is ASP.Net and for J2EE, it is the Java server pages (JSP).

"Microsoft has a technology that was initially the same as JSP, called ASP (application server pages), but ASP.Net is very different," Sessions pointed out.

As he explained, four layers of code come into play in processing a browser interaction.

The three most complex of these -- the processing of the user request from the browser, state management, and the output of information to different browsers -- have been automated in ASP.Net. Programmers will thus only have to code for access to business logic, for example, to authorize a credit card transaction. And this, according to Sessions, is the simplest of the four levels.

"There is a 90 percent complexity reduction with ASP.Net compared with ASP/JSP," he said. "At some point, J2EE will have to respond."

While the technical gap between ASP.Net and JSP is likely to be closed eventually, what is likely to remain a key difference between the J2EE and .Net platforms is the different route each is taking with regard to portability.

Major J2EE vendors such as IBM and BEA support many operating systems, said Sessions. "They have chosen a portability architecture."

To run on different operating systems, J2EE-based products such as IBM's WebSphere are divided into two segments -- a main code body and a portability layer which insulates this code body from the OS, and translates it into something that the OS can handle.

The portability layer has to be kept as thin as possible because of the need to port it to different operating systems. "You should be having no more than 5 percent of code in the portability layer," said Sessions.

A second requirement for the portability layer is that the main code body cannot make calls to the OS direct. By Sessions' assessment, both BEA and IBM have been quite successful in reinforcing these requirements. The result is good portability, but the downside is poor performance. "There is another layer of software to go through, and the code cannot be optimized for the operating system," Sessions pointed out.

In contrast, the .Net approach enables the main code body to be optimized for the Microsoft operating system. The result is good performance, but poor portability.

To make a good decision, developers need to know the performance difference between the two systems and the associated cost per transaction.

Computerworld Singapore