FULL PRODUCT VERSION :
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta3-b84)
Java HotSpot(TM) Client VM (build 1.4.0-beta3-b84, mixed mode)

FULL OPERATING SYSTEM VERSION :
 customer  Windows 2000 [Version 5.00.2195]



A DESCRIPTION OF THE PROBLEM :
Exceptions and subclasses (and possibly Throwable
subclasses - haven't tested) serialized in 1.4 (Tomcat 3.2
server) can not be deserialized using jdk 1.1 (Internet
Explorer client).


REGRESSION.  Last worked in version 1.3.1

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Write a servlet that serializes an Exception (or
subclass) to the response outputstream.
2. Write an applet that reads the  customer .
3. Run the servlet and serve the applet on Tomcat 3.2 (will
probably work on any server running in 1.4 though)
4. Connect to the servlet using the applet in a 1.1 client
(i.e. Internet Explorer)

EXPECTED VERSUS ACTUAL BEHAVIOR :
Surely Exceptions should be serializable between different
VMs, as they were before 1.4?

ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.lang.ClassNotFoundException
	at java/io/ObjectInputStream.loadClass0 (ObjectInputStream.java)
	at java/io/ObjectInputStream.resolveClass (ObjectInputStream.java:852)
	at java/io/ObjectInputStream.readClassDescriptor
(ObjectInputStream.java:1165)
	at java/io/ObjectInputStream.readArray (ObjectInputStream.java:1100)
	at java/io/ObjectInputStream.checkSpecialCases
(ObjectInputStream.java:1063)
	at java/io/ObjectInputStream.readObject (ObjectInputStream.java:300)
	at java/io/ObjectStreamClass.doMismatchedRead (ObjectStreamClass.java)
	at java/io/ObjectInputStream.defaultReadObject
(ObjectInputStream.java:448)
	at java/io/ObjectInputStream.readNewObject (ObjectInputStream.java:1296)
	at java/io/ObjectInputStream.readObject (ObjectInputStream.java:309)

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
A test applet:

import java.io.*;
import java.net.*;
public class TestApplet extends java.applet.Applet {

    public void init () {
        try
        {
            URL url = new URL(getCodeBase()+"servlet/TestServlet");
            URLConnection urlConn = url.openConnection();
            ObjectInputStream ois =
                new ObjectInputStream(urlConn.getInputStream());
            Object obj = ois.readObject();
        }
        catch(Exception e)
        {
            e.printStackTrace();
        }
    }
}

and a test servlet:

import javax.servlet.*;
import javax.servlet.http.*;
public class TestServlet extends HttpServlet {

    protected void processRequest(HttpServletRequest request,
HttpServletResponse response)
    throws ServletException, java.io.IOException {
        java.io.ObjectOutputStream out =
            new java.io.ObjectOutputStream(response.getOutputStream());
        out.writeObject(new Exception("Test Exception"));
        out.close();
    }

    protected void doGet(HttpServletRequest request, HttpServletResponse
response)
    throws ServletException, java.io.IOException {
        processRequest(request, response);
    }

    protected void doPost(HttpServletRequest request, HttpServletResponse
response)
    throws ServletException, java.io.IOException {
        processRequest(request, response);
    }
}

---------- END SOURCE ----------

Release Regression From : merlin-beta3
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

Release Regression From : merlin-beta3
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

(Review ID: 138558) 
======================================================================

See evaluation.

The root cause of this problem is that the JVM in Internet Explorer exhibits
bug 4088176 ("backward compat. fails reading an evolved class with new field,
nonexistant class"), which was fixed in (Sun's) JDK 1.1.6.  Presumably the
implementation of serialization in Internet Explorer's JVM was based off of JDK
code prior to 1.1.6, or was independently implemented with the bug (note: from
the stack trace given, the ObjectInputStream implementation in Internet
Explorer's JVM does not appear to closely match any of Sun's implementations
from 1.1 through 1.1.5).

The reason that J2SE 1.4 triggers this problem is as follows: in J2SE 1.4, a
new serializable field "stackTrace" of type java.lang.StackTraceElement[] was
added to java.lang.Throwable.  The StackTraceElement class is itself new to
1.4, and is not present in JDK 1.1.x.  Because of bug 4088176, this causes
deserialization to fail in JDK <= 1.1.5 (including Internet Explorer's JVM).
The correct behavior (as documented by 4088176) is for the receiving VM to
disregard the failure to resolve StackTraceElement, since the field it is
associated with is not present in the local (1.1.x) version of
java.lang.Throwable.  Note that deserialization of exceptions written by 1.4
works properly in JDK 1.1.6 and later.

Since this failure is caused by a bug in the deserializing (applet-side) JVM,
and we do not have any means of affecting the serialization code in the JVM
bundled with Internet Explorer, there is no way to fix the underlying bug
directly, given the deployment described.  Several workarounds are possible,
however:

  1.  Use JDK 1.3.x or earlier for the server end.  Since the added
      "stackTrace" field is absent from JDK <= 1.3.x, this would avoid the
      particular failure described.  However, any other serializable classes
      with added fields whose types are unresolvable in Internet Explorer's JVM
      will trigger similar deserialization failures.

  2.  Use the Java Plug-In or Java WebStart on the client side.  Both employ
      JVMs in which 4088176 is fixed.

Closing as "will not fix", since the addition of StackTraceElement to
Throwable's serial form in 1.4 is completely legal, and the root cause of the
failure is due to 4088176 in code that is beyond our control.

  xxxxx@xxxxx   2002-02-07

Workaround: Send Throwable objects through custom
ObjectOutputStream, where you override method:

protected Object replaceObject(Object obj) throws IOException {
   if
("[Ljava.lang.StackTraceElement;".equals(obj.getClass().getName()))
return null;
   else return obj;
}