Issue 1941: Problem mapping "global" types in Java mapping (java-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: The current IDL/Java mapping cannot correctly map IDL "global" types correctly in all cases. Resolution: Close, no action Revised Text: Actions taken: September 9, 1998: received issue June 4, 1999: closed issue Discussion: closed issue End of Annotations:===== Return-Path: Sender: "George Scott" Date: Wed, 09 Sep 1998 17:57:59 -0700 From: "George M. Scott" Organization: Inprise Corporation To: java-rtf@omg.org CC: issues@omg.org Subject: Problem mapping "global" types in Java mapping The current IDL/Java mapping cannot correctly map IDL "global" types correctly in all cases. For example: // IDL struct c { short x; }; module a { interface c { void op1(in ::c a); }; }; When mapped to Java cannot compile because the global import of the struct "c" clashes with the interface "c". Today, vendors work around these problems by allowing IDL compilers to place all IDL types in additional packages which solves this problem, but this is a vendor extension and not part of the mapping. We would therefore like to propose a standard solution to this problem. The proposal would be that all IDL names in the global top-level name space would be mapped to the Java package _IDL_GLOBAL. This name is expected to not clash with any existing systems and is prefixed with an underscore to prevent collision with a user-defined IDL module. We are open to other name suggestions... George Return-Path: Sender: jon@floorboard.com Date: Wed, 09 Sep 1998 19:06:29 -0700 From: Jonathan Biggar To: "George M. Scott" CC: java-rtf@omg.org, orb_revision@omg.org Subject: Re: Problem mapping "global" types in Java mapping References: <35F72417.B4F58BCC@inprise.com> George M. Scott wrote: > > The current IDL/Java mapping cannot correctly map IDL "global" types > correctly in all cases. For example: > > // IDL > struct c { > short x; > }; > > module a { > interface c { > void op1(in ::c a); > }; > }; > > When mapped to Java cannot compile because the global import of the > struct "c" clashes with the interface "c". Today, vendors work > around these problems by allowing IDL compilers to place all IDL > types in additional packages which solves this problem, but this > is a vendor extension and not part of the mapping. We would > therefore > like to propose a standard solution to this problem. > > The proposal would be that all IDL names in the global top-level > name > space would be mapped to the Java package _IDL_GLOBAL. This name is > expected to not clash with any existing systems and is prefixed with > an underscore to prevent collision with a user-defined IDL module. > We are open to other name suggestions... I would also be open to a suggestion that non-module definitions in the global scope be deprecated. It never was a good idea, and probably against everyone's style guide anyway. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: From: Jeffrey Mischkinsky Subject: Re: Problem mapping "global" types in Java mapping To: jon@floorboard.com (Jonathan Biggar) Date: Wed, 9 Sep 1998 20:32:07 -0700 (PDT) Cc: gscott@inprise.com, java-rtf@omg.org, orb_revision@omg.org 'Jonathan Biggar' writes: > > George M. Scott wrote: > > > > The current IDL/Java mapping cannot correctly map IDL "global" > types > > correctly in all cases. For example: > > > > // IDL > > struct c { > > short x; > > }; > > > > module a { > > interface c { > > void op1(in ::c a); > > }; > > }; > > > > When mapped to Java cannot compile because the global import of > the > > struct "c" clashes with the interface "c". Today, vendors work > > around these problems by allowing IDL compilers to place all IDL > > types in additional packages which solves this problem, but this > > is a vendor extension and not part of the mapping. We would > therefore > > like to propose a standard solution to this problem. > > > > The proposal would be that all IDL names in the global top-level > name > > space would be mapped to the Java package _IDL_GLOBAL. This name > is > > expected to not clash with any existing systems and is prefixed > with > > an underscore to prevent collision with a user-defined IDL module. > > We are open to other name suggestions... > > I would also be open to a suggestion that non-module definitions in > the > global scope be deprecated. It never was a good idea, and probably > against everyone's style guide anyway. That's a change for the core RTF to make. In the meantime, even if it were to be deprecated now, it would still be legal for "a while", and the Java language mapping has to be able to deal with. jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 jeffm@visigenic.com +1 650-358-3049 Return-Path: X-NS-Transport-ID: 0800201FCE5D39B41412 Date: Thu, 10 Sep 1998 12:58:40 PDT Sender: Christian_P_Jacobi.PARC@xerox.com From: jacobi.PARC@xerox.com Subject: Re: Problem mapping "global" types in Java mapping To: jon@floorboard.COM cc: gscott@inprise.COM, java-rtf@omg.org, orb_revision@omg.org >I would also be open to a suggestion that non-module definitions in the >global scope be deprecated. It never was a good idea, and probably >against everyone's style guide anyway. Very good idea. When we deprecate this bad feature before we make it vendor independant, there will be much less old code to fix. Chris Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Fri, 11 Sep 1998 06:57:44 +1000 (EST) From: Michi Henning To: jacobi.PARC@xerox.com cc: jon@floorboard.COM, gscott@inprise.COM, java-rtf@omg.org, orb_revision@omg.org Subject: Re: Problem mapping "global" types in Java mapping On Thu, 10 Sep 1998 jacobi.PARC@xerox.com wrote: > >I would also be open to a suggestion that non-module definitions in the > >global scope be deprecated. It never was a good idea, and probably > >against everyone's style guide anyway. > > Very good idea. When we deprecate this bad feature before we make > it vendor independant, there will be much less old code to fix. I'd be happy to see global definitions disappear. However, this is to risk breaking a lot of existing code. Given the huge arguments we had about something as simple as adding a few keywords to IDL, I don't like your chances of axing the global scope altogether... Cheers, Michi. Return-Path: Date: Fri, 11 Sep 1998 08:05:48 -0700 (PDT) From: Jeff Nisewanger Reply-To: Jeff Nisewanger Subject: Re: Problem mapping "global" types in Java mapping To: jacobi.PARC@xerox.com, michi@dstc.edu.au Cc: jon@floorboard.COM, gscott@inprise.COM, java-rtf@omg.org, orb_revision@omg.org Content-MD5: AqpzntBW2RAbXKnSdcRGbQ== > > >I would also be open to a suggestion that non-module definitions in the > > >global scope be deprecated. It never was a good idea, and probably > > >against everyone's style guide anyway. > > > > Very good idea. When we deprecate this bad feature before we make > > it vendor independant, there will be much less old code to fix. > > I'd be happy to see global definitions disappear. However, this is to > risk breaking a lot of existing code. Given the huge arguments we had > about something as simple as adding a few keywords to IDL, I don't > like your chances of axing the global scope altogether... In the specific case of the Java mapping, the original submission intentionally chose to map global IDL definitions to the unnamed Java package rather than to an arbitrary magic global package such as "idl_global". It was felt at the time that a primary use of global IDL definitions was for simple prototyping and for use by new CORBA developers just learning IDL who don't need to know about the extra conceptual baggage of IDL modules or Java packaging yet. Problems with mapping global IDL into the Java unnamed package primarily come up when using more sophisticated IDL features that such users are unlikely to stumble over. This happens because the "global module" in IDL is namable using :: whereas the similar "unnamed package" in Java is not namable in an equivalent manner. It was felt at the time that mapping global IDL to the Java unnamed package was the simplest, most obvious mapping that was easier to use and understand by the kinds of developers most likely to write globally packaged IDL. At the time, there was a strong push to avoid arbitrary mangling of the identifier naming or packaging of IDL into Java. In fact, earlier Java IDL mappings had used a distinguished "idl_global" named Java package for global IDL. Many people agree that using global IDL definitions in "real" CORBA projects is generally poor style. For the unlikely case where legacy IDL global definitions need to be mapped to something other than the unnamed Java package, the Java mapping already handles this by allowing IDL tools to be used to generate the mapping into a specially named Java package. This can be done either through IDL tool options or through wrapping existing IDL inside a new IDL module and then using the "prefix" pragma to remove that IDL module "prefix" from any generated IDL repository ids in order to retain IIOP wire compatibility. This was all extensively discussed during the original mapping submission process. I don't think we should change it now for the Java IDL mapping unless there is a real demonstrated need. Jeff Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Sat, 12 Sep 1998 07:25:05 +1000 (EST) From: Michi Henning To: Jeff Nisewanger cc: jacobi.PARC@xerox.com, jon@floorboard.COM, gscott@inprise.COM, java-rtf@omg.org, orb_revision@omg.org Subject: Re: Problem mapping "global" types in Java mapping On Fri, 11 Sep 1998, Jeff Nisewanger wrote: > [ Many words omitted... ] > Many people agree that using global IDL definitions in > "real" CORBA projects is generally poor style. > [ ... ] I agree. > [ ... ] > > This was all extensively discussed during the original mapping > submission process. I don't think we should change it now for > the Java IDL mapping unless there is a real demonstrated need. Making definitions in the global scope illegal goes beyond any reasons that may apply to the Java mapping because it would affect all language mappings. I think the main question to ask would be "How much existing code will we break if we do this?" Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html