Malcolm Davis's Blog

April 2004 Archives

RI the application

What is RI
Many developers first introduction into J2EE is in the form of JSP & Servlets. Using JSP & Servlets requires the services of a servlet container, and one of the most commonly used is Tomcat. However, Tomcat is more than an open source servlet container, Tomcat is also the Servlets and JavaServer Pages reference implementation (RI).

Tomcat demonstrates one of the core strengths of Sun’s work with Java, specifications and reference implementations.

Why RI
Initially, Tomcat did not promote itself as a production quality container. Industrial strength containers came in the form of JRun, BEA, IPlanet and many others. Tomcat provided several benefits to the developer:

• Because it was missing all the bells and whistles of the commercial counterparts, it was lightweight, fast, and easy to setup.
• A low cost entry into learning Java web technology.
• A tool to insure applications meet the Servlet/JSP specs. Many vendors provide extensions to the container. Using the vendor specific extensions in application development can hinder porting applications to other containers, or even newer versions of a vendor’s container.

Application portability
Everybody seems big on applications portability until it reaches Web development, then they have no problem being hooked into a single vendor. The mindset I have observed over and over again is: ‘we are not going to switch vendors’. The implied ‘never’ plagues organizations of all shapes and sizes. I’ve seen a single organization switch vendors 3 times over 4 years, each time saying they are migrating to a single vendor.

Fusing with a single vendor is worse then selecting a single OS, IDE or anything for that matter, and saying we will never change. Change is inevitable due to business needs, technology, or vendor offerings. The best way to fight change is to stay application vendor neutral.

The EJB container
The lonely cousin to the Tomcat is the J2EE platform RI. The J2EE RI is provided by Sun and can be found at http://java.sun.com/j2ee/. The J2EE RI contains all the things that Tomcat does not, like EJBs and JMS. The J2EE RI is:

• Lightweight and easy to setup.
• A low cost entry into learning J2EE technology.
• A tool to insure J2EE applications meet the specs.

Nevertheless, for several reasons developers have not used J2EE RI.

• Previous to J2EE 1.4 releases, the RI was only for development and not deployment.
• Many major IDE did not support the J2EE RI. Only recent versions of JBuilder Enterprise support the RI, and MyEclipse still does not support the RI. [However, Genuitec does plan to extend the MyEclipse Enterprise Workbench to support the J2EE 1.4 RI.]
• Organizational attitudes. The Java mindset is having a difficult time penetrating the corporate world due to things like the fear of open source, lack of understanding of RI, and the stance on using single vendor implementations.
• Not all vendor implementations are RI compliant. Even if the application were developed with the RI, it might not execute correctly in the vendors application server. For example, frameworks like Struts had problems deploying to particular application servers that were supposedly J2EE certified.

Included in the build
Not all is lost, if the RI cannot be included in your organizations development process, it can be included in the build by using the Application Verification Kit (AVK). The kit can be found at http://java.sun.com/j2ee/avk/. Among other things, the kit contains the ability to search source for items that are not J2EE compliant. Ant extensions are provided that help find things during the build process. I doubt AVK will catch everything or solve all RI problem in a organization, but it’s a place to start.

Sun is working to solve the usage problem with J2EE RI by allowing it to be used in production, and working with tool vendors to have it included in product lines. Maybe someday I will see companies using the J2EE RI as the standard for development as many have done with Tomcat.

Where's the marketing occurring? Subliminal messages in technical articles of course.

When reading “ASP.NET and Struts: Web Application Architectures”, I was expecting to see a comparison of the 2 web techniques, ASP.NET and Struts. Instead, a continuous theme of “why .NET is better than J2EE” underlies the article.

Anybody with J2EE knowledge can find hordes of problems with the article starting with the comparison drawing. For example, you get the idea that JDBC is not part of the core API, and all J2EE database access is via JDBC. What happened to EJB and JDO?

Of course, J2EE and J2SE API are complex and obfuscated while the BCL is "rich and extensive". Even if critiques of the API layer might have merit, what is it doing in an article about ASP.NET and Struts?

I will avoid my long tirade of things wrong with the piece. As we mature we cultivate a sense of skepticism, we expect problems with articles, plus marketing occurs. However, Microsoft takes the art of self-promotion to an entirely new level with the sub-conscious attacks on Java.

My history is composed of over 6 years of Microsoft development, so really none of the discussion is new. Yet looking back, I did not realize the level of subliminal messaging I was receiving. [Maybe there should be a new Subliminal Messaging API . :-) ]

However not all is lost. Based on the article evaluation at the bottom of the page, apparently Microsoft developers expect more than technology hype.

This work is licensed under a Creative Commons License.