Posted by malcolmdavis
on April 28, 2004 at 7:40 AM PDT
The J2EE reference implementation (RI) doesnt get any respect.
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 Suns work with Java, specifications and reference implementations.
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 vendors container.
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. Ive 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 its 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.