A Tale of Two ORBs
By kcavanaugh on May 09, 2007
One question that comes up over and over again is why do we have two Java ORBs?
We ship an ORB in the JDK, and also one in GlassFish. Why don't we just use the JDK ORB in GlassFish?
We do maintain a single master source code repository for CORBA from which we deliver both the JDK and the GlassFish ORBs. This repository is currently
only available inside of Sun, because it uses TeamWare. In the future, the master repository will migrate to Mercurial, and be made available on the open internet.
The basic problem is version skew across releases. Java 5 code was frozen (if memory serves) sometime in late 2004. Meanwhile ORB development continued for the 8.x releases of the app server, which were Java EE 4 compliant. The basic rule is that Java EE x requires Java SE x as its minimum feature set, but of course Java EE x should also run on Java SE x+1. Now we are working on Java EE 5 for GlassFish v2, which will FCS sometime later in 2007. So there is roughly a 3 YEAR window from the time the ORB in the JDK is frozen, until that JDK is the minimum required JDK release for the app server.
Note that we do take steps to make sure that the two ORBs don't conflict:
- sun.corba only contains the Bridge and BridgePermission classes. This defines the contract between the ORB and the JDK that the ORB requires to get certain required features that are not possible through standard JDK APIs. This class is sharable by both ORBs.
- The tools are in com.sun.tools.corba (idlj) and sun.rmi.rmic.iiop. However, GlassFish does not use idlj at all, and rarely uses rmic, so the packaging of the tools is not a problem.
- com.sun.corba.se contains most of the ORB classes, including the SPI that defines the extended ORB interface required by GlassFish.
- com.sun.corba.se is automatically renamed to com.sun.corba.ee during the ORB build that is used for GlassFish.
- All ORB property names start with com.sun.corba.se, as of around a year ago. (They are then automatically renamed, along with everything else that contains com.sun.corba.se). It turned out that some serious integration issues were caused in part by having the JDK and GlassFish ORBs share the same property names.
For development purposes, it is possible to do all testing and development without the rename. Note that you REALLY want to use NetBeans 6 for debugging (if you use NetBeans) because NetBeans 5 gets very confused about having two different classes with the same name (one in the JDK, one in the current ORB under development).
A lot can happen in 3 years. We implemented quite a few features intended mainly for the app server:
- Completion of dynamic RMI-IIOP
- Further refinement of the fast object copier
- Development of the codegen library
- Creation of the ReferenceFactoryManager for dynamic IIOP failover and load balancing
- Many improvements in the log wrapper code generation
- Addition of the internal timer framework in the ORB
- Support for hardware load balancers
- A lot of work in generifying the ORB (still incomplete)
- Many bug fixes
- Lots of performance optimizations
None of this work is available in the JDK ORB, which makes it impossible to use the JDK ORB in GlassFish. However, it would be VERY nice if we could get to a point where using the JDK ORB for at least GlassFish application clients would be possible. This would help with one of the most frequently requested features for GlassFish: reduce the size of the jar file needed for application clients. I think this may become reasonable once we get the current GlassFish ORB into JDK 7. It will be quite a long time before we can assume that JDK 7 is the base level JDK required for the GlassFish (How long will it take to even define Java EE 7?).
Another possibility is to migrate the ORB to a component framework, and allow partial
replacement of the ORB components in the JDK with ORB components from GlassFish's
ORB. I've done some work on this, but I don't think time will permit much to happen
here for JDK 7.