Issue 5696: Package name issue (java-rtf) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com) Nature: Uncategorized Issue Severity: Summary: This is an issue for the Java RTF. Related issue in Core RTF is Issue 5327. Originally from Michi Henning: suppose the following [pseudo-]idl: #pragma prefix "2abc.def" module xyz { interface q {...}; }; It would generate a Java class 'q' within package 'def.2abc.xyz'. The package name '2abc' is not that popular with the java compiler since it starts with a digit. Discussion from Jishnu Mukerji: It seems to me that this is more of a language mapping issue. I don't think that the Repository Ids have any requirement to be of the same shape as a valid IDL identifier. It would be kind of hard to have GUIDs as RepId if that were the case. But even for IDL type RepIds 12345.com seems to be a perfectly good domain name as is 2ab.com. I don't see why these perfectly valid domain names should be disallowed because the Java language mapping is unable to deal with them. Further discussion from Michi Henning: One way to fix it would be to state that: 1) For the Java mapping, any prefix that starts with a digit gets translated with an underscore prefix, so 2ab would turn into _2ab for the Java mapping. 2) Characters that can appear in a prefix pragma are limited to some set we'd have to agree on. (Probably the same as for IDL identifiers, plus '.' and possibly hyphen ('-').) Further discussion from Jishnu Mukerji: Item 1 in Michi's list needs to be handled by the IDL-Java RTF. This message to issues@omg.org is requesting the creation of an issue covering this item for the Java RTF. Item 2 can be taken care of in the resolution for Core Issue 5327. Resolution: close no change Revised Text: Actions taken: October 23, 2002: received issue April 28, 2003: closed issue Discussion: Discussion from Jishnu Mukerji: It seems to me that this is more of a language mapping issue. I don't think that the Repository Ids have any requirement to be of the same shape as a valid IDL identifier. It would be kind of hard to have GUIDs as RepId if that were the case. But even for IDL type RepIds 12345.com seems to be a perfectly good domain name as is 2ab.com. I don't see why these perfectly valid domain names should be disallowed because the Java language mapping is unable to deal with them. Further discussion from Michi Henning: One way to fix it would be to state that: For the Java mapping, any prefix that starts with a digit gets translated with an underscore prefix, so 2ab would turn into _2ab for the Java mapping. Characters that can appear in a prefix pragma are limited to some set we'd have to agree on. (Probably the same as for IDL identifiers, plus '.' and possibly hyphen ('-').) Further discussion from Jishnu Mukerji: Item 1 in Michi's list needs to be handled by the IDL-Java RTF. This message to issues@omg.org is requesting the creation of an issue covering this item for the Java RTF. Item 2 can be taken care of in the resolution for Core Issue 5327 Discussion: #pragma prefix affects only the repository ID, not the actual package into which the interface is placed. In fact, there are no #pragmas defined in the IDL to Java mapping. Various IDL to Java compilers include mechanisms to map IDL types into specific Java packages. For example, Sun's idlj supports a flag -pkgPrefix <t> <prefix> which puts the <prefix> in front of the normal mapping of <t>. Since all such mechanisms are proprietary, no spec change is needed here. End of Annotations:===== Date: Wed, 23 Oct 2002 11:27:40 -0400 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: issues@omg.org Cc: java-rtf@omg.org, corba-rtf@omg.org Subject: Package name issue This is an issue for the Java RTF. Related issue in Core RTF is Issue 5327. Originally from Michi Henning: suppose the following [pseudo-]idl: #pragma prefix "2abc.def" module xyz { interface q {...}; }; It would generate a Java class 'q' within package 'def.2abc.xyz'. The package name '2abc' is not that popular with the java compiler since it starts with a digit. Discussion from Jishnu Mukerji: It seems to me that this is more of a language mapping issue. I don't think that the Repository Ids have any requirement to be of the same shape as a valid IDL identifier. It would be kind of hard to have GUIDs as RepId if that were the case. But even for IDL type RepIds 12345.com seems to be a perfectly good domain name as is 2ab.com. I don't see why these perfectly valid domain names should be disallowed because the Java language mapping is unable to deal with them. Further discussion from Michi Henning: One way to fix it would be to state that: 1) For the Java mapping, any prefix that starts with a digit gets translated with an underscore prefix, so 2ab would turn into _2ab for the Java mapping. 2) Characters that can appear in a prefix pragma are limited to some set we'd have to agree on. (Probably the same as for IDL identifiers, plus '.' and possibly hyphen ('-').) Further discussion from Jishnu Mukerji: Item 1 in Michi's list needs to be handled by the IDL-Java RTF. This message to issues@omg.org is requesting the creation of an issue covering this item for the Java RTF. Item 2 can be taken care of in the resolution for Core Issue 5327. Jishnu. Issue 5696: Name mangling for module names that are not valid Java identifiers. (Related issue in Core RTF is Issue 5327) ------------------------------------------------------------------------------------------- Originally from Michi Henning: suppose the following [pseudo-]idl: #pragma prefix "2abc.def" module xyz { interface q {...}; }; It would generate a Java class 'q' within package 'def.2abc.xyz'. The package name '2abc' is not that popular with the java compiler since it starts with a digit. Discussion from Jishnu Mukerji: It seems to me that this is more of a language mapping issue. I don't think that the Repository Ids have any requirement to be of the same shape as a valid IDL identifier. It would be kind of hard to have GUIDs as RepId if that were the case. But even for IDL type RepIds 12345.com seems to be a perfectly good domain name as is 2ab.com. I don't see why these perfectly valid domain names should be disallowed because the Java language mapping is unable to deal with them. Further discussion from Michi Henning: One way to fix it would be to state that: 1) For the Java mapping, any prefix that starts with a digit gets translated with an underscore prefix, so 2ab would turn into _2ab for the Java mapping. 2) Characters that can appear in a prefix pragma are limited to some set we'd have to agree on. (Probably the same as for IDL identifiers, plus '.' and possibly hyphen ('-').) Further discussion from Jishnu Mukerji: Item 1 in Michi's list needs to be handled by the IDL-Java RTF. This message to issues@omg.org is requesting the creation of an issue covering this item for the Java RTF. Item 2 can be taken care of in the resolution for Core Issue 5327. Discussion: #pragma prefix affects only the repository ID, not the actual package into which the interface is placed. In fact, there are no #pragmas defined in the IDL to Java mapping. Various IDL to Java compilers include mechanisms to map IDL types into specific Java packages. For example, Sun's idlj supports a flag -pkgPrefix which puts the in front of the normal mapping of . Since all such mechanisms are proprietary, no spec change is needed here. Proposed Resolution: close no change X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 10 Dec 2002 14:19:04 -0800 To: Ken Cavanaugh , java-rtf@omg.org From: Andy Piper Subject: Re: Vote 5 (due 5 pm PST 12/17/02) BEA votes as follows: 2889: YES 3633: YES 3995: YES 4010: YES 5696: NO - I do not believe it is acceptable to rely on optional vendor-specifc features to compile legal IDL into legal Java. 5728: YES 5782: YES 5783: NO - whilst I agree that it should be the Stub that performs these operations, the nested exceptions is marshaled as a java Throwable and therefore _must_ be possible to be extracted if the underlying ORB understands RMI (and valuetypes). I would be happier with: - If the CORBA system exception org.omg.CORBA.portable.UnknownException is thrown, the stub translates it to the nested Throwable that the UnknownException contains. andy Date: Tue, 10 Dec 2002 14:40:21 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Vote 5 (due 5 pm PST 12/17/02) To: Ken.Cavanaugh@sun.com, java-rtf@omg.org, andyp@bea.com X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc >X-Sender: andyp@san-francisco.beasys.com >To: Ken Cavanaugh , java-rtf@omg.org >From: Andy Piper >Subject: Re: Vote 5 (due 5 pm PST 12/17/02) >Mime-Version: 1.0 > >BEA votes as follows: > >2889: YES >3633: YES >3995: YES >4010: YES >5696: NO - I do not believe it is acceptable to rely on optional >vendor-specifc features to compile legal IDL into legal Java. But that is not what is happening here. The legal IDL compiles into legal java WITHOUT any -pkgprefix change. #pragma prefix simply has no effect on the generated Java packages, so there is no problem in the generated code. If you are looking for a standard mechanism to set the Java package in the generated code, we have never had one, and I'm not sure anyone really wants to standardize this area. >5728: YES >5782: YES >5783: NO - whilst I agree that it should be the Stub that performs >these >operations, the nested exceptions is marshaled as a java Throwable >and >therefore _must_ be possible to be extracted if the underlying ORB >understands RMI (and valuetypes). I would be happier with: > >- If the CORBA system exception >org.omg.CORBA.portable.UnknownException > is thrown, the stub translates it to the nested Throwable that the > UnknownException contains. > If you and Ann agree on a revised wording, I'll be happy to include the changes in this vote. Thanks, Ken. Date: Tue, 10 Dec 2002 16:12:01 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Vote 5 (due 5 pm PST 12/17/02) To: Ken.Cavanaugh@sun.com, java-rtf@omg.org, andyp@bea.com X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc >X-Sender: andyp@san-francisco.beasys.com >To: Ken Cavanaugh , Ken.Cavanaugh@sun.com, >java-rtf@omg.org >From: Andy Piper >Subject: Re: Vote 5 (due 5 pm PST 12/17/02) >Mime-Version: 1.0 > >At 02:40 PM 12/10/2002 -0800, Ken Cavanaugh wrote: >>But that is not what is happening here. The legal IDL compiles into >>legal java WITHOUT any -pkgprefix change. #pragma prefix simply has >>no effect on the generated Java packages, so there is no problem >>in the generated code. >> >>If you are looking for a standard mechanism to set the Java package >in >>the generated code, we have never had one, and I'm not sure anyone >>really wants to standardize this area. > >Stupidly I have deleted the original e-mail. I thought the issue was >that >currently legal module names can translate into illegal java and that >the >only way of rectifying this is using a vendor-specific mechanism? I >would >much rather the mapping coped in some way or specified that the >compiler >has to barf. > The original email assumed that #pragma prefix changed the Java package in the generated code. However, #pragma prefix only changes the repository ID. It has no effect on the Java package of the generated code. You can find the entire archive at http://cgi.omg.org/issues/java-rtf.html#Issue5696 Ken.