Bug 150023 - LTC14251- rmic generates stubs in a different way from Sun's rmic
LTC14251- rmic generates stubs in a different way from Sun's rmic
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: java-1.4.2-ibm (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: mark wisner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-01 14:05 EST by Thomas Fitzsimmons
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-14 09:22:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Thomas Fitzsimmons 2005-03-01 14:05:19 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041228 Firefox/1.0 Fedora/1.0-8

Description of problem:
We've run into a problem with IBM's rmic compiler.

IBM's rmic generates these CORBA stubs for the class test.Test:

org/omg/stub/test/_Test_Stub.java
test/_Test_Tie.java

whereas Sun's rmic generates these files:

org/omg/stub/test/_Test_Stub.java
org/omg/stub/test/_Test_Tie.java

This link explains why it's necessary to generate the stubs and ties in
a different package:

http://www.omg.org/issues/issue2804.txt

Why does IBM's rmic not generate the tie in the same location as Sun's
rmic?


Version-Release number of selected component (if applicable):
java-1.4.2-ibm-1.4.2.1-1jpp_2rh

How reproducible:
Always

Steps to Reproduce:
1. see description


Actual Results:  _Test_Tie.java generated in same location as Sun's rmic.


Expected Results:  _Test_Tie.java generated in different location.


Additional info:
Comment 1 mark wisner 2005-03-01 15:27:15 EST
Asking Glen Johnson to mirror to IBM
Comment 2 IBM Bug Proxy 2005-03-04 12:41:42 EST
---- Additional Comments From chavez@us.ibm.com(prefers email via lnx1138@us.ibm.com)  2005-03-04 12:38 EST -------
Thomas,

Could you just give me the output of java -version so I can forward this along
with the problem description to the Java folks? 
Comment 3 Thomas Fitzsimmons 2005-03-04 13:29:51 EST
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)
Classic VM (build 1.4.2, J2RE 1.4.2 IBM build cxia32142-20041210 (JIT
enabled: jitc))
Comment 4 IBM Bug Proxy 2005-03-04 15:28:56 EST
---- Additional Comments From chavez@us.ibm.com(prefers email via lnx1138@us.ibm.com)  2005-03-04 15:20 EST -------
Reported bug to Java group. Eureka system PMR # is 80678,001,866. 
Comment 5 IBM Bug Proxy 2005-03-21 10:10:51 EST
---- Additional Comments From chavez@us.ibm.com(prefers email via lnx1138@us.ibm.com)  2005-03-21 10:06 EST -------
Update from Java team :

In the java to IDL Specification I coud see the following paragraph
under Section 1.4.6 Locating Stubs and Ties :

"The stub class corresponding to an RMI/IDL interface or
implementation class may either be in the same package as its
associated interface or class, or may be further qualified by the
org.omg.stub package prefix. For example, the stub class for an
RMI/IDL interface class a.b.Fred would be named either a.b._Fred_Stub
or org.omg.stub.a.b._Fred_Stub. For an RMI/IDL implementation class
x.y.Z, the tie class would be named x.y._Z_Tie. "

Hence to conclude IBM rmic is working as designed . 
Comment 6 IBM Bug Proxy 2005-03-23 11:01:12 EST
---- Additional Comments From chavez@us.ibm.com(prefers email via lnx1138@us.ibm.com)  2005-03-23 10:58 EST -------
redhat,

Any comments on the info provided by Java team or can we close this one? thanks. 
Comment 7 Thomas Fitzsimmons 2005-03-23 11:55:38 EST
I agree with Comment #5 -- IBM's rmic is working to spec.  However there's still
an issue -- the runtime needs to look in both places for the stub and ties;
first without the org.omg.stub prefix, then with it.  Otherwise stubs compiled
by another vendor's rmic will not be found by IBM's runtime.

I'm not sure what became of this proposal, but on java2idl-rtf@omg.org, Simon
Nash propsed this amendment to the spec which, if implemented, would fix the
issue we're having:

"1. In section 28.4.6 of ptc/99-03-09, replace the second paragraph by the
following:

    The stub class corresponding to an RMI/IDL interface or implementation
class
    may either be in the same package as its associated interface or 
class, or
    may be further qualified by the org.omg.stub package prefix.  For 
example,
    the stub class for an RMI/IDL interface class a.b.Fred, would be named
either
    a.b._Fred_Stub or org.omg.stub.a.b._Fred_Stub.  For an RMI/IDL
implementation
    class x.y.Z, the tie class would be named x.y._Z_Tie.

    When loading a stub class corresponding to an interface or class
    <packagename>.<typename>, the class <packagename>._<typename>_Stub shall
be used
    if it exists; otherwise, the class
org.omg.stub.<packagename>._<typename>_Stub
    shall be used."
Comment 8 Thomas Fitzsimmons 2005-04-06 11:23:01 EDT
IBM,

thoughts on Comment #7?
Comment 9 IBM Bug Proxy 2005-04-06 11:49:26 EDT
---- Additional Comments From chavez@us.ibm.com(prefers email via lnx1138@us.ibm.com)  2005-04-06 11:44 EST -------
Thomas,

I requested an update two days ago from the Java team regarding your last
comment. It looks like I got a reply yesterday which said, 

"I will provide an update at the earliest .
Thanks ,
Janaki."

Hopefully, you'll get a response to your request soon. Thanks for your patience.

regards,
Luciano 
Comment 10 IBM Bug Proxy 2005-04-08 10:21:07 EDT
---- Additional Comments From chavez@us.ibm.com(prefers email via lnx1138@us.ibm.com)  2005-04-08 10:18 EDT -------
Update from Java team:

Update :

I could see at the end of the link
http://www.omg.org/issues/issue2804.txt, the approved changes that have
gone in to the specification as below :

-----------------------------------------------------------------------
" The resolution to issue 2804 approved by the Java to IDL RTF contains
the following revised text for the IDL to Java mapping spec:

3. In section 1.21.4.1 of formal/99-07-53, replace the description of
read_Object by the following:

For read_Object, the clz argument is one of the following:

The Class object for the stub class which corresponds to the type that
is statically expected.  Typically, the ORB runtime will allocate
and  return a stub object of this stub class.

The Class object for the RMI/IDL interface type that is statically
expected.  The ORB runtime must allocate and return a stub object that
conforms to this interface.

4. In section 1.21.4.1 of formal/99-07-53, replace the first
paragraph of the description of read_abstract_interface by the
following:

For read_abstract_interface, the ORB runtime will return either a
value object or a suitable stub object. The specified clz argument is
one of the  following:

The Class object for the stub class which corresponds to the type
that is statically expected.

The Class object for the RMI/IDL interface type that is statically
expected.  If a stub object is returned, it must conform to this
interface.
----------------------------------------------------------------------

Hope this helps .
Please revert back if you have any further queries .

Thanks ,
Janaki 
Comment 11 IBM Bug Proxy 2005-04-08 11:14:52 EDT
changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |REJECTED
         Resolution|                            |NOTABUG




------- Additional Comments From khoa@us.ibm.com  2005-04-08 11:12 EDT -------
Based on our discussion at the SWG call today, we agree to return this bug
as "Working As Designed" (or NotABug).  Thanks. 
Comment 12 mark wisner 2005-04-14 09:22:40 EDT
This bug has been rejected by the Lava group. This is working in accordance with
the Java spec.
Comment 13 Fernando Nasser 2005-04-15 09:27:17 EDT
Although you may have the right claim that you are working as "per spec" and
that this is not a bug _in your implementation_, we still have an issue that
affects both our customer bases, the acceptability of IBM JVMs in the Java
software developing communities etc.  Just ignoring this issue seems
fundamentaly wrong.

We still have an incompatibility between the other major JVM providers (Sun
itself and BEA) and the IBM JVM.  We cannot bring this up with Sun because we
are not J2SE implementors, but you are.  I believe it would be in everyone's
best interest if you continue to pursue a solution for this issue by questioning
Sun why their (reference?) implementation does not follow the specification and
discuss with them how to make your Java environments compatible.

IMHO if I can't build with one provider's SDK and run with another provider's
JMV this is not Java.  Java builds once and run's everywhere.  There is not
supposed to be a restriction on obtaining all Java pieces from the same provider
-- this is what the Java licensing terms are supposed to prevent.

Regards to all.

Note You need to log in before you can comment on or make changes to this bug.