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:
Asking Glen Johnson to mirror to IBM
---- Additional Comments From chavez.com(prefers email via lnx1138.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?
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))
---- Additional Comments From chavez.com(prefers email via lnx1138.com) 2005-03-04 15:20 EST ------- Reported bug to Java group. Eureka system PMR # is 80678,001,866.
---- Additional Comments From chavez.com(prefers email via lnx1138.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 .
---- Additional Comments From chavez.com(prefers email via lnx1138.com) 2005-03-23 10:58 EST ------- redhat, Any comments on the info provided by Java team or can we close this one? thanks.
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, 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."
IBM, thoughts on Comment #7?
---- Additional Comments From chavez.com(prefers email via lnx1138.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
---- Additional Comments From chavez.com(prefers email via lnx1138.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
changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |REJECTED Resolution| |NOTABUG ------- Additional Comments From khoa.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.
This bug has been rejected by the Lava group. This is working in accordance with the Java spec.
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.