Issue 2096: Issue with Mapping for Constants within an interface (java-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: In Chapter 25 (IDL/Java) of CORBA V2.3-1.3 (Aug 1998), section 25.5.1, "Constants Within An Interface", the text says "Constants declared within an IDL interface are mapped to fields in the Java interface corresponding to the IDL interface". The problem is that there are now two Java interfaces produced for an IDL interface, the Operations interface and the Signature interface. The current client programming model for accessing constants within an interface is to say "t.c" (instead of "tOperations.c"). Therefore, in order to avoid changing the client programming mode, I propose that section 25.5.1 be revised to say that constants within an IDL interface "are mapped to fields in the Java signature interface..." Resolution: closed, no action Revised Text: Actions taken: October 19, 1998: received issue June 4, 1999: closed issue Discussion: This is an editorial issue, that got missed when updating the spec to take into account the split into the signature and operations interfaces. The editor has already made the change. Revised Text: Actions taken: Close, no action End of Annotations:===== Return-Path: From: Rochat Subject: Issue with Mapping for Constants within an interface To: java-rtf@omg.org Date: Sat, 17 Oct 1998 15:12:21 -0500 (CDT) In Chapter 25 (IDL/Java) of CORBA V2.3-1.3 (Aug 1998), section 25.5.1, "Constants Within An Interface", the text says "Constants declared within an IDL interface are mapped to fields in the Java interface corresponding to the IDL interface". The problem is that there are now two Java interfaces produced for an IDL interface, the Operations interface and the Signature interface. The current client programming model for accessing constants within an interface is to say "t.c" (instead of "tOperations.c"). Therefore, in order to avoid changing the client programming mode, I propose that section 25.5.1 be revised to say that constants within an IDL interface "are mapped to fields in the Java signature interface..." Kim ------------------------------- Kim Rochat Component Broker Connector E-Mail: krochat@austin.ibm.com Phone: (512) 823-8792 Tie Line: 793-8792 Date: Thu, 18 Mar 1999 08:04:54 +0000 From: Simon Nash Organization: IBM To: Jeffrey Mischkinsky CC: java-rtf@omg.org Subject: Re: Remaining Issues on Our Plate References: <199903180512.VAA26885@wheel.dcn.davis.ca.us> Jeff, I cannot understand why the last vote would include these old issues and not the new issues that I submitted last week. T sent you email a few days ago asking about voting on these, to which you did not respond. Some of these issues are quite important, such as 2517, 2519, 2531, and 2532. I submitted proposed resolutions for these along with the issues and I do not understand why these are not part of vote 7. I will send my proposed resolutions out again today. Now concerning these old issues, I am OK with closing 1941 and 1964 with no spec change, but not 2096. This is a bug in our current spec! It shows an IDL interface Face containing a constant ALongerOne that maps to: public interface Face { int aLongerOne = (int)(-321L); } and there is no trace of FaceOperations! IBM believes that this example was intended to say public interface FaceOperations { } public interface Face extends FaceOperations { int aLongerOne = (int)(-321L); } and not public interface FaceOperations { int aLongerOne = (int)(-321L); } public interface Face extends FaceOperations { } So my formal proposal to resolve this issue is: In section 25.6.1, change "the Java interface" to "the Java signature interface". In section 25.6.1.1, replace the generated Java code by: package Example; public interface FaceOperations { } public interface Face extends FaceOperations { int aLongerOne = (int)(-321L); } Simon Jeffrey Mischkinsky wrote: > > Hi, > > As is outlined in the Draft RTF Reports, the following issues are > "old". > Either they've been discussed and proposals have been previously > voted > down, or they've moldered for so long that they are now competition > for any of the biology projects currently growing in my > refrigerator. > > Since there has not been a peep out of anyone inspite of my > proddings, I'm > going to propose a quick last vote 7 due Friday Mar 19 at 17:00 PST > to close them with no action. > > If anyone still feels strongly they can refile them, hopefully along > with > a proposed solution and we'll take them up in the next round. > > The issues in question are: > 1941, 1964, and 2096 > > thx, > jeff > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeffm@inprise.com +1 650-358-3049 -- 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 From: Jeffrey Mischkinsky Subject: Re: Remaining Issues on Our Plate To: nash@hursley.ibm.com (Simon Nash) Date: Thu, 18 Mar 1999 02:15:56 -0800 (PST) Cc: java-rtf@omg.org 'Simon Nash' writes: > > Jeff, > I cannot understand why the last vote would include these old issues > and not the new issues that I submitted last week. T sent you email > a few days ago asking about voting on these, to which you did not > respond. I must have missed it in the several million (only a slight exaggeration) of messages. I just searched again for all the simon things and didn't see any. There's something about issues that need attention between you and jishnu, but that's the closest i can find. I apologize. When I posted the draft template of the RTF report with the first Vote, it contained a list of all the outstanding issues. I assumed that it was clear that the work of the RTF was to move all the Still outstandings to the Approved or Defer line. It's what showed for vote 2 also. I gave votes 3, 4, and 5 separate pages just because they were so long. > Some of these issues are quite important, such as 2517, > 2519, 2531, and 2532. I submitted proposed resolutions for these > along with the issues and I do not understand why these are not part > of vote 7. I will send my proposed resolutions out again today. Because the comment deadline was Jan something and I didn't see your mail. Again I apologize, though i'm not sure i would have wanted to include new issues anyway. I started working on the draft report in late February and included all the issues that were outstanding at the time. I refreshed it again after the first week in March. And quite frankly I haven't looked at the issue list in detail since then. I told george yesterday that since he hadn't gotten some of his issues he was signed up for done that they weren't going to be addressed and that he that he could try again next time. I haven't gotten to bed before 2:00 am now for over a week. And i'm still behind on everything. We (Inprise) don't have time to drop everything to process to all these last minute requests. It's just not a good way to do business. Besides which it is highly error prone. I just scheduled my last available time slot tomorrow (actually it later today now) to deal with the last minute proposals on 1980. I literally don't have any more time tomorrow to process more issues. If the RTF wants to consider these issues in the last 24 hours it may, but does not have to. I'd rather spend the time hashing out 1980, which I think is much more significant. > Now concerning these old issues, I am OK with closing 1941 and 1964 > with no spec change, but not 2096. This is a bug in our current > spec! > It shows an IDL interface Face containing a constant ALongerOne that > maps to: > > public interface Face { > int aLongerOne = (int)(-321L); > } > > and there is no trace of FaceOperations! IBM believes that this > example > was intended to say > > public interface FaceOperations { > } > public interface Face extends FaceOperations { > int aLongerOne = (int)(-321L); > } > > and not > > public interface FaceOperations { > int aLongerOne = (int)(-321L); > } > public interface Face extends FaceOperations { > } > > So my formal proposal to resolve this issue is: > > In section 25.6.1, change "the Java interface" to "the Java > signature > interface". > > In section 25.6.1.1, replace the generated Java code by: > > package Example; > public interface FaceOperations { > } > public interface Face extends FaceOperations { > int aLongerOne = (int)(-321L); > } Actually shouldn't Face also extend org.omg.CORBA.portable,IDLEntity as well as org.omg.CORBA.Object ? When we changed the mapping for interface I forgot that we had an interface example lurking in constants. So I didn't change it. Good eyes. So far at least 5 people have missed it. It's only an example. It's not normative. (But confusing!!) Looks like its editorial to me. jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 Date: Thu, 18 Mar 1999 18:36:45 +0000 From: Simon Nash Organization: IBM To: Jeffrey Mischkinsky CC: java-rtf@omg.org Subject: Re: Java 2.4 RTF - new VOTE 6 References: <199903181739.JAA06770@wheel.dcn.davis.ca.us> Jeff, IBM votes Yes on 1941 and 1964. IBM votes No on 2096. This is a clear bug is the spec and needs to be fixed. The fix is trivial and uncontroversial. We should not ship this broken example in the CORBA 2.3 Java chapter. Am I procedurally in order to propose an amendment to your motion on 2096? Simon Jeffrey Mischkinsky wrote: > > They are close no action. If i'd been slightly more awake I might > have sent > Juergen the final edited file, instead of the template file. > > The correct version is on the way. > > jeff > > 'Simon Nash' writes: > > > > Jeff, > > > > Jeffrey Mischkinsky wrote: > > > > > > Hi, > > > As previously threatened, Juergen will be posting what I hope > is the last vote > > > for this round. > > > > > > ftp://www.omg.org/pub/orbrev/votes/java_2_4vote6.html. > > > > > > I set the close of the vote for the RTF's expiration date. > > > Friday 19 MAR at 17:00 PST > > > > > > It just proposes to close the remaining issues on our agenda > that have been > > > around for a while. > > > > > I looked at this and couldn't see anywhere where this was stated. > > Does close mean "close no change" or "close incorporate text"? > > > > > Assuming it passes, we will have addressed all but one of the > issues on > > > our agenda. (We'll see how the 2 pending votes-4 and 5 will > come > > > out.) > > > > > > I've also sent the final vote tally pages for votes 2 and 3 to > Juergen for > > > posting. > > > > > > Good work!! > > > > > > I just finished applying the edits from votes 2 and 3 to the > draft chapter. > > > > > > If someone is ambitious, there are a couple of outstanding > issues sections > > > in the chapter which could probably be addressed editorially > if someone wants > > > to send me some clarifying words. If not, i'm just going to > deep 6 before > > > sending it off the OMG for incorporation. > > > > > > The latest draft (minus the deltas from vote 2 and 3) have > been posted in > > > ftp://ftp.omg.org/pub/orbrev/drafts > > > > > > I forget the filename, but its pretty obvious. > > > > > > later, > > > > > > jeff > > > > > > -- > > > Jeff Mischkinsky > > > jmischki@dcn.davis.ca.us +1 530-758-9850 > > > jeffm@inprise.com +1 650-358-3049 > > > > -- > > 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 > > > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeffm@inprise.com +1 650-358-3049 -- 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