Issue 799: Problems with IDL unions mapped to Java (java-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Significant Summary: Summary: I have found a problem with the Java to IDL mapping (97-03-01) in the area of Unions. The problem is that the Java-idl mapping does not provide any means by which the user can set the value of the union to be one of the non branch members of the enum such as B. Resolution: resolved/closed Revised Text: Actions taken: November 28, 1997: received issue February 19, 1999: closed issue Discussion: End of Annotations:===== Return-Path: X-Sender: andrew@emerald.omg.org Date: Fri, 28 Nov 1997 16:00:07 -0500 To: Juergen Boldt From: John Nichol (by way of Andrew Watson) Subject: Problems with IDL unions mapped to Java [Juergen - please can you log this as a Java mapping issue? Thanks. AJW] I have found a problem with the Java to IDL mapping (97-0301) in the area of Unions. If a union is described as follows enum ABC { A, B, C }; union Test switch ( ABC ) { case A: long X; }; that is an union, with an enum as discriminator, where not all of the members of the enum have branches in the union. This is legal idl and is used heavily in the OMG Trader specification. The problem is that the Java-idl mapping does not provide any means by which the user can set the value of the union to be one of the non branch members of the enum such as B. In the C++-idl mapping gets round this problem by allowing the user to set the discriminator. But in the java-mapping the discriminator is read only and can only be set via calls generated for the union branches. Is this a known bug? I am using Visigenics 3.0 Java with the Orbix Trader 1.0. Thanks John. -- John Nichol SBC Warburg, 2 Finsbury, London, EC2M 2PP Tel: +44 171 5680390 Work: john.nichol@swissbank.com http://w2155791/john_nichol/ Home: john.nichol@virgin.net http://freespace.virgin.net/john.nichol/ Return-Path: X-Sender: jeffm@visigenic.com Date: Mon, 18 May 1998 08:25:22 -0700 To: Roland Turner , java-rtf@omg.org From: "Jeff Mischkinsky" Subject: Re: Unsolved Union problem (Was: Java RTF Proposed IssueResolution - VOTE) References: <355BC1D2.46F05397@visigenic.com> Roland, Thanks for the clear explanation and example illustrating the issue. Since at least one company has supported your position, i'd like to suggest that we proceed as follows. The effect on the specification of closing the issue or deferring is the same. I do however understand that the reason is also important. I suggest that we close the issue without prejudice, saying that the issue has been clarified and that a new issue with the text of Roland's excellent description be opened and that we deal with it during the next RTF. This is a proposal so voters please vote. Make sure you cc me personally at jeffm@visigenic.com with your vote. Visi/Borland/Inprise votes YES. jeff At 06:06 AM 5/15/98 -0800, Roland Turner wrote: >Jeff Mischkinsky wrote: > >> 799: Problems with IDL unions mapped to Java >> >> propose close - This is the intended behavior. One should not be allowed >> to set the discriminator to an illegal value. > >It appears to me that underlying the resolution of 919 and the >outstanding 799 there is a very real problem in that the IDL->Java >mapping as it stands does not correctly implement the IDL Discriminated >Union type in some slightly obscure cases. > >It took me several back and forths with Tim Brinson to grasp this, the >problem appears subtle but real. > >An IDL Discriminated Union has a discriminator of some type. The >discriminator is permitted to take any value allowed by its type - >nothing in the CORBA spec constrains the discriminator's value to be >those of the branch labels present in the union or just one catch-all >default. For this reason, CORBA 2.2 3.8.2 defines a Discriminated >Union's value as follows: > >> It is not required that all possible values of the union >> discriminator be listed in the . The value >> of a union is the value of the discriminator together with >> one of the following: >> >> 0 If the discriminator value was explicitly listed in a case >> statement, the value of the element associated with that >> case statement; >> >> 0 If a default case label was specified, the value of the >> element associated with the default case label; >> >> 0 No additional value. > >> Access to the discriminator and the related element is >> language-mapping dependent. > >The implication is that the following > >union foo switch (int) > { > case 1: string bar; > }; > >declares a union type foo whose value consists either of: > >- the integer value 1 together with a string value for bar > >OR > >- some integer value other than 1. > >So, if I were to create a foo and set the discriminator to 74, someone >receiving this instance from me should be able to discern that the >discriminator's value was set to 74. > >As it stands, the IDL->Java mapping provides for discovering the value >of the discriminator, so if some other ORB sent me a foo with the >discriminator set to 74 I could discern this, but as far as I can tell >from reading the current IDL->Java mapping (CORBA 2.2 - no relevant >changes appear to be present on orbos/98-03-10) there is no way that I >could set the discriminator's value to 74. > >If need be, this can be raised as a new issue (the original issue lacked >a concrete example of something that CORBA requires, but that the >language mapping didn't support), but it might perhaps be more >appropriate to defer the vote until this has been considered. Jeff Mischkinsky email: jeffm@inprise.com Senior Software Architect jeffm@visigenic.com INPRISE Corporation voice: +1(650)312-5158 951 Mariner's Island Blvd. fax:: +1(650)286-2475 San Mateo, CA 94404 web: http://www.inprise.com Return-Path: Date: Fri, 24 Jul 1998 00:36:05 -0700 From: George Scott To: java-rtf@omg.org Subject: Issue 799 proposal - Unions Issue 799 raised a problem with the Java mapping for unions which prevents users from setting the default discriminator to a value they choose. In addition, the value the union uses for the default value is not specified, and hence not portable across ORB vendors. To resolve these issues we propose the following changes: In section 23.8 Mapping for Union (according to Jeff's 3.1a draft) change the following: Add a new bullet after the fifth bullet item: - A modifier method for the branch corresponding to the default label if present Change the fifth paragraph which begins with "If the branch corresponds to the default ..." to the following: "If the branch corresponds to the default case label, then the simple modifier for that branch sets the discriminant to the first available default value starting from a 0 index of the discriminant type. In addition, an extra modifier which takes an explicit discriminator parameter is generated." Change the seventh paragraph which begins with "A default modifier method ..." to the following: "Two default modifier methods, both named __default, are generated if there is no explicit default case label, and the set of case labels does not completely cover the possible values of the discriminant. The simple method taking no arguments and returning void sets the discriminant to the first available default value starting from a 0 index of the discriminant type. The second method takes a discriminator as a parameter and returns void. The value of the union may be left uninitialized." Change the sample generated code for UnionType as follows: Change: public discriminator() { ... } to: public EnumType discriminator() { ... } Change: public void show(int discriminator, byte value) { ... } to: public void show(EnumType discriminator, byte value) { ... } Add the following after the last other() method: public void other(EnumType discriminator, boolean value) { ... } ---------- George Return-Path: Sender: raz@arrakis.com.au Date: Mon, 27 Jul 1998 08:48:26 -0300 From: Roland Turner Organization: - To: java-rtf@omg.org Subject: Re: Issue 799 proposal - Unions References: <35B83965.8F53C58C@inprise.com> George Scott wrote: > Issue 799 raised a problem with the Java mapping for unions > which > prevents users from setting the default discriminator to a value > they choose. In addition, the value the union uses for the > default > value is not specified, and hence not portable across ORB > vendors. > > To resolve these issues we propose the following changes: Excellent. These changes look sensible, although I've not yet tried implementing them. (I believe that you'll find that you've also addressed issue 1385 (?) which was raised in response to my comments a while back, although I had the impression that 799 was already closed and deferred to 1385. Perhaps I've missed a step somewhere.) Your post raised one question in my mind though: > The value of the > union may be left uninitialized." What are the semantics surrounding an unintialised union? Is it the same as a union with the default values for discriminator and relevant fields? If so, are these defaults all specified somewhere? Neither the specification of IDL constucted types, nor the GIOP CDR for unions appears to allow for an uninitialised union. Perhaps some explanatory text is called for? - Raz