Issue 3117: Name mangling scheme broken. (java2idl-rtf)
Source: Borland Software Corporation (Mr. Vijaykumar Natarajan, nobody)
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 operationsin IDL will now be

op__octet (octet x) and op__octet(::_octet);

which is incorrect.

Resolution: closed, no change
Revised Text: 
Actions taken:
December 15, 1999: received issue
May 24, 2001: closed 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.
(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: Tue, 14 Dec 1999 15:02:47 -0800
From: Vijaykumar Natarajan <vijayn@inprise.com>
Reply-To: vijayn@inprise.com
Organization: Inprise Corporation
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: issues@omg.org, java2idl-rtf@omg.org
Subject: Name mangling scheme broken.
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: *4\!!X<`!!T(Ne9$`(!!


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 operationsin IDL will now be

op__octet (octet x) and op__octet(::_octet);

which is incorrect.

Vijay

Date: Sun, 12 Nov 2000 12:50:48 +0000
From: Simon Nash <nash@hursley.ibm.com>
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 3117 proposed resolution
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: 2#Wd9\+,!!54Ud9(Amd9

I will place the following proposed resolution for issue 3117 in vote
2 of
the Java to IDL RTF unless I hear otherwise by close of business
Wednesday.

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.

   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