difference in jsp:usebean between tomcat 4 and 5

[Daniel Gibby]

Hi, I've noticed a change in the java code that results from a 
jsp:usebean when upgrading from tomcat 4 to tomcat 5.
I'm wondering if this is a change in the spec or just a coding 
difference between versions:

*This jsp:*
<jsp:useBean id="payment" class="mybeans.ValidateableBean" 
scope="session" />
*Results in this java code: *

*on tomcat-5.0.19:*
mybeans.ValidateableBean payment = null;
synchronized (session) {
   payment = (mybeans.ValidateableBean) 
_jspx_page_context.getAttribute("payment", PageContext.SESSION_SCOPE);
   if (payment == null){
       payment = new mybeans.ValidateableBean();
       _jspx_page_context.setAttribute("payment", payment, 
PageContext.SESSION_SCOPE);
   }
}

*in tomcat-4.1.27 (same on tomcat-4.1.30 I believe):*
mybeans.ValidateableBean payment = null;
synchronized (session) {
   payment = (mybeans.ValidateableBean) 
pageContext.getAttribute("payment", PageContext.SESSION_SCOPE);
   if (payment == null){
       try {
           payment = (mybeans.ValidateableBean) 
java.beans.Beans.instantiate(this.getClass().getClassLoader(), 
"mybeans.ValidateableBean");
       } catch (ClassNotFoundException exc) {
           throw new InstantiationException(exc.getMessage());
       } catch (Exception exc) {
           throw new ServletException("Cannot create bean of class " + 
"mybeans.ValidateableBean", exc);
       }
       pageContext.setAttribute("payment", payment, 
PageContext.SESSION_SCOPE);
   }
}

Was this a 'performance enhancement'? The problem I have with the tomcat 
5 code is that it doesn't catch errors. ValidateableBean just happened 
to be an abstract class with multiple ValidateableBean subclasses. The 
section of code that this is in had an if statement around it that made 
sure that the 'payment' variable shouldn't have been null, and that it 
was already an instance of a ValidateableBean subclass, so the code 
would have just called pageContext.getAttribute and have been done.

Tomcat 4 was fine with the abstract class because when it compiled it 
never tried validate the call to 'new mybeans.ValidateableBean()'
Tomcat 5 throws an error that an abstract class can't be instantiated 
(which is true, but why does is the compiler now forced to perform this 
check?)

Insights?

Daniel Gibby