An Adventure with Adventure Builder and getParameterMap

An Adventure with Adventure Builder and getParameterMap() ....

Someone in our group was just looking at the Sun Adventure Builder application and came across an interesting issue when running it against OC4J 10.0.3.

When exercising one part of the application, a class cast exception is thrown. When we had a look at through the source code, the offending line makes a call into the ServletRequest.getParameterMap() method as follows:

private void updateActivityHeadCounts(HttpServletRequest httpservletrequest)
{
  HttpSession httpsession = httpservletrequest.getSession();
  AdventureComponentManager adventurecomponentmanager =
    (AdventureComponentManager)httpsession.getAttribute("com.sun.j2ee.blueprints.waf.COMPONENT_MANAGER");
  Cart cart = adventurecomponentmanager.getCart(httpsession);
  HashMap hashmap = (HashMap)httpservletrequest.getParameterMap();
  ...
}

According to the J2EE 1.4 API docs at http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/ServletRequest.html#getParameterMap, this method has a signature of :

  public Map getParameterMap()
  Returns: an immutable java.util.Map containing parameter names as keys and parameter values as map values.

In the adventure builder code, the returned Map object is being explicitly cast into a java.util.HashMap.

The problem is that OC4J doesn't return a HashMap object from this method call -- it returns an object which implements the Map interface, as required by the API, but which is not a subclasss of HashMap.

With a simple test case, I verified that this method call works OK on the Sun RI/Tomcat. This method returns an object of type org.apache.catalina.util.ParameterMap which extends directly from java.util.HashMap. So the casting works OK.

But in the case of OC4J, where we return an implementation of the Map interface, but which is not a HashMap, the code barfs at the casting call.

Joshua Bloch recommends in his book [Effective Java Programming Language Guide, Item34] that developers "should favor the use of interfaces rather than classes to refer to objects".

This is a pretty good example of why that recommendation makes a lot of sense, and highlights the fact that application portability really requires strict coding to the APIs themselves, and not to any internal implementation details.

Last update: 2/18/2004; 2:02:14 PM.