Did .NET Really Beat J2EE Flat? Can It? (Continued)

However, no one should underestimate Microsoft (just ask Sony how much it's worried about Xbox). These factors could make .NET move forward with a greater rate than J2EE:

• .NET runs on Windows, so it's a Microsoft product on top of another Microsoft product. The engineers working on .NET have access to the nuts and bolts of the operating system, so it could be easy for them to tune up .NET applications. Any contest between J2EE and .NET will be performed on Windows machines because .NET is not really portable yet. However, to J2EE application servers, Windows is nothing but a black box.
• Microsoft has proven that it is good at catching up. In just over a year, its .NET Framework's performance is comparable to the more mature J2EE. .NET even implements many newer technologies that J2EE has yet to implement, such as caching and server-side components. In an ASP.NET page, caching can be done with a single line of code to enhance performance tremendously. In contrast, caching is not yet defined in a Java specification. Java developers have to code it themselves or use a third-party tool, such as the Jakarta Taglibs project. Also, .NET has had GUI server-side components since its first release early last year. Java is going to have those with the release of JavaServer Faces, but it's a year behind in this technology.
• Many Java Web technologies are not standards yet. Take Struts, for example. It's the framework for the recommended architecture for middle-sized and large Java Web applications. It is popular, but it has not been adopted as a standard. So there's no guarantee that this popular technology will not be overridden by a new standard later. This could create confusion especially for those wanting to choose a server-side technology for the first time. Microsoft is different. Anything coming out of Redmond will be supported.
• There are many J2EE players. While this encourages competition that leads to innovation, many great efforts are redundant. For example, BEA and IBM could be doing the same R&D that results in the same enhancements. If they joined forces, they could surely move faster. But this is not always feasible in business. Even members of the open source community sometimes compete with one another (JBoss and Jonas, Tomcat and Jetty, to name some). All .NET efforts at Microsoft, on the other hand, are under one "commander-in-chief." Little redundancy could happen here.
• New Java specifications are drafted by many collaborating organizations and individuals in a supposedly democratic way. While this ensures that even the smallest players can have their voices heard, it's often a time-consuming and lengthy process. On the other hand, specifications for new technologies at Microsoft are drafted by small teams that can make decisions more quickly. Microsoft has proved that it is faster to implement new technologies.

Indeed, with the current rate of the .NET Framework's progress, I am afraid that the J2EE community has more to worry about.