Issue 3433: No factory for javax.rmi.ClassDesc (java2idl-rtf) Source: Borland Software Corporation (Mr. Vijaykumar Natarajan, nobody) Nature: Uncategorized Issue Severity: Summary: There appears to be no way to construct a javax.rmi.ClassDesc, since the ClassDesc class has two private members and no constructor. This is required by non-default implementations of ValueHandler. There are many ways to solve this issue. 1. Add a public constructor to javax.rmi.ClassDesc (preferred) 2. Make members protected so other implementations can subclass and add constructors 3. create a factory method in say Util that returns a ClassDesc which takes the required parameters. Resolution: See revised text below Revised Text: 1. In section 1.3.5.11, change the declarations of repid and codebase from private to public. 2. Add the following field to section 1.3.5.11: static final long serialVersionUID = -3477057297839810709L; Actions taken: March 20, 2000: received issue May 24, 2001: closed issue Discussion: It is not correct to say that non-default ValueHandlers must construct a ClassDesc instance, since the correct wire representation can be written without an actual instance being constructed. However, it seems reasonable to modify the definition of the ClassDesc class to allow instances to be constructed and initialized. The simplest way to do this is by making the data members public instead of private. This also has the benefit of making these data members accessible from other languages, by making them public in the Java to IDL mapping of this class. Note that changing these member declarations to public changes the default SUID. Therefore, for on-the-wire compatibility with current implementations, it is necessary to specify the current SUID value using an explicit declaration. End of Annotations:===== Date: Mon, 20 Mar 2000 11:17:51 -0800 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org, java2idl-rtf@omg.org Subject: No factory for javax.rmi.ClassDesc Content-Type: multipart/mixed; boundary="------------D218EF3E55012382F1E96E5F" X-UIDL: JSdd9R:gd9GOK!!1N3e9 Hi all, There appears to be no way to construct a javax.rmi.ClassDesc, since the ClassDesc class has two private members and no constructor. This is required by non-default implementations of ValueHandler. There are many ways to solve this issue. 1. Add a public constructor to javax.rmi.ClassDesc (preferred) 2. Make members protected so other implementations can subclass and add constructors 3. create a factory method in say Util that returns a ClassDesc which takes the required parameters. Vijay [] vijayn2.vcf Date: Mon, 13 Nov 2000 20:23:42 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: java2idl-rtf@omg.org Subject: Issue 3433 proposed resolution Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: YECe9Y:a!!]5"!!n6Qe9 I will place the following proposed resolution for issue 3433 in vote 2 of the Java to IDL RTF unless I hear otherwise by close of business Wednesday. Discussion: It is not correct to say that non-default ValueHandlers must construct a ClassDesc instance, since the correct wire representation can be written without an actual instance being constructed. However, it seems reasonable to modify the definition of the ClassDesc class to allow instances to be constructed and initialized. The simplest way to do this is by making the data members public instead of private. This also has the benefit of making these data members accessible from other languages, by making them public in the Java to IDL mapping of this class. Note that changing these member declarations to public changes the default SUID. Therefore, for on-the-wire compatibility with current implementations, it is necessary to specify the current SUID value using an explicit declaration. Proposed Resolution: 1. In section 1.3.5.11, change the declarations of repid and codebase from private to public. 2. Add the following field to section 1.3.5.11: static final long serialVersionUID = -3477057297839810709L; Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Mon, 27 Nov 2000 18:24:23 -0800 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: Mary Leland , Vijay Natarajan , Stefan Bauer , Jeff Mischkinsky , Yoshitaka Honishi , java2idl-rtf@omg.org, juergen@omg.org Subject: Re: Java to IDL RTF Vote 2 References: <3A18446C.A8CD9606@hursley.ibm.com> Content-Type: multipart/alternative; boundary="------------9ECFAFF2F79EF7600DA47182" X-UIDL: eak!!O)(!!2#Zd99Jnd9 Hi all Sorry, I just got time to look at this. I have an issue with the resolution for Issue 3433: No factory for javax.rmi.ClassDesc The resolution says the simplest way to solve this is to make class members public and then provides a resolution that includes change of SerialVersionUIDs etc. This solution also means that one has to construct the object and then set the variables. I believe the simplest way to do this is to add a constructor that takes all the arguments (and possibly a default one that sets the members to default values). This would mean no SerialVersionUID changes and is more efficient. I counter propose the following: Add a constructor to ClassDesc as follows: public ClassDesc(String repId, String[] codebase); This involves no addition of SerialVersionUID and has no back compat issues as far as I can tell. Thanks, Vijay Simon Nash wrote: RTF Members: Please see the attached html file for the issues to be voted on and their proposed resolutions. Votes are due by 5pm US EST on November 28, 2000. The voting members of the Java to IDL RTF are: Simon Nash, IBM Mary Leland, HP Vijay Natarajan, Inprise Stefan Bauer, Sun Jeff Mischkinsky, Persistence Yoshitaka Honishi, Fujitsu Juergen: Please put the attached html file in the http://cgi.omg.org/pub/java2idl-rtf directory. Thanks. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Java to IDL 2000 RTF Vote 2 Deadline for Votes: 5pm, US Eastern Standard Time, November 28, 2000 Summary of Issues in this Vote Issue 2111: mapping from java.rmi Remote to CORBA::Object Issue 3117: Name mangling scheme broken. Issue 3152: Tie.deactivate() exception handling Issue 3267: How to create marshalel data of java.lang.Throwable instance? Issue 3433: No factory for javax.rmi.ClassDesc Issue 3670: Exception mapping needs fixing Issue 3857: Descriptions of readAny and writeAny not precise enough Issue 2111: mapping from java.rmi Remote to CORBA::Object Click here for this issue's archive. Nature: Uncategorized Issue Severity: Summary: Are we trying to support sending JRMP stubs over IIOP? If so, then it would seem that the IDL mapping of java.rmi.Remote to CORBA::Object works against that; it would need to be changed to Any. Resolution: Revised Text: Actions taken: October 20, 1998: received issue Discussion: Changing the mapping of java.rmi.Remote from Object to any would be a major incompatibility and realistically is not an option. Therefore this issue as currently worded should be closed no change. If there is a requirement to send JRMP stubs across RMI-IIOP (and so far we have not seen user demand for this), then another approach that does not change the Java to IDL mapping should be used. For example, JRMP stubs could be serialized as IORs with a JRMP profile. Proposed Resolution: In section 1.5.1.4, at the end of the paragraphs describing writeRemoteObject and writeAbstractObject, add the sentence: "This method cannot be used to write a JRMP object reference to an output stream." Issue 3117: Name mangling scheme broken. Click here for this issue's archive. Source: Inprise Corporation (Mr. Vijaykumar Natarajan, vijayn@inprise.com) Nature: Uncategorized Issue Severity: Summary: Say I have a class octet in the global scope and I have an interface interface foo extends java.rmi.Remote { void op(byte x); void op(octet y); }; The operations in IDL will now be op__octet (octet x) and op__octet(::_octet); which is incorrect. Resolution: Revised Text: Actions taken: December 15, 1999: received issue Discussion: This problem occurs in two cases only: 1. The case described in the issue, where two overloaded Java methods have parameters declared as byte (a Java primitive) and octet (a class in the default package). The method name mangling rules map both of these to "octet". 2. The case where two overloaded Java methods have parameters declared as char (a Java primitive) and wchar (a class in the default package). The method name mangling rules map both of these to "wchar". There are many other cases of valid Java method declarations that do not map to unique names in IDL. The Java to IDL mapping was never intended to ensure uniqueness in all possible cases, but only in cases that are likely to occur in real applications. Since this error can only occur when an application contains classes called "octet" or "wchar" in the default package, and since use of classes in the default package is not recommended for deployment of production applications, it is not worth introducing a new mangling rule to support these two specific cases. Instead, the rules in section 1.3.2.9 should apply in this case. Proposed Resolution: Close, no change. Issue 3152: Tie.deactivate() exception handling Click here for this issue's archive. Source: International Business Machines (Mr. Simon C. Nash, nash@hursley.ibm.com) Nature: Uncategorized Issue Severity: Summary: The javax.rmi.CORBA.Tie.deactivate() method does not declare any exceptions. However, when using a POA servant, the following exceptions can be thrown by the RMI/IDL tie's implementation of deactivate(): org.omg.PortableServer.POAPackage.ServantNotActive org.omg.PortableServer.POAPackage.WrongPolicy (by the servant_to_id() method) org.omg.PortableServer.POAPackage.ObjectNotActive org.omg.PortableServer.POAPackage.WrongPolicy (by the deactivate_object() method) How should these exceptions be handled by Tie.deactivate()? If they should be rethrown by Tie.deactivate(), what exception(s) should be used? (This issue was raised by Max Mortazavi of Sun.) Resolution: Revised Text: Actions taken: December 21, 1999: received issue Discussion: The lack of a throws clause on the signature for Tie.deactivate() was an oversight. This method is called only by Util.unexportObject(), which is called only by PortableRemoteObject.unexportObject(). Since the signature for PortableRemoteObject.unexportObject() has a throws clause for java.rmi.NoSuchObjectException, the same throws clause should be added to the signatures for both Tie.deactivate() and Util.unexportObject(). If a POA-based tie gets a POA exception when deactivating an object, it should throw a NoSuchObjectException whose detail field contains the original POA exception. Util.unexportObject() should rethrow this exception to PortableRemoteObject.unexportObject(), which should rethrow it to its caller. Proposed Resolution: 1. In section 1.5.1.1, add "throws java.rmi.NoSuchObjectException" to the declaration of the Tie.deactivate method. 2. In section 1.5.1.1, add the following sentence at the end of the paragraph describing the Tie.deactivate method: "If the target object could not be deactivated (e.g., because it is not currently active), a NoSuchObjectException is thrown." 3. In section 1.5.1.4, add "throws java.rmi.NoSuchObjectException" to the declaration of the Util.unexportObject method. 4. In section 1.5.1.4, add the following sentence at the end of the paragraph describing the Util.unexportObject method: "If the object is not currently exported or could not be deactivated, a NoSuchObjectException is thrown." 5. In section 1.5.3.2, add "throws java.rmi.NoSuchObjectException" to the declaration of the UtilDelegate.unexportObject method. Issue 3267: How to create marshalel data of java.lang.Throwable instance? Click here for this issue's archive. Source: Fujitsu (Mr. Masayoshi Shimamura, shima@rp.open.cs.fujitsu.co.jp) Nature: Uncategorized Issue Severity: Summary: I don't understand that how to create marshaled data of java.lang.Throwable instance to set it to context_data in UnknownExceptionInfo. In CORBA 2.3.1, section "13.6.7 Object Service Context" on 13-25 page says: UnknownExceptionInfo identifies a CDR encapsulation of a marshaled instance of a java.lang.throwable or one of its subclasses as described in Java to IDL Language Mapping, Section 1.4.8.1, "Mapping of UnknownExceptionInfo Service Context," on page 1-32. In Java to IDL Language Mapping specification revised by RTF (ptc/99-03-09), section "28.4.8.1 Mapping of UnknownExceptionInfo Service Context" on page 28-32 says: CORBA UNKNOWN exceptions whose GIOP Reply message includes an UnknownExceptionInfo service context containing a marshaled instance of java.lang.Throwable or one of its subclasses are mapped to RMI exceptions according to the type of the object contained in the service context, as shown in follows: ------------------------------------------------------------------- UnknownExceptionInfo RMI Exception ------------------------------------------------------------------- java.lang.Error java.rmi.ServerError java.rmi.RemoteException java.rmi.ServerException java.lang.RuntimeException java.rmi.ServerRuntimeException(JDK 1.1) java.lang.RuntimeException(Java 2) ------------------------------------------------------------------- It seems to me that these specifications above are not clear. How to create the context_data from java.lang.Throwable instance? I guess the context_data should be created by one of following two ways. Which way is correct? Or is there any other correct way? 1. A instance of java.lang.Throwable or its subclasses should be serialized by Java language specific serialization function and then should be set to the context_data as sequence of octet. 2. A instance of java.lang.Throwable or its subclasses should be marshaled as CORBA Value type data and then should be set to the context_data as sequence of octet. Resolution: Revised Text: Actions taken: February 1, 2000: received issue Discussion: Section 1.4.7 states that "All other Java exceptions are marshaled as CORBA UNKNOWN system exceptions whose GIOP Reply message includes an UnknownExceptionInfo service context containing the marshaled Java exception thrown by the server implementation." The phrase "marshaled Java exception" should be clarified to avoid possible confusion as to how this marshaling is done. Proposed Resolution: Add the following sentence to the end of section 1.4.7: "The Java exception is marshaled using the rules for CDR marshaling of value types as defined by the GIOP specification, applied in conjunction with the rules for mapping RMI/IDL value types to IDL as defined in section 1.3.5 of this specification." Issue 3433: No factory for javax.rmi.ClassDesc Click here for this issue's archive. Source: Inprise Corporation (Mr. Vijaykumar Natarajan, vijayn@inprise.com) Nature: Uncategorized Issue Severity: Summary: There appears to be no way to construct a javax.rmi.ClassDesc, since the ClassDesc class has two private members and no constructor. This is required by non-default implementations of ValueHandler. There are many ways to solve this issue. 1. Add a public constructor to javax.rmi.ClassDesc (preferred) 2. Make members protected so other implementations can subclass and add constructors 3. create a factory method in say Util that returns a ClassDesc which takes the required parameters. Resolution: Revised Text: Actions taken: March 20, 2000: received issue Discussion: It is not correct to say that non-default ValueHandlers must construct a ClassDesc instance, since the correct wire representation can be written without an actual instance being constructed. However, it seems reasonable to modify the definition of the ClassDesc class to allow instances to be constructed and initialized. The simplest way to do this is by making the data members public instead of private. This also has the benefit of making these data members accessible from other languages, by making them public in the Java to IDL mapping of this class. Note that changing these member declarations to public changes the default SUID. Therefore, for on-the-wire compatibility with current implementations, it is necessary to specify the current SUID value using an explicit declaration. Proposed Resolution: 1. In section 1.3.5.11, change the declarations of repid and codebase from private to public. 2. Add the following field to section 1.3.5.11: static final long serialVersionUID = -3477057297839810709L; Issue 3670: Exception mapping needs fixing Click here for this issue's archive. Source: Inprise Corporation (Mr. Vijaykumar Natarajan, vijayn@inprise.com) Nature: Uncategorized Issue Severity: Summary: When I have Java exceptions called foo fooException fooError they all get mapped to the exception fooEx causing collisions. I am not sure what the fix should be so I'll dump my thoughts here... The correct fix for this probably should be: foo -> fooEx fooException -> fooExcp fooError -> fooEr However, given that that would not be backward compatible, another solution would be All exceptions map to the Ex suffix. Each collision adds an _ (underscore) at the end, if there is a collision. However, this has problem with the name changing depending on which exception gets processed first, and the resultant definitions are not deterministic. Any other ideas? Resolution: Revised Text: Actions taken: June 1, 2000: received issue Discussion: There is no conflict between fooError and the exception class names foo and fooException, since a trailing Error string is not removed before appending the Ex suffix. However, there is a conflict between foo and fooException. Without making an incompatible change, there is no way to resolve this conflict, since the mapping of each class must be deterministic and cannot vary depending on whether another exception class with this name conflict also exists (since the second class could be created after the first class has been mapped). This is similar to the treatment of Java class or interface names that differ only in case. The mapping deals with such method or field names within a class by applying a deterministic mangling rule, since all method and field names within a class are known when the class is mapped. However, applying the same mangling to class or interface names would require global knowledge of all class and interface names that could be mapped, which is not practical. It seems reasonable to follow this precedent and not specify a mangling fpr conflicting exception names that would require global knowledge of all class and interface names that could be mapped. In practice this conflict is unlikely to cause any serious problems, since the JDK names all exceptions with an Exception suffix and other packages should use a a consistent naming convention for all their exceptions (either with or without an Exception suffix). Proposed Resolution: Add the following after the bullets in section 1.3.7.2: "If applying the above rules yields the same OMG IDL name for more than one Java exception name (e.g., there are Java exception names foo and fooException, which both map to the OMG IDL name fooEx), then this is treated as an error." Issue 3857: Descriptions of readAny and writeAny not precise enough Click here for this issue's archive. Source: International Business Machines (Mr. Simon C. Nash, nash@hursley.ibm.com) Nature: Uncategorized Issue Severity: Summary: The descriptions of readAny and writeAny in section 1.5.1.4 of the Java to IDL mapping spec are not very precise and don't say how null values should be handled. These methods are currently described in section 1.5.1.4 as follows: > The writeAny method writes the Java object obj to the output stream out in the > form of a GIOP any. The readAny method reads a GIOP any from the input stream > in and unmarshals it as a Java object, which is returned. Proposed resolution: Replace the above paragraph in section 1.5.1.4 by the following: "The writeAny method writes the Java object obj to the output stream out in the form of a GIOP any. The contents of the GIOP any are determined by applying the Java to IDL mapping rules to the actual runtime type of obj. If obj is null, then it is written as follows: the TypeCode is tk_value, the repository ID is "IDL:omg.org/CORBA/ValueBase:1.0", the name string is "", the ValueModifier is VM_NONE, the concrete base is tk_null, the member count is 0, and the any's value is a null valuetype (0x00000000). The readAny method reads a GIOP any from the input stream in and unmarshals it as a Java object, which is returned. The following TypeCodes are valid for the GIOP any: tk_value, tk_value_box, and tk_objref. If the TypeCode is anything other than these, a MARSHAL exception is thrown." Resolution: Revised Text: Actions taken: September 5, 2000: received issue Discussion: Using tk_value for java.lang.Object null seems incorrect because a java.lang.Object does not only contain valuetypes. Another alternative is tk_null, but this is currently used for an any with no contents rather than an any containing a null. The bext compromise appears to be tk_abstract_interface. The IDL abstract interface type can represent all the legal values of java.lang.Object in the Java to IDL mapping. Also, using this representation is consistent with the folllowing usability goals: 1. When nulls are sent from IDL to RMI-IIOP, the same insertion operations for anys that are used for n Date: Tue, 28 Nov 2000 11:09:02 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Vijaykumar Natarajan CC: Mary Leland , Stefan Bauer , Jeff Mischkinsky , Yoshitaka Honishi , java2idl-rtf@omg.org, juergen@omg.org Subject: Re: Java to IDL RTF Vote 2 References: <3A18446C.A8CD9606@hursley.ibm.com> <3A231757.C025B4D3@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: L%7!!8`>e9O&6e9b`c!! Vijay, Actually, adding a constructor does change the default SUID, so with this approach it would still be necessary to add a serialVersionUID declaration. I'm not sure what you mean by the constructor being more efficient. I don't think the cost of doing the two variable assignments in the calling code is any greater than doing them in the constructor. Changing the variable attributes is a smaller change than adding a constructor. Also, making the variables public has the advantage of making them accessible in other languages like C++. This would not be true if they remain private and are set by a constructor. RTF members: Since vote 2 is due today, we will vote on the original proposal in vote 2. If this proposal passes, and if Vijay still disagrees with it, then we can vote on his alternate proposal in vote 3. Simon > Hi all > > Sorry, I just got time to look at this. I have an issue with the > resolution for > > Issue 3433: No factory for javax.rmi.ClassDesc > > The resolution says the simplest way to solve this is to make class > members public and then provides a resolution that includes change > of > SerialVersionUIDs etc. This solution also means that one has to > construct the object and then set the variables. I believe the > simplest > way to do this is to add a constructor that takes all the arguments > (and > possibly a default one that sets the members to default > values). This > would mean no SerialVersionUID changes and is more efficient. > > I counter propose the following: > > Add a constructor to ClassDesc as follows: > > public ClassDesc(String repId, String[] codebase); > > This involves no addition of SerialVersionUID and has no back compat > issues as far as I can tell. > > Thanks, > Vijay Vijaykumar Natarajan wrote: > > Part 1.1 Type: Plain Text (text/plain) > Encoding: 7bit -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb