JDK-6277781 : Serialization of Enums over IIOP is broke.
  • Type: Bug
  • Component: other-libs
  • Sub-Component: corba:idl
  • Affected Version: 5.0,5.0u14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,linux
  • CPU: generic,x86
  • Submitted: 2005-05-30
  • Updated: 2018-07-26
  • Resolved: 2009-01-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other JDK 6 JDK 7
5.0u17-revFixed 5.0u19Fixed 6u11-rev b07Fixed 7Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
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 http://hg.openjdk.java.net/jdk7/build/corba/rev/f642c9ec81a0
04-12-2010

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
01-06-2005