Issue 5742: scheme for mapping names is pretty byzantine (java2idl-rtf) Source: Boeing (Mr. Paul Murray, Paul.Murray3(at)PSS.Boeing.com) Nature: Enhancement Severity: Minor Summary: You know, this scheme for mapping names is pretty byzantine. As far as I can tell, if you happen to name a java variable J_Fred, you've got problems. I'm sure you get plenty of suggestions. Here's mine: 1) Underscore is used consistently as an escape character. Thus: _ -> __ $ -> _S \u1234 -> _U1234 ( -> _P (parenthesis) [ -> _B (bracket) ; -> _C (semiColon) / -> _F (forward slash) _U uppercases a single character doRecord -> DO_URECORD _A indicates that the entire name is in uppercase MAX_VALUE -> _AMAX__VALUE 2) inner classes - we replace the dot with a $, and use that as the name. This is how most java compilers produce inner classes. 3) Overloaded names - In the case of overloaded names, then rather than using the simple name of a method or variable, we use the converted name as it is defined in the java virtual machine specification, section 4.3. This is an already existing standard for uniquely identifying members in java classes. As methods are identified by parameters (ie: we don't need the return types to distinguish them), we can ignore the closing parenthesis and return type of a Method Descriptor. However, we use lowercase for the characters in table 4.2 so that our underscore escaping doesn't expand out foo(I to foo_P_UI thus: int FOO int foo void foo() Object foo(int) long foo(int[]) a.b.Boz foo(a.b.Bar.Baz) become FOO foo foo( foo(i foo([i foo(la/b/Bar$Baz; which are encoded by the rules above to _AFOO FOO FOO_P FOO_PI FOO_P_BI FOO_PLA_FA_F_UBAR_S_UBAZ_C These are not very natural ... but there you go. Serves you right for attempting to use IDL for overloaded names. If IDL had an name ailiasing facility (maybe it does), then all classes and methods could be generated as above and used as such in generated code, and an alias produced for those names which map unambiguously to a particular field or value. Thus for doAThing(int), all generated code would use DO_UA__UTHING_PI, but an alias DOATHING would be generated and presumably used by coders. Resolution: see above Revised Text: Actions taken: October 31, 2002: received issue July 1, 2003: closed issue Discussion: Resolution: Closed, no change. The current spec does cause collisions, and this has been known from the outset. The design objective was to avoid collisions for normal usage of Java method and variable names, while preserving reasonable usability for IDL generated from real-world Java classes and interfaces. It is correct that having names _fred and J_fred within the same Java interface or class causes problems. But how many real-world Java programs do this? Is there a problem with a real Java class or interface, or is this issue based on the theoretical possibility of a clash in a contrived case? Some of these suggestions have merit, but at this point it is not practical to make radical changes that would affect all RMI-IIOP applications and implementations. If there is a specific example of a name clash that is causing real-world problems, then the RTF can consider making minor changes to the existing mapping to resolve these problems End of Annotations:===== From: webmaster@omg.org Date: 30 Oct 2002 21:59:59 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Paul Murray Company: Computer Sciences Corporation mailFrom: pmurray6@csc.com Notification: No Specification: Java to IDL Language Mapping Section: 1.3.2 FormalNumber: ptc/02-01-12. Version: Version 1.2 RevisionDate: 08/01/02 Page: 1-7 to 1-10 Nature: Enhancement Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) Description You know, this scheme for mapping names is pretty byzantine. As far as I can tell, if you happen to name a java variable J_Fred, you've got problems. I'm sure you get plenty of suggestions. Here's mine: 1) Underscore is used consistently as an escape character. Thus: _ -> __ $ -> _S \u1234 -> _U1234 ( -> _P (parenthesis) [ -> _B (bracket) ; -> _C (semiColon) / -> _F (forward slash) _U uppercases a single character doRecord -> DO_URECORD _A indicates that the entire name is in uppercase MAX_VALUE -> _AMAX__VALUE 2) inner classes - we replace the dot with a $, and use that as the name. This is how most java compilers produce inner classes. 3) Overloaded names - In the case of overloaded names, then rather than using the simple name of a method or variable, we use the converted name as it is defined in the java virtual machine specification, section 4.3. This is an already existing standard for uniquely identifying members in java classes. As methods are identified by parameters (ie: we don't need the return types to distinguish them), we can ignore the closing parenthesis and return type of a Method Descriptor. However, we use lowercase for the characters in table 4.2 so that our underscore escaping doesn't expand out foo(I to foo_P_UI thus: int FOO int foo void foo() Object foo(int) long foo(int[]) a.b.Boz foo(a.b.Bar.Baz) become FOO foo foo( foo(i foo([i foo(la/b/Bar$Baz; which are encoded by the rules above to _AFOO FOO FOO_P FOO_PI FOO_P_BI FOO_PLA_FA_F_UBAR_S_UBAZ_C These are not very natural ... but there you go. Serves you right for attempting to use IDL for overloaded names. If IDL had an name ailiasing facility (maybe it does), then all classes and methods could be generated as above and used as such in generated code, and an alias produced for those names which map unambiguously to a particular field or value. Thus for doAThing(int), all generated code would use DO_UA__UTHING_PI, but an alias DOATHING would be generated and presumably used by coders. X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 31 Oct 2002 21:12:48 -0800 To: Juergen Boldt , pmurray6@csc.com, java2idl-rtf@omg.org From: Andy Piper Subject: Re: issues 5741 - 5742 -- Java to IDL RTF issues At 11:49 AM 10/31/2002 -0500, Juergen Boldt wrote: 1.2.3 RMI/IDL Remote Interfaces 2. All methods in the interface are defined to throw java.rmi.RemoteException or a superclass of java.rmi.RemoteException. Should this read " ... or a subclass of ..." as per point 4 and elsewhere? I think so. This is issue # 5742 scheme for mapping names is pretty byzantine These suggestions will break all conforming implementations in existence - of which there are many. andy Date: Fri, 01 Nov 2002 10:27:48 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en To: pmurray6@csc.com CC: java2idl-rtf@omg.org Subject: Re: issues 5741 - 5742 -- Java to IDL RTF issues Paul, Andy Piper wrote: > > At 11:49 AM 10/31/2002 -0500, Juergen Boldt wrote: > >1.2.3 RMI/IDL Remote Interfaces 2. All methods in the interface are > >defined to throw java.rmi.RemoteException or a superclass of > >java.rmi.RemoteException. > > > >Should this read " ... or a subclass of ..." as per point 4 and elsewhere? > > I think so. > The spec wording is correct. If a method of an interface declares a superclass of RemoteException (e.g., IOException) but does not declare RemoteException, then the method can throw RemoteException and all of its subclasses, as well as some other exceptions. The method therefore meets the criteria for a conforming remote interface. However, if the method declares a subclass of RemoteException (e.g., ConnectException) but does not declare RemoteException, then the method cannot throw RemoteException and neither can it throw other subclasses of RemoteException, such as ConnectIOException. The method therefore fails the criteria for a conforming remote interface. > >This is issue # 5742 > > > > scheme for mapping names is pretty byzantine > > These suggestions will break all conforming implementations in > >existence - > of which there are many. > The current spec does cause collisions, and this has been known from > >the outset. The design objective was to avoid collisions for normal usage of Java method and variable names, while preserving reasonable > >usability for IDL generated from real-world Java classes and interfaces. You are correct that having names _fred and J_fred within the same Java interface or class causes problems. But how many real-world Java programs do this? Did you encounter this problem with a real Java class or interface, or is this issue based on the theoretical possibility of a clash in a contrived case? Some of your suggestions do have merit, but at this point it is not practical to make radical changes that would affect all RMI-IIOP applications and implementations. If you have a specific example of a name clash that is causing real-world problems, then the RTF can consider making minor changes to the existing mapping to resolve these problems. Simon -- Simon C Nash, Chief Technical Officer, IBM Java Technology Hursley Park, Winchester, UK nash@hursley.ibm.com Tel. +44-1962-815156 Fax +44-1962-818999