Issue 3670: Exception mapping needs fixing (java2idl-rtf) Source: Borland Software Corporation (Mr. Vijaykumar Natarajan, nobody) 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: See revised text below Revised Text: 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." Actions taken: June 1, 2000: received issue May 24, 2001: closed 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). (Vijay) I vote no on 3117 and 3670 as I am very concerned that there are is an increasing number of cases where we decide not to handle it because it's too difficult or backward incompatible and the number of cases where the reverse mapping cannot handle a valid java class is becoming large. End of Annotations:===== Date: Wed, 31 May 2000 17:42:46 -0700 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org Subject: [Fwd: Exception mapping needs fixing.] Content-Type: multipart/mixed; boundary="------------B4D95CCF1654E21F4023B54A" X-UIDL: X_4!!3,Ie9HCad9LI8e9 Vijaykumar Natarajan wrote: > 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? > > Vijay Message-ID: <3935B133.F164542C@inprise.com> Date: Wed, 31 May 2000 17:41:23 -0700 From: Vijaykumar Natarajan X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: java2idl-rtf@omg.org Subject: Exception mapping needs fixing. Content-Type: multipart/mixed; boundary="------------07D1A18A4C065F028623BAE7" 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? Vijay [] vijayn.vcf [] vijayn1.vcf Date: Mon, 13 Nov 2000 21:04:56 +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 3670 proposed resolution Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: !9%e9*iD!!RiMe9C0R!! I will place the following proposed resolution for issue 3670 in vote 2 of the Java to IDL RTF unless I hear otherwise by close of business Wednesday. 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. 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