Issue 3654: OMG ZIP FILE ISSUES for IDL to Java RTF (01) (java-rtf) Source: Oracle (Dr. Anita Jindal, nobody) Nature: Uncategorized Issue Severity: Summary: We notice the following discrepancies with org.omg.PortableServer package published as part of 00-02-01.tar at the OMG web site. We need to get these issues resolved as soon as possible (especially before the next release of JDK). (1). Following specified interfaces have an extra inheritance from an org.omg.CORBA.Object interface. org.omg.PortableServer.Current.java org.omg.PortableServer.ServantActivator org.omg.PortableServer.ServantLocator e.g., the actual inheritance hierarchy for Current should be: public interface Current extends CurrentOperations, org.omg.CORBA.Current, org.omg.CORBA.portable.IDLEntity whereas, in the OMG published interfaces it is: public interface Current extends org.omg.PortableServer.CurrentOperations, org.omg.CORBA.Current, org.omg.CORBA.portable.IDLEntity, org.omg.CORBA.Object PLS. NOTE AN EXTRA INHERITANCE FROM org.omg.CORBA.Object interface, which should not be there, since there is already an inheritance from org.omg.CORBA.Current. Same for other interfaces. Resolution: Revised Text: Remove inheritance from org.omg.CORBA.Object from org.omg.PortableServer.Current.java org.omg.PortableServer.ServantActivator org.omg.PortableServer.ServantLocator Actions taken: May 30, 2000: received issue January 9, 2001: closed issue Discussion: End of Annotations:===== We notice the following discrepancies with org.omg.PortableServer package published as part of 00-02-01.tar at the OMG web site. We need to get these issues resolved as soon as possible (especially before the next release of JDK). (1). Following specified interfaces have an extra inheritance from an org.omg.CORBA.Object interface. org.omg.PortableServer.Current.java org.omg.PortableServer.ServantActivator org.omg.PortableServer.ServantLocator e.g., the actual inheritance hierarchy for Current should be: public interface Current extends CurrentOperations, org.omg.CORBA.Current, org.omg.CORBA.portable.IDLEntity whereas, in the OMG published interfaces it is: public interface Current extends org.omg.PortableServer.CurrentOperations, org.omg.CORBA.Current, org.omg.CORBA.portable.IDLEntity, org.omg.CORBA.Object PLS. NOTE AN EXTRA INHERITANCE FROM org.omg.CORBA.Object interface, which should not be there, since there is already an inheritance from org.omg.CORBA.Current. Same for other interfaces. Date: Wed, 14 Jun 2000 11:44:10 -0700 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: java-rtf@omg.org Subject: Issue 3654: OMG ZIP FILE ISSUES for IDL to Java RTF (01) Content-Type: multipart/mixed; boundary="------------BF25BF570BD86BDEB0A88447" X-UIDL: 'P2!!HCF!!g"&!!"bfd9 The extra inheritance causes no harm and is definitely not a "serious" issue, but looks like an editorial change to the sources to me. Vijay Issue 3654: OMG ZIP FILE ISSUES for IDL to Java RTF (01)(java-rtf) We notice the following discrepancies with org.omg.PortableServer package published as part of 00-02-01.tar at the OMG web site. We need to get these issues resolved as soon as possible (especially before the next release of JDK). (1). Following specified interfaces have an extra inheritance from an org.omg.CORBA.Object interface. org.omg.PortableServer.Current.java org.omg.PortableServer.ServantActivator org.omg.PortableServer.ServantLocator e.g., the actual inheritance hierarchy for Current should be: public interface Current extends CurrentOperations, org.omg.CORBA.Current, org.omg.CORBA.portable.IDLEntity whereas, in the OMG published interfaces it is: public interface Current extends org.omg.PortableServer.CurrentOperations, org.omg.CORBA.Current, org.omg.CORBA.portable.IDLEntity, org.omg.CORBA.Object PLS. NOTE AN EXTRA INHERITANCE FROM org.omg.CORBA.Object interface, which should not be there, since there is already an inheritance from org.omg.CORBA.Current. Same for other interfaces. Proposal: Remove inheritance from org.omg.CORBA.Object from org.omg.PortableServer.Current.java org.omg.PortableServer.ServantActivator org.omg.PortableServer.ServantLocator [] vijayn5.vcf Date: Wed, 14 Jun 2000 12:12:48 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Issue 3654: OMG ZIP FILE ISSUES for IDL to Java RTF (01) To: vnatarajan@inprise.com Cc: java-rtf@OMG.ORG MIME-Version: 1.0 Content-MD5: ELlSW8oYbILT32V0WKeOiw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: R+Oe9^%N!!F8N!!f!l!! The problem with the OMG ZIP file issues is that Sun needs to put all of the files in omg.zip into the JDK, possibly with a few other files since not all of the required files are present in the zip file, as Jeff pointed out earlier. This means that the JCK tests are written against what we put into the JDK. All Java licensees must pass the JCK tests, and the JCKs tests are extremely picky about all differences in signatures. We need the contents of omg.zip to exactly match what is in the JDK, or else anyone that picks up the zip file may question why the JDK is different. So, issue 3655 (BAD_PARAM on enum from_int) is indeed quite harmless programmatically, but it must be fixed so that the JCK tests are written against the correct signature and the JDK matches the zip file. Also, I would like to see the spec updated to include a requirement that implementations of from_int throw BAD_PARAM if the argument is out of range. Please keep in mind for all of the zip file issues that these are related to the JCK tests in Java, and we want the zip file contents to have exactly the same signatures as the files that we ship in the JDK. We are spending a lot of time reviewing the mapping spec, the zip file, and the code in the JDK to insure that we do not have problems in this area. Thanks, Ken. Date: Wed, 14 Jun 2000 12:59:37 -0700 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ken Cavanaugh , java-rtf@omg.org Subject: Re: Issue 3654: OMG ZIP FILE ISSUES for IDL to Java RTF (01) References: <200006141912.MAA28780@taller.eng.sun.com> Content-Type: multipart/mixed; boundary="------------8F3B0D33131F90F4CA5FB47D" X-UIDL: [-o!!QJ>!!R++e9M(f!! While I would suggest that the problem here is with the JCK's inability to deal with these semantically equivalent cases, I am not too hung up on this. I am OK with the changes. The changes should be straightforward ( and I would suggest editorial) anyway. I am not sure this applies to the constant issue however, as I am guessing the JCK does not test against sources but against the compiled class files which have the right modifiers anyway. Thanks, Vijay Ken Cavanaugh wrote: > The problem with the OMG ZIP file issues is that Sun needs to put > all of the files in omg.zip into the JDK, possibly with a few other > files > since not all of the required files are present in the zip file, as > Jeff > pointed out earlier. This means that the JCK tests are written > against > what we put into the JDK. All Java licensees must pass the JCK > tests, and > the JCKs tests are extremely picky about all differences in > signatures. > > We need the contents of omg.zip to exactly match what is in the JDK, > or > else anyone that picks up the zip file may question why the JDK is > different. > So, issue 3655 (BAD_PARAM on enum from_int) is indeed quite harmless > programmatically, but it must be fixed so that the JCK tests are > written > against the correct signature and the JDK matches the zip file. > Also, I would like to see the spec updated to include a requirement > that > implementations of from_int throw BAD_PARAM if the argument is out > of > range. > > Please keep in mind for all of the zip file issues that these are > related > to the JCK tests in Java, and we want the zip file contents to have > exactly the same signatures as the files that we ship in the JDK. > We > are spending a lot of time reviewing the mapping spec, the zip file, > and the code in the JDK to insure that we do not have problems in > this > area. > > Thanks, > > Ken. [] vijayn8.vcf