United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6277781 Serialization of Enums over IIOP is broke.
JDK-6277781 : Serialization of Enums over IIOP is broke.

Details
Type:
Bug
Submit Date:
2005-05-30
Status:
Resolved
Updated Date:
2012-10-18
Project Name:
JDK
Resolved Date:
2009-01-26
Component:
other-libs
OS:
linux,generic
Sub-Component:
corba:idl
CPU:
x86,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
5.0,5.0u14
Fixed Versions:
6u11-rev (b07)

Related Reports
Backport:
Backport:
Backport:
Backport:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
FULL PRODUCT VERSION :
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08)
Java HotSpot(TM) Client VM (build 1.5.0_01-b08, mixed mode)


A DESCRIPTION OF THE PROBLEM :
When Enums are passed over RMI IIOP, they are not serialized/deserialized correctly.

They fail the equals() test. This is quite major.

I have an application that serializes an enumeration across a socket connection. When I read one and do an equals against one of the local Enum objects, it fails. However, enum.name().equals(deserializedEnum.name()) returns true and so does enum.getClass().equals(deserializedEnum.name()).

I am doing an import static com.foo.bar.MyEnum.* when I set my items to be serialized, I don't know if that causes a problem or not.

However, I can't reproduce the error simply. Creating a local ByteArrayOutput/Input streams works ok. This seems to be happening over a socket connection.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
javac EnumIIOPBreakage.java
rmic -classpath . -iiop Server
java -classpath . EnumIIOPBreakage


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
equal?                 true
classes equal? true
names equal?   true
ACTUAL -
equal?                 false
classes equal? true
names equal?   true

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.rmi.*;
import java.util.*;

import javax.rmi.*;
import javax.naming.*;

enum MyEnum { ONE, TWO, THREE };

public class EnumIIOPBreakage
{
  public static void main(String[] args)
    throws Throwable
  {
    Hashtable properties = new Hashtable();
    properties.put("java.naming.factory.initial",
                   "com.sun.jndi.cosnaming.CNCtxFactory");
    properties.put("java.naming.provider.url", "iiop://localhost:1099");

    new Server(properties);

    Context context = new InitialContext(properties);
    Object ref = context.lookup("server");
    RServer server = (RServer) PortableRemoteObject.narrow(ref, RServer.class);

    System.out.println("equal?         " +
                       MyEnum.ONE.equals(server.get(MyEnum.ONE.name())));
    System.out.println("classes equal? " +
                       MyEnum.ONE.getClass().equals(
                           server.get(MyEnum.ONE.name()).getClass()));
    System.out.println("names equal?   " +
                       MyEnum.ONE.name().equals(
                           server.get(MyEnum.ONE.name()).name()));
  }
}

class Server
  implements RServer
{
  public Server(Hashtable properties)
    throws Throwable
  {
    PortableRemoteObject.exportObject(this);

    Context context = new InitialContext(properties);
    context.rebind("server", this);
  }

  public MyEnum get(String name)
  {
    return MyEnum.valueOf(name);
  }
}


interface RServer
  extends Remote
{
  MyEnum get(String name)
    throws RemoteException;
}

---------- END SOURCE ----------
###@###.### 2005-05-30 05:28:17 GMT

                                    

Comments
EVALUATION

This is interesting. Enum.equals() has reference semantic, should it preserve such reference semantic across VMs, e.g. in a RMI IIOP call?
###@###.### 2005-06-01 10:26:14 GMT

Recategorizing because this CR seems primarily about the lack of support for serializing Java enum constants over RMI-IIOP.    (Note that in some circumstances the result will be deserialization failure rather than creation of an instance that doesn't behave properly-- such as if constant-specific specialization in the enum type has evolved between the sender's version and the receiver's version.)

###@###.### 2005-06-06 22:44:00 GMT

This problem first requires attention by the OMG Java to IDL mapping 
RTF.?? The problem is that the serialized form of a Java enum must
be interoperable across all Java ORB implementations.?? Currently the
RMI-IIOP spec says nothing about Java enums, since it has not been
updated for Java SE 5.

Another problem here is that every RMI-IIOP construct must be translated
into OMG IDL so that there is a mapping in non-Java environments.
IDL does define an enum, but IDL enums are limited to simple constants,
without any possibility of methods on IDL enums (IDL enums are not
objects, unlike Java enums).

However, the IIOP marshaled form of an IDL enum is simply an unsigned
long, representing the ordinal position of the enum constant in the
definition.?? This form cannot provide the kinds of binary compatibility 
that are part of the Java serialization spec.

This suggests that a more complex mapping is required.?? Basically it
will be necessary to treat enums as IDL value types so that the type
information is available that will be needed to deserialize the
enum constant.

The solution that comes to mind is as follows:

1. Simply marshal enums following the standard value type rules.
2. On unmarshal, we can recognize enum constants because their
???? type extends java.lang.Enum.
3. Use the information about extending Enum in simpleReadObject
???? to use Enum.valueOf to find the correct enum constant.

We can't introduce a TC_ENUM as in the Java serialization code
because there is simply no place to put it in the CDR representation.

We can possibly explore this for Mustang, but I don't think any
of us on the CORBA team have time for this until Dolphin.
The almost certain necessity of dealing with this at the OMG
also makes this more difficult to fix.



###@###.### 2005-06-16 18:18:47 GMT
                                     
2005-06-01
EVALUATION

http://hg.openjdk.java.net/jdk7/build/corba/rev/f642c9ec81a0
                                     
2010-12-04



Hardware and Software, Engineered to Work Together