JDK-4615605 : J2SE 1.4/1.3 interop broken for RemoteException and unchecked exceptions
  • Type: Bug
  • Component: other-libs
  • Sub-Component: corba:orb
  • Affected Version: cts1.3.1,1.3.0,1.4.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2001-12-19
  • Updated: 2008-11-05
  • Resolved: 2002-06-12
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
1.3.1 04Fixed 1.4.1Fixed
Related Reports
Relates :  
JDK-4676248 - JDK 1.3.1/1.4 interop failure for all exceptions
Relates :  
JDK-4833514 - JVM crash while reading FVD described class
Relates :  
JDK-4904723 - JDK 1.3.1/PEORB interop failure for exceptions
Description
When a J2SE 1.3.x client talks to a J2SE 1.4 server with RMI-IIOP, and on the first request on a connection, the result is an unchecked exception or RemoteException (or subclass), the client hangs.

When the server is 1.3.x and the client is 1.4, the client will receive a CORBA UNKNOWN exception with minor code 0 rather than the exception as created on the server.

Please see the attached test case.

********************************************************************************

###@###.### 2002-06-12

Fix verified ok:
- with build: j2sdk-1_4_1-beta-bin-b14-solaris-sparc-04_jun_2002
- with test: attached test "extest.zip.Z"

********************************************************************************
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.3.1_04 hopper FIXED IN: 1.3.1_04 hopper INTEGRATED IN: 1.3.1_04 hopper VERIFIED IN: 1.3.1_05 hopper-beta
14-06-2004
PUBLIC COMMENTS When a J2SE 1.3.x client talks to a J2SE 1.4 server with RMI-IIOP, and on the first request on a connection, the result is an unchecked exception or RemoteException (or subclass), the client hangs. When the server is 1.3.x and the client is 1.4, the client will receive a CORBA UNKNOWN exception with minor code 0 rather than the exception as created on the server.
10-06-2004
EVALUATION This is being raised as an urgent OMG for the Java to IDL RTF. Here is the issue submission: --- When an unchecked exception or RemoteException occurs in RMI-IIOP, it is translated into a CORBA UNKNOWN system exception, and the real Java exception is marshaled as a CDR encapsulation in the UnknownExceptionInfo service context. (Java to IDL formal 01-06-07 1.4.7, 1.4.8.1) In J2SE 1.4, java.lang.Throwable has evolved to add several new non-transient fields including private Throwable cause; private StackTraceElement[] stackTrace; This means that when J2SE 1.3.x talks to 1.4 and an unchecked exception or RemoteException occurs, there is a class evolution scenario occurring inside of the UnknownExceptionInfo service context. Normally, class evolution is handled by using the SendingContextRunTime CodeBase to find out what the sender put on the wire. This service context is sent by the client on the first request on a connection and by the server on the first reply on a connection. (Java to IDL formal 01-06-07 1.5.1) This presents two problems: 1. Since the UnknownExceptionInfo service context has the Throwable in an encapsulation, technically it has no connection information. 2. Even if we assumed that we use the connection on which this encapsulation is transmitted, we would need to make sure that the SendingContextRunTime service context is unmarshaled BEFORE the UnknownExceptionInfo service context so that the connection has the CodeBase to use to unmarshal the evolved Throwable class. Here are two possible solutions: 1. Service context ordering proposal (strawman): Require that service context encapsulations use the connection on which they are sent if they need the CodeBase, and that the UnknownExceptionInfo service context must be unmarshaled after the SendingContextRunTime service context. Specifically, add this language to the Java to IDL spec in section 1.4.8.1. Note: We may need to be careful not to generalize to all service contexts. For instance, code sets for wstring/wchar inside of service context encapsulations should probably be explicitly stated when defining the service context at the spec level. 2. New service context & backwards compatibility proposal: Add a new UnknownExceptionInfo service context called something like UnknownExceptionInfoPlusCodeBase service context. It contains the CodeBase IOR followed by the java.lang.Throwable. Thus, all necessary information is contained, and we can support evolution going forward in this particular service context. Older receivers would just disregard it. For backwards compatibility with J2SE 1.3 and before, we must still also send the original UnknownExceptionInfo service context containing something that looks like the J2SE 1.3 java.lang.Throwable class. Thus, we must define the format of this new structure and how to translate from J2SE 1.4 or later Throwables to it. --- It is too late to resolve and fix this for the SDK 1.4.0 release, so it will have to be put in for 1.4.1 or an earlier patch release, assuming it is resolved at the OMG in time. We will have to update our release notes for 1.4.0 to document this failure and commit to fix for 1.4.1. ###@###.### 2001-12-18 This has become Java to IDL issue 4795, expected to be voted on and resolved before the next technical meeting at the end of this month: http://cgi.omg.org/issues/issue4795.txt The current proposal may require service updates for our J2SE 1.3 and 1.4.0 implementations. ###@###.### 2002-01-16
16-01-2002