Issues for IDL/Java Revision Task Force mailing list

To comment on any of these issues, send email to [email protected]. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to [email protected].

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 632: Spec insufficient in section 5.2.1 - Reserved Names Jira Issue I2JAV11-52
Issue 799: Problems with IDL unions mapped to Java Jira Issue I2JAV11-34
Issue 888: Section 5.14 and 6.11 IDL/Java Language mapping Jira Issue I2JAV11-35
Issue 890: Add missing UnknownUserException Jira Issue I2JAV11-36
Issue 891: ImplementationDef should be an abstarct class Jira Issue I2JAV11-37
Issue 892: create_list semantics not well defined Jira Issue I2JAV11-38
Issue 893: delegate field in ObjectImpl should be transient Jira Issue I2JAV11-39
Issue 894: input/output streams should extend java.io.streams Jira Issue I2JAV11-40
Issue 895: _orb() is missing from ObjectImpl Jira Issue I2JAV11-41
Issue 896: Make all basic Holders implement Streamable Jira Issue I2JAV11-42
Issue 897: Fix any"s to have implement copy semantics Jira Issue I2JAV11-43
Issue 898: Clarify the use of return_value() before invoke() in DII Jira Issue I2JAV11-44
Issue 899: Clarify exact list of methods available on singleton orb Jira Issue I2JAV11-45
Issue 907: Current mapped incorrectly in Java language mapping Jira Issue I2JAV11-46
Issue 908: CORBA::DATA::CONVERSION exception for IDL types wchar/wstring Jira Issue I2JAV11-47
Issue 909: IDL/Java language mapping, section 5.14, 6.11 Jira Issue I2JAV11-48
Issue 919: Problem with IDL --> Java mapping for Unions Jira Issue I2JAV11-49
Issue 1090: Reserved names Jira Issue I2JAV11-50
Issue 1142: POA_Interface bug Jira Issue I2JAV11-53
Issue 1143: Chapter 9.8.1 Local stubs-bug Jira Issue I2JAV11-54
Issue 1167: Any.insert_Object() Jira Issue I2JAV11-55
Issue 1242: Any"s and Exceptions Jira Issue I2JAV11-56
Issue 1381: No INV_NO_RESPONSE possible in Java DII Jira Issue I2JAV11-51
Issue 1385: Discriminated Union value issue Jira Issue I2JAV11-57
Issue 1536: Helper classes are only for user defined IDL types Jira Issue I2JAV11-58
Issue 1577: Section 7.1.3 of Java to IDL mapping Jira Issue I2JAV11-59
Issue 1583: org.omg.CORBA.UserException class not specified Jira Issue I2JAV11-60
Issue 1586: Callback issue Jira Issue I2JAV11-61
Issue 1672: Does object reference == ObjectImpl? Jira Issue I2JAV11-62
Issue 1696: Proposed change to orb.init Jira Issue I2JAV11-63
Issue 1701: Mapping of IDL constants to Java Jira Issue I2JAV11-64
Issue 1703: orb.properties file issue Jira Issue I2JAV11-65
Issue 1704: Proposed change sto IDL/Java mapping Jira Issue I2JAV11-66
Issue 1705: Add Any.extract_Streamable() Jira Issue I2JAV11-67
Issue 1722: New stream based stubs and location forward Jira Issue I2JAV11-68
Issue 1724: OutputStream semantics question Jira Issue I2JAV11-69
Issue 1730: Changes to Java fixed type mapping Jira Issue I2JAV11-70
Issue 1731: Java mapping"s use of _this() Jira Issue I2JAV11-71
Issue 1732: Changes to Java interface mapping Jira Issue I2JAV11-72
Issue 1734: Mapping of IDL names that clash with java.lang.Object methods Jira Issue I2JAV11-73
Issue 1737: Compiler-readable code Jira Issue I2JAV11-74
Issue 1738: Object._request variants are unspecified Jira Issue I2JAV11-75
Issue 1739: Local stubs Jira Issue I2JAV11-76
Issue 1741: Java RTF issue Jira Issue I2JAV11-77
Issue 1746: Conext support in Java Jira Issue I2JAV11-78
Issue 1750: 2 IDL->Java issues on the singleton ORB (02) Jira Issue I2JAV11-79
Issue 1752: mapping of IDL enumerations to java Jira Issue I2JAV11-80
Issue 1754: Proposal to change get_value_def in Java mapping Jira Issue I2JAV11-81
Issue 1795: final methods on ObjectImpl Jira Issue I2JAV11-82
Issue 1897: Evolving the org.omg.* APIs Jira Issue I2JAV11-83
Issue 1941: Problem mapping "global" types in Java mapping Jira Issue I2JAV11-84
Issue 1942: Need overloaded write_Value method on OutputStream Jira Issue I2JAV11-85
Issue 1961: Java Mapping for interfaces -- Proposal Jira Issue I2JAV11-86
Issue 1964: Creating TypeCodes safely in java Jira Issue I2JAV11-87
Issue 1980: Updated proposal for the OBV Java mapping Jira Issue I2JAV11-88
Issue 1993: create_lname & create_lname_context Jira Issue I2JAV11-89
Issue 1994: Local stubs proposal Jira Issue I2JAV11-90
Issue 2079: Potential problem with Java Mapping ORB init for Applet Jira Issue I2JAV11-91
Issue 2096: Issue with Mapping for Constants within an interface Jira Issue I2JAV11-92
Issue 2228: typedefs in IDl when generating Java code Jira Issue I2JAV11-93
Issue 2233: Helper "narrow" exception clarification Jira Issue I2JAV11-94
Issue 2251: Java LocalStub Jira Issue I2JAV11-95
Issue 2255: Proposal for persistent valuetypes Jira Issue I2JAV11-96
Issue 2256: PSS requiremnets for the ObV/Java mapping Jira Issue I2JAV11-97
Issue 2462: BAD_PARAM issue Jira Issue I2JAV11-98
Issue 2514: PortableServer Servant issue Jira Issue I2JAV11-99
Issue 2517: orb.properties search should include home directory Jira Issue I2JAV11-100
Issue 2518: Incorrect search order for ORB implementation class name Jira Issue I2JAV11-101
Issue 2519: Need SerializableHolder class Jira Issue I2JAV11-102
Issue 2520: Standard properties should include initial host and port Jira Issue I2JAV11-10
Issue 2528: Mapping Messaging sendc_ (and sendp_) methods to Java Jira Issue I2JAV11-11
Issue 2531: Serializable objects in Anys need reference semantics Jira Issue I2JAV11-103
Issue 2532: Mapping of AbstractBase and abstract interfaces Jira Issue I2JAV11-12
Issue 2540: _servant_postinvoke Jira Issue I2JAV11-104
Issue 2550: Dealing with reserved suffixes (e.g. POA) Jira Issue I2JAV11-105
Issue 2608: Java - Mapping for Struct issue Jira Issue I2JAV11-106
Issue 2609: Issues with ObjectImpl implementations Jira Issue I2JAV11-107
Issue 2647: Modification of Constant Mapping Jira Issue I2JAV11-108
Issue 2661: Valuetype packages Jira Issue I2JAV11-109
Issue 2721: DII and SystemException semantics Jira Issue I2JAV11-13
Issue 2770: Java substitutability issue: value instance -> interface type Jira Issue I2JAV11-14
Issue 2823: Java mapping for PolicyType... Jira Issue I2JAV11-110
Issue 2889: Should Any.extract_string work for bounded strings? Jira Issue I2JAV11-15
Issue 2979: Java SystemException should contain nested exception field Jira Issue I2JAV11-16
Issue 3068: Messaging sendc and sendp missing from portability interfaces Jira Issue I2JAV11-1
Issue 3204: ORB Init problems Jira Issue I2JAV11-17
Issue 3209: Illegal return statement Jira Issue I2JAV11-111
Issue 3267: How to create marshalel data of java.lang.Throwable instance? Jira Issue I2JAV11-18
Issue 3320: Java language mapping: Tie classes for local interfaces. Jira Issue I2JAV11-19
Issue 3323: Need clarification on custructor(s) for stream-based stubs/skeletons Jira Issue I2JAV11-112
Issue 3410: IDL/Java: methods marked final in PortableServer.Servant Jira Issue I2JAV11-113
Issue 3570: org.omg.CORBA.portable.UnknownException does not have all constructors Jira Issue I2JAV11-114
Issue 3575: Custom marshal does not work for certain valuetypes Jira Issue I2JAV11-20
Issue 3633: Request clarification for use of alias typecodes in typedef helper classes Jira Issue I2JAV11-21
Issue 3643: Description of ORB.init parameters insufficient Jira Issue I2JAV11-2
Issue 3654: OMG ZIP FILE ISSUES for IDL to Java RTF (01) Jira Issue I2JAV11-115
Issue 3655: OMG ZIP FILE ISSUES for IDL to Java RTF (02) Jira Issue I2JAV11-116
Issue 3656: OMG ZIP FILE ISSUES for IDL to Java RTF (03) Jira Issue I2JAV11-117
Issue 3657: OMG ZIP FILE ISSUES for IDL to Java RTF (04) Jira Issue I2JAV11-118
Issue 3658: OMG ZIP FILE ISSUES for IDL to Java RTF (05) Jira Issue I2JAV11-119
Issue 3659: OMG ZIP FILE ISSUES for IDL to Java RTF (06) Jira Issue I2JAV11-120
Issue 3665: Java ORB Id Jira Issue I2JAV11-3
Issue 3668: Possible problem with IDL to Java mapping of fixed-point decimal types Jira Issue I2JAV11-121
Issue 3669: Enum mapping issue Jira Issue I2JAV11-122
Issue 3686: How can org.omg.CORBA.portable.InputStream.read_fixed possibly work? Jira Issue I2JAV11-123
Issue 3707: Need clarification on custructor(s) for stream-based Jira Issue I2JAV11-124
Issue 3750: SystemExceptionHelper missing Jira Issue I2JAV11-125
Issue 3788: Mapping for Sequences -> <sequence_class>Holder Jira Issue I2JAV11-126
Issue 3794: IDLEntity interface has to be public. Jira Issue I2JAV11-127
Issue 3795: Incorrect method declaration in CORBA_2_3/portable/InputStream.java and Out Jira Issue I2JAV11-128
Issue 3801: policy_type should map to a Java int. Jira Issue I2JAV11-129
Issue 3818: Operations signatures include throws clauses on system exceptions. Jira Issue I2JAV11-130
Issue 3819: Issues with Java mapping of Typecode Jira Issue I2JAV11-131
Issue 3903: mapping for Request.target will not compile Jira Issue I2JAV11-132
Issue 3904: ptc/00-01-08: Conflict 1.15.1 paragraph 2 - 1.19.2 paragraph 2 Jira Issue I2JAV11-133
Issue 3911: Incomplete union mapping Jira Issue I2JAV11-134
Issue 3912: How is an ORB to determine whether or not it is in an applet context? Jira Issue I2JAV11-135
Issue 3913: Vendor-specific ORB_init methods Jira Issue I2JAV11-136
Issue 3923: #pragma prefix issue Jira Issue I2JAV11-137
Issue 3946: CompletionStatus needs to implement org.omg.CORBA.portable.IDLEntity Jira Issue I2JAV11-138
Issue 3979: IDL to Java Spec Issue : need to add SystemExceptions introduced in CORBA 2 Jira Issue I2JAV11-139
Issue 3994: Valuetype unmarshalling Jira Issue I2JAV11-22
Issue 3995: Copying boxed valuetypes on local calls Jira Issue I2JAV11-23
Issue 4009: Union exceptions Jira Issue I2JAV11-24
Issue 4010: Should valuetype helper insert/extract make copies? Jira Issue I2JAV11-25
Issue 4013: Usage of ExceptionDetailMessage service context Jira Issue I2JAV11-26
Issue 4057: Displaying SystemExceptions Jira Issue I2JAV11-27
Issue 4059: When to honor the servant delegate in POA? Jira Issue I2JAV11-28
Issue 4064: Any extract operations for tk_abstract_interface Jira Issue I2JAV11-29
Issue 4076: System Exceptions REBIND, TIMEOUT, BAD_QOS Jira Issue I2JAV11-30
Issue 4158: publication of messaging / unchecked_narrow Jira Issue I2JAV11-31
Issue 4271: IDL/Java issue, Mapping for IDL enum Jira Issue I2JAV11-32
Issue 4286: Clarification of serialization of Anys and Typecodes Jira Issue I2JAV11-33
Issue 4323: local interface mapping underspecified Jira Issue I2JAV11-140
Issue 4549: Missing elements of the local mapping Jira Issue I2JAV12-14
Issue 4624: support for local objects Jira Issue I2JAV12-15
Issue 4699: is_a support in Java for local interfaces Jira Issue I2JAV12-16
Issue 4701: Colocated calls in Java Jira Issue I2JAV12-17
Issue 4710: Mapping for Character and String Types Jira Issue I2JAV12-10
Issue 4741: New issue on register_initial_reference Jira Issue I2JAV12-18
Issue 4748: Naming issues for new ORB methods Jira Issue I2JAV12-19
Issue 4749: New issue: Error in resolution of issue 4699 Jira Issue I2JAV12-20
Issue 4750: Make CORBA_2_3.ORB methods available in CORBA.ORB Jira Issue I2JAV12-21
Issue 4792: exceptions on valuetype initializers Jira Issue I2JAV12-22
Issue 4793: attribute exceptions Jira Issue I2JAV12-23
Issue 4794: OMG Java Language Mapping and the use of Java null Jira Issue I2JAV12-24
Issue 4802: Should a holder class for ProtectingEntity get generated Jira Issue I2JAV12-11
Issue 4804: section 1.18.2 of the OMG IDL mapping document ptc/00-01-08 Jira Issue I2JAV11-141
Issue 4805: Java mapping changes for core issue 4337 Jira Issue I2JAV11-152
Issue 5108: J2EE ORB Socket Factory API Jira Issue I2JAV11-4
Issue 5465: Default UnknownException behavior Jira Issue I2JAV12-12
Issue 5468: Anys obtained using the singleton ORB Jira Issue I2JAV12-13
Issue 5586: interfaces that do not extend org.omg.CORBA.portable.ValueBase Jira Issue I2JAV11-142
Issue 5595: Should javadoc statement be removed or should method be removed? Jira Issue I2JAV11-143
Issue 5615: Streaming Interfaces Jira Issue I2JAV11-144
Issue 5638: Typo on getRaises and setRaises in formal/2002-08-05 Jira Issue I2JAV11-145
Issue 5646: Java source code for org.omg.PortableServer.POAOperations Jira Issue I2JAV11-5
Issue 5693: POA changes missing in Java source archive Jira Issue I2JAV11-146
Issue 5694: What is the IDL for ServiceInformation and/or what is correct Java mapping? Jira Issue I2JAV11-147
Issue 5696: Package name issue Jira Issue I2JAV11-148
Issue 5728: How does a Java ORB implement a write_fixed/read_fixed? Jira Issue I2JAV11-149
Issue 5782: Missing operations on org.omg.CORBA.Object Jira Issue I2JAV11-150
Issue 5783: Stub handling of UnknownException Jira Issue I2JAV11-151
Issue 5806: response_expected value for colocated invocations Jira Issue I2JAV13-10
Issue 5893: definition of FixedHolder should have been removed Jira Issue I2JAV11-6
Issue 7846: wrong enumeration value for SetOverrideType Jira Issue I2JAV11-7
Issue 9795: section 1.21.3 IDLEntity Jira Issue I2JAV11-8
Issue 15709: Specification does not provide mapping spec for Home, Component and Event Jira Issue I2JAV11-9

Issue 632: Spec insufficient in section 5.2.1 - Reserved Names (java-rtf)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:
Summary: Reserved words seen as IDL identifiers be prepended by an underscore. Insufficient for Holder, Helper, Package in case where two or three of these strings appear in single identifier 

Resolution: Clarify the IDL Name conflict resolution rules to resolve this case. Also change the naming rules
Revised Text: Solution suggested: extend rule in section 5.2.1 to require one underscore to be prepended for each suffix on the nameAdd the following sentence to paragraph 2 in Section 25.1 "Names":
Actions taken:
July 23, 1997: received issue
May 18, 1998: Deferred
June 4, 1999: closed issue

Discussion:


Issue 799: Problems with IDL unions mapped to Java (java-rtf)

Click
here for this issue's archive.
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:


Issue 888: Section 5.14 and 6.11 IDL/Java Language mapping (java-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Summary: In the class definition for Any there is only    insert_Streamable(...), but no    extract_Streamable(...).  How do you extract    streamables?    

Resolution: duplicate, issue closed
Revised Text:
Actions taken:
January 7, 1998: received issue
May 19, 1998: closed issue, duplicate of issue 909

Discussion:


Issue 890: Add missing UnknownUserException (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary:  

Resolution: closed issue, resolved
Revised Text:
Actions taken:
January 12, 1998: received issue
May 19, 1998: closed issue

Discussion:


Issue 891: ImplementationDef should be an abstarct class (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary:  

Resolution: closed issue, resolved
Revised Text:
Actions taken:
January 12, 1998: received issue
May 19, 1998: closed issue

Discussion:


Issue 892: create_list semantics not well defined (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: create_list semantics are not well-defined in CORE and hence Java          Language Mapping    

Resolution: resolved/closed
Revised Text:
Actions taken:
January 12, 1998: received issue
May 19, 1998: closed issue

Discussion:
 received issue


Issue 893: delegate field in ObjectImpl should be transient (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary:  

Resolution: closed issue
Revised Text:
Actions taken:
January 12, 1998: received issue
May 19, 1998: closed issue

Discussion:


Issue 894: input/output streams should extend java.io.streams (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary:  

Resolution: closed issue, resolved
Revised Text:
Actions taken:
January 12, 1998: received issue
May 19, 1998: closed issue

Discussion:


Issue 895: _orb() is missing from ObjectImpl (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary:  

Resolution: closed issue, resolved
Revised Text:
Actions taken:
January 12, 1998: received issue
May 19, 1998: closed issue

Discussion:


Issue 896: Make all basic Holders implement Streamable (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary:  

Resolution: proposal approved, issue closed
Revised Text:
Actions taken:
January 12, 1998: received issue
February 19, 1999: closed issue

Discussion:


Issue 897: Fix any"s to have implement copy semantics (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Issue: Fix any"s to have implement copy semantics, similar to C++    

Resolution: closed
Revised Text: closed issue
Actions taken:
January 12, 1998: received issue
May 19, 1998: closed issue

Discussion:
 closed issue


Issue 898: Clarify the use of return_value() before invoke() in DII (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Clarify the use of return_value() before invoke() in DII.          When using dii in Java (in portable stubs), it should be possible          to call return_value() before invoke() in order to get the Any           that will be associated with the return. It is then possible          to insert a streamable, which when combined with fixing copy          semantics for any"s, will enable a big performance improvement.     

Resolution: closed
Revised Text:
Actions taken:
January 12, 1998: received issue
May 19, 1998: closed issue

Discussion:


Issue 899: Clarify exact list of methods available on singleton orb (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary:  

Resolution: closed issue
Revised Text:
Actions taken:
January 12, 1998: received issue
May 19, 1998: closed issue

Discussion:


Issue 907: Current mapped incorrectly in Java language mapping (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:
Summary:     In 2.1 current became a regular IDL interface, so its mapping needs to   change.    Proposed Change:       delete section 23.16.14 on current    

Resolution: closed issue
Revised Text:
Actions taken:
January 15, 1998: received issue
May 19, 1998: closed issue

Discussion:
 closed issue


Issue 908: CORBA::DATA::CONVERSION exception for IDL types wchar/wstring (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: This specification defines CORBA::DATA_CONVERSION exception for IDL   types char/string, but does not define same exception for IDL types   wchar/wstring. However, in the CORBA 2.1, IDL types wchar/wstring can   handle any codeset beside Unicode (see section "10.7 Code Set Conversion"   in CORBA 2.1) as well as IDL types char/string. Therefore, data   conversion error may occur between IDL types wchar/wstring and Java   types char/java.lang.String.    

Resolution: closed issue
Revised Text:
Actions taken:
January 16, 1998: received issue
May 19, 1998: closed issue

Discussion:


Issue 909: IDL/Java language mapping, section 5.14, 6.11 (java-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Summary: In the class definition for Any there is only    insert_Streamable(...), but no    extract_Streamable(...).  How do you extract    streamables?    

Resolution: closed issue
Revised Text:
Actions taken:
January 7, 1998: received issue
May 18, 1998: Deferred
July 30, 1998: closed issue

Discussion:


Issue 919: Problem with IDL --> Java mapping for Unions (java-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: I have found what appears to be a short coming of the IDL to Java   mapping for unions.     Reading the CORBA V2.0 (July 1995) on pages 3-23 and 3-24 it indicates   unions can have a value of the discriminator where there is not a case   that matches the discriminator.  The Trader Service specification has a   great example of when this may be needed (in fact we are following this   pattern in PIDS). The Java mapping for unions does not have a method or constructor for   setting the discriminator when the discriminator does not correspond to   at least one case label.     

Resolution: closed issue
Revised Text:
Actions taken:
January 23, 1998: received issue
May 19, 1998: closed issue

Discussion:


Issue 1090: Reserved names (java-rtf)

Click
here for this issue's archive.
Nature:
Severity:
Summary:
Summary:  The list of java keywords provided is an old one.   >     Should this be updated to the following list?   >       abstract boolean break   >       byte byvalue case cast catch char   >       class const continue default do double   >       else extends final finally float for   >       future generic goto if implements import   >       inner instanceof int interface long native   >       new null operator outer package private   >       protected public rest return short static   >       super switch synchronized this throw throws   >       transient try var void volatile while    

Resolution: closed issue
Revised Text:
Actions taken:
March 20, 1998: received issue
February 19, 1999: closed issue

Discussion:


Issue 1142: POA_Interface bug (java-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: Chapter 5.2.4   class POA_<interface_name> is supposed to implement    <interface_name>Operations.      However neither specification nor the example contain any     operations method.  The class also are not specified abstract.       

Resolution: closed issue
Revised Text:
Actions taken:
April 16, 1998: received issue
May 18, 1998: closed issue

Discussion:


Issue 1143: Chapter 9.8.1 Local stubs-bug (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Chapter 9.8.1   Says "Local stubs are defined to be direct base classes of remote stubs"   Does it matter?  It is the opposite way as proposed in the drawing in   chapter 6.4         MORE FAR-FETCHED IDEA      What if the Operations interface would not contain the inheritance   relationship?  Wouldn"t that be a step in the direction of being able   to implement independent interfaces with one class.  (To be   functional this would need matching changes in the tie class)     

Resolution: closed issue
Revised Text:
Actions taken:
April 16, 1998: received issue
May 18, 1998: closed issue

Discussion:


Issue 1167: Any.insert_Object() (java-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: In Section 23.13, the signature for insert_Object() is given as,      // throw excep when typecode inconsistent with value   abstract public void insert_Object(                       org.omg.CORBA.Object o, org.omg.CORBA.TypeCode t)                                   throws org.omg.CORBA.MARSHAL;      Does this mean if an incorrect TypeCode is passed, eg. tk_short, that a   MARSHAL   Exception must be thrown or could a BAD_PARAM Exception be thrown.    

Resolution: closed issue
Revised Text:
Actions taken:
April 22, 1998: received issue
May 18, 1998: closed issue

Discussion:


Issue 1242: Any"s and Exceptions (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: In Section 23.13, the signature for insert_Object() is given as,      // throw excep when typecode inconsistent with value   abstract public void insert_Object(                       org.omg.CORBA.Object o, org.omg.CORBA.TypeCode t)                                   throws org.omg.CORBA.MARSHAL;      Does this mean if an incorrect TypeCode is passed, eg. tk_short, that a   MARSHAL Exception must be thrown or could a BAD_PARAM Exception   be thrown.      Also, I assume read_value() is meant to insert a complex IDL type into   an Any ?   If so, read_value() is supposed to throw a MARSHAL Exception if the   typecode   is inconsistent with the value. Does this mean that if a short has been   written to the   stream, but the stream is passed with a tk_sequence typecode, then an   Exception   should be thrown by read_value() ?.    

Resolution: closed issue
Revised Text:
Actions taken:
April 27, 1998: received issue
May 18, 1998: closed issue

Discussion:


Issue 1381: No INV_NO_RESPONSE possible in Java DII (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: There is no Flags argument in the create_request operations   as mapped from PIDL to Java.  This means that there is no   way to create a request with INV_NO_RESPONSE.  Therefore,   you cannot do oneway invocations in Java DII without the ORB    having to consult the Interface Repository (clearly   unnacceptable).    

Resolution: closed/resolved
Revised Text:
Actions taken:
May 18, 1998: received issue
July 30, 1998: closed issue

Discussion:


Issue 1385: Discriminated Union value issue (java-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: 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, section 3.8.2 defines a Discriminated   Union"s value as follows:  <example>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.       

Resolution: closed issue
Revised Text:
Actions taken:
May 19, 1998: received issue
July 30, 1998: closed issue

Discussion:


Issue 1536: Helper classes are only for user defined IDL types (java-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
Summary: The Java Language Mapping mandates Helper classes for user defined IDL   types but does not say Helper classes are ONLY for user defined IDL types.   Please let us all know whether the ObjectHelper class is standard or not.    

Resolution: closed issue
Revised Text:
Actions taken:
June 23, 1998: received issue
July 30, 1998: closed issue

Discussion:


Issue 1577: Section 7.1.3 of Java to IDL mapping (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Section 7.1.3 of the Java to IDL mapping specifies new methods   _request, _invoke, and _releaseReply to be added to both    org.omg.CORBA.portable.ObjectImpl and org.omg.CORBA.portable.Delegate.      There is an existing convention that methods on ObjectImpl have   leading underscores but the corresponding methods on Delegate do not.      I propose that the new methods on Delegate be named request, invoke,   and releaseReply to confirm to this existing convention.    

Resolution: closed issue
Revised Text:
Actions taken:
June 24, 1998: received issue
July 30, 1998: closed issue

Discussion:


Issue 1583: org.omg.CORBA.UserException class not specified (java-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: The current mapping does not specify the org.omg.CORBA.UserException   class. I propose the mapping below. All generated user exception    constructors should then pass the exception"s id to the UserException   string constructor. The toString() method on the exception will then    output the Exception"s type id.      package org.omg.CORBA;      public abstract class UserException extends java.lang.Exception    {     public UserException()     {     }        public UserException(String r)     {       super(r);     }   }       

Resolution: closed issue
Revised Text:
Actions taken:
June 26, 1998: received issue
July 30, 1998: closed issue

Discussion:


Issue 1586: Callback issue (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: IIOP only permits requests to flow in the direction that the underlying   connection was opened. The Java sandbox only allows outbound   connections. Consequently we are left with a situation where applets can   only ever make outbound requests, callback objects can never be   registered. For any sort of asynchronous notification pattern, this is a   problem. (There is an obvious workaround with blocking calls and a   waiting thread, but this sort of interaction should never be required of   application developers.)      Most products provide a means to handle callbacks in this situation,   presumably via non-standard mechanisms, I am yet to explore how.      It would seem that, from the point of view of those involved in this   RTF, a standardised means to handle reverse calls over IIOP would be   beneficial.      Is my reasoning flawed? Is there a revision going on elsewhere to   address this? Is there interest in standardising this?    

Resolution: closed issue
Revised Text:
Actions taken:
June 26, 1998: received issue
July 30, 1998: closed issue

Discussion:


Issue 1672: Does object reference == ObjectImpl? (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The issue is whether or not code that calls the _this_object method   of the org.omg.PortableServer.Servant class (which is declared to   return an org.omg.CORBA.Object type) can assume that the result   of calling _this_object can be safely cast to ObjectImpl.      The decision of the RTF was that this is a safe assumption, but no   change is necessary to the spec because it is already clearly stated   that all stubs (object references) must be subclasses of ObjectImpl.                         

Resolution: closed issue
Revised Text:
Actions taken:
July 13, 1998: received issue
July 30, 1998: closed issue

Discussion:


Issue 1696: Proposed change to orb.init (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: How should ORB.init() be fixed?      ORB.init() should try to find an ORB class in the following order:        1. Try loading the class using Class.forName(String className) --  this is        to take into account the possibility that the ORB implementation class        is in the core (for example: com.sun.CORBA.iiop.ORB). If that fails,     2. Try loading the class using Class.forName(String className, boolean        initialize, ClassLoader cl), where cl ==        ClassLoader.getSystemClassLoader(). In the case of an applet, cl ==        applet.getClass().getClassLoader().      For sophisticated users who might have a well-behaved ClassLoader that knows   how to load the ORB implementation, it might be necessary to have a new   ORB.init() that takes a ClassLoader as an argument. For example:           ORB.init(String[] args, Properties props, ClassLoader cl);      In this case, ORB.init() would load the class using the class loader that   was passed by the user instead of the system class loader.    

Resolution: closed issue
Revised Text:
Actions taken:
July 20, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1701: Mapping of IDL constants to Java (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The IDL to Java mapping specifies that IDL constants are mapped   to public static final fields within a Java interface.  Examples   are shown that include "public static final" modifiers for these   fields.      The Java Language Specification (Gosling/Joy/Steele) states in   section 9.3 that "Every field declaration in the body of an   interface is implicitly public, static, and final.  It is permitted,   but strongly discouraged as a matter of style, to redundantly   specify any or all of these modifiers for such fields."      I propose that the text and examples be changed to remove the    explicit "public static final" modifiers.    

Resolution: closed issue
Revised Text:
Actions taken:
July 20, 1998: received issue
July 30, 1998: closed issue

Discussion:


Issue 1703: orb.properties file issue (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary:    The search order followed by ORB.init when looking for the names   of the ORB and ORB singleton classes does not allow a user to   install a specified ORB as the default ORB, overriding the    hardcoded default behavior.  It is possible to override the   hardcoded default by setting system properties, but this requires   running the java command with an explicit -D option every time,    which is awkward.      I propose that an additional step be added to this search order,   between "check in the System properties" and "fall back on    hardcoded default behavior". 

Resolution: closed issue
Revised Text:
Actions taken:
July 20, 1998: received issue
July 30, 1998: closed issue

Discussion:


Issue 1704: Proposed change sto IDL/Java mapping (java-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: The following proposal describes changes to the IDL/Java mapping   that will allow values to be marshalled and demarshalled more   efficiently in both the "forward mapping" and "reverse mapping"   cases.  It also allows other IDLEntity types to be marshalled and   demarshalled more efficiently in the reverse mapping case, and it   fixes some problems in the existing spec with marshalling and   demarshalling values and boxed strings.     

Resolution: closed issue
Revised Text:
Actions taken:
July 20, 1998: received issue
July 30, 1998: closed issue

Discussion:


Issue 1705: Add Any.extract_Streamable() (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: 	org.omg.CORBA.portable.Streamable extract_Streamable();       As the name of the operation suggests it allows any Streamable    value inserted into an Any using insert_Streamable() to be    extracted. A BAD_INV_ORDER exception will be thrown if the    operation is invoked on an Any that doesn"t already contain a    Streamable.       The addition of this method allows for a more efficient Any    implementation especially when collocation and DII/DSI is in use.           

Resolution: closed issue
Revised Text:
Actions taken:
July 20, 1998: received issue
July 30, 1998: closed issue

Discussion:


Issue 1722: New stream based stubs and location forward (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The new portable stream-based stubs for the Java language mapping   do not properly handle location forwards properly.  The ORB must   be able to give some indication to the ORB that it must remarshal   in case the ORB receives a locate forward or object forward message.   The remarshalling is required because the object key in the request   message may have changed and the alignment will be incorrect.    

Resolution: closed issue
Revised Text:
Actions taken:
July 22, 1998: received issue
July 30, 1998: closed issue

Discussion:


Issue 1724: OutputStream semantics question (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: When an InputStream is created by an OutputStream, is it permitted to   continue to write anything more to the OutputStream?      If this is not permitted, we should presumably lock out the OutputStream   and throw an exception if another write_X is attempted after the    create_input_stream.      If this is permitted, we need to say whether or not the things written   to the OutputStream after the InputStream is created show up in the   InputStream or not.    

Resolution: closed issue
Revised Text:
Actions taken:
July 22, 1998: received issue
July 30, 1998: closed issue

Discussion:


Issue 1730: Changes to Java fixed type mapping (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The current mapping for fixed type was written with the intention   of supporting JDK 1.0.2 as well as JDK 1.1.  Recent changes in the   Java RTF and other recently adopted submissions (Java to IDL) have   introduced a JDK 1.1 requirement in the Java mapping which make   it possible to implement certain operations on fixed types in a   type safe manner instead of the current specification.       

Resolution: closed issue
Revised Text:
Actions taken:
July 24, 1998: received issue
July 30, 1998: closed issue

Discussion:


Issue 1731: Java mapping"s use of _this() (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The current Java mapping for the POA defines semantics for _this()   (also known as _this_object()) which are consistent with the C++   mapping.  However, the current specification for    org.omg.PortableServer.Servant does not support those semantics.       

Resolution: closed issue
Revised Text:
Actions taken:
July 24, 1998: received issue
July 30, 1998: Deferred
February 22, 1999: closed issue

Discussion:
  Resolution is to fix the behavior of servant_to_reference by revising text as shown below


Issue 1732: Changes to Java interface mapping (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: This issue is based off of discussion with engineers at Sun.      The recent portability submission introduced changes to the    mapping for Java interfaces.  This change was to generate both   a signature interface and an operations interface.  The signature   interface is defined to extend the operations interface.  While   the need for both interfaces is clear, it is not clear if the   relationship between the two interfaces is necessary. The change   requires additional classes to be downloaded for the remote stub   case and could potentially impact performance.             

Resolution: closed issue
Revised Text:
Actions taken:
July 24, 1998: received issue
July 30, 1998: closed issue

Discussion:


Issue 1734: Mapping of IDL names that clash with java.lang.Object methods (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: It appears that the IDL to Java mapping does not remap IDL identifiers   that collide with the 9 method names defined for java.lang.Object; i.e.     "clone", "equals", "finalize", "getClass", "hashCode", "notify",      "notifyAll", "toString" and "wait"   If a CORBA/Java server attempts to implement IDL operations with these    names, it will either overload the Object operations, or give compilation   errors (for Object methods declared as "final").  In either case, it looks   like the IDL mapping should treat these names as if they were Java   reserved words.       

Resolution: closed issue
Revised Text:
Actions taken:
July 25, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1737: Compiler-readable code (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary:       PLEASE PLEASE PLEASE resist the temptation to include consolidated Java   source code in .PDF files. At least 3 reasons exist:      - EVERY publication of the consolidated org.omg.* hierachy so far has   contained code that, even before inclusion in the PDF, simply could not   have compiled (void functions returning values, non-void functions   failing to do so, etc.). Errors of this nature arise through having an   editor have to maintain two seperate copies of the code. The need to   apply changes twice (to compiler readable and to .PDF) all but   guarantees that errors will creep in, particularly given that only the   non-.PDF version can be machine checked.    

Resolution: closed issue
Revised Text:
Actions taken:
July 27, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1738: Object._request variants are unspecified (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: It is possible that some part of the C++ mapping is intended to apply   here, but even so, the Java mapping should stand independantly of the   C++ mapping. Requiring Java developers (of ORBs and of applications) to   know C++ and the C++ mapping seems excessive          

Resolution: closed issue
Revised Text:
Actions taken:
July 27, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1739: Local stubs (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: - There is no example given in the mapping. I forget the exact problem,   but some guesswork was required to work out exactly what code should be   generated.      - Why should the class name be specified? Surely it is up to the Helper   to generate instances and thus decide which to create? (I note that   recent changes have altered this somewhat, with ORBs apparently now free   to bypass the Helper altogether and instantiate stubs directly. This   seems like a bad idea.)      - Why are local stubs disctinct? Given that a local stub has to deal   with the possibility of an object ceasing to be local, and that it would   be desirable for a non-local stub to discover that an object has become   local and make use of that knowledge, surely it is up to ORB   implementors to have their Helpers make whatever choices are appropriate   to instantiate appropriate stubs. The way that the mapping currently   stands, it does not seem to be possible to implement a stub that will   cope with objects moving into and out of the current JVM and still   remain compliant.      - _is_local is redundant. The success/failure of preinvoke is the acid   test. This also avoids races: if preinvoke suceeds then you know that   the object is available for a single local invocation. If _is_local   suceeds, then you know nothing of the sort, you have to invoke preinvoke   anyway, and if it fails, invoke remotely anyway.    

Resolution: closed issue
Revised Text:
Actions taken:
July 27, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1741: Java RTF issue (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: ObjectImpl._servant_preinvoke(), how many arguments does it take? The   spec and the consolidated code in the appendix currently differ.      ---      Are Helpers/Holders for SystemExceptions generated? Are they streamable?   How does one insert them into an Any?      (I gain the impression that there has been some work in this area. This   may no longer be an issue.)      ---      Why are the mapped classes for structs "final" when little else is? Is   there a reason for preventing application developers from sub-typing   them?    

Resolution: closed issue
Revised Text:
Actions taken:
July 27, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1746: Conext support in Java (java-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: Below are the proposed spec changes to support Contexts in IDL/Java.   It turns out that some type of API change will be required.  As I was   investigating this further today I realized that one of the methods   on ORB we have to support Context streaming is a proprietary method   and not a standard method, so there is no way to create a Context    object given an InputStream.  This makes demarshalling of contexts   impossible in the stream-based model as it exists today.  The proposal   adds one new method each to InputStream and OutputStream.  Also, as   requested by Simon I have text which states how the Context parameters   are used in interface method declarations.       

Resolution: closed issue
Revised Text:
Actions taken:
July 27, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1750: 2 IDL->Java issues on the singleton ORB (02) (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: How is an ORB to determine whether or not it is in an   applet context? The nearest that I can see is to check for the presence   of a SecurityManager. If we are in an applet context, then there is a   SecurityManager present, but the inverse (that the presence of a   SecurityManager implies that we are in an applet) is not true. It is   however the case that whenever a SecurityManager is present, potentially   untrusted code is present, so the same constraints on the singleton ORB   are probably appropriate. Therefore, I propose that the specification be   changed to state that if System.getSecurityManager() returns a non-null   result, the singeton ORB should be constrained to creating TypeCodes and   Anys.       

Resolution: Close, no action
Revised Text:
Actions taken:
July 29, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1752: mapping of IDL enumerations to java (java-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
Summary: he current mapping of IDL enumerations to Java relies on there being   one and only one instance of an enum.  The instance is held as   a static variable in the enumeration class.  Since there is only   one instance, identity comparisons are used in comparing enums and   the enumeration value class does not implement equality or hash   methods based on the value of the enum.    

Resolution: Close, no action
Revised Text:
Actions taken:
July 29, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1754: Proposal to change get_value_def in Java mapping (java-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: The current support for get_value_def in Helper classes in the   Java mapping for values is currently has several problems.      1. It cannot work with the singleton ORB, which means that the API      is unusable.      2. It requires the generation of the nearly the exact same code in      every single value helper which is very wasteful.      The new proposal is to remove get_value_def from the Value helper class   and add it to the ORB class 

Resolution: closed issue
Revised Text:
Actions taken:
July 30, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1795: final methods on ObjectImpl (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The _get_delegate() and _set_delegate() methods on the Java class   org.omg.CORBA.portable.ObjectImpl should be marked "final" so they   can be inlined by an optimizing java compiler.       

Resolution: closed issue
Revised Text:
Actions taken:
August 11, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1897: Evolving the org.omg.* APIs (java-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: Now that the org.omg.* APIs are built into the JDK core (from JDK 1.2   onwards), there is an issue with how these could be evolved to   support changes to the OMG spec that happen between JDK major releases.   The following is a proposal for how this could be handled.    

Resolution: resolved, see revised text
Revised Text: 1. Change the IDL/Java mapping of enums so that a. the generated Java classes are not final b. the from_int method is not final, and c. the constructor is protected instead of private. Rationale: This change has previously been discussed by this RTF. It is needed in this context because of the need to include some Java classes mapped from IDL enums (e.g., TCKind) in the core JDK. If new members are added to such an enum later, there needs to be a way to subclass the generated Java class to produce a subclass that corresponds to the new IDL (or PIDL) enum. 2. Change the Object, ObjectImpl, and Delegate classes to a. add new methods org.omg.CORBA.Object _get_interface_def() to Object and ObjectImpl and org.omg.CORBA.Object get_interface_def(org.omg.CORBA.Object self) to Delegate. b. deprecate the existing methods org.omg.CORBA.InterfaceDef _get_interface() on Object and ObjectImpl and org.omg.CORBA.InterfaceDef get_interface(org.omg.CORBA.Object self) on Delegate. Rationale: The new methods do not refer to Interface Repository types in their signatures. However, at runtime they still return the same IR objects as the deprecated methods. Since this signature change is a binary incompatible change, and since Java methods cannot be overloaded on their return types, the new methods have different names than the deprecated methods. This allows an easier path for user migration than if the method signatures had been updated "in place". Removing IR types from the signatures allows the new methods to be included in the core JDK without also having to include all the IR classes in the core JDK. With likely changes in this area in the near future because of the Components RFP, it is felt to be unwise to put the IR into core in JDK 1.2. 3. Change the ORB class to a. add a new method public NVList create_operation_list(org.omg.CORBA.Object oper) b. deprecate the existing method public NVList create_operation_list(org.omg.CORBA.OperationDef oper) Rationale: The reason for this change is as for item 2 above. Since Java supports overloading on argument types, there is no need to change the method name in this case. 4. Move some methods needed by Objects By Value from the ORB, InputStream and OutputStream classes to new subclasses (that will not be part of the core JDK 1.2). The names of these new classes are: org.omg.CORBA_2_3.ORB org.omg.CORBA_2_3.portable.InputStream org.omg.CORBA_2_3.portable.OutputStream and the methods affected are: ORB.get_value_def ORB.register_value_factory ORB.unregister_value_factory ORB.lookup_value_factory InputStream.read_Value InputStream.read_Abstract OutputStream.write_Value OutputStream.write_Abstract OutputStream.start_block OutputStream.end_block
Actions taken:
August 28, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1941: Problem mapping "global" types in Java mapping (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The current IDL/Java mapping cannot correctly map IDL "global" types   correctly in all cases. 

Resolution: Close, no action
Revised Text:
Actions taken:
September 9, 1998: received issue
June 4, 1999: closed issue

Discussion:
 closed issue


Issue 1942: Need overloaded write_Value method on OutputStream (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: We have come across a case in the Java-to-IDL mapping where we   need another overloaded form of the write_Value method on the   org.omg.CORBA.portable.OutputStream class.    

Resolution: Close, no action
Revised Text:
Actions taken:
September 10, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1961: Java Mapping for interfaces -- Proposal (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Sun would like to see the following changes to the mapping:    * Change the specification to:   *    * either not specify that object reference types extend the operations interfaces, or   *    * specify that object reference types do not inherit from the operations interface and that the operations interface is just used on the server-side for delegation-based object implementations.   *       * The convention established was that the names of all Java classes/interfaces generated for the server-side as well as those that are not visible start with an `_". We would like to stick to the convention and rename the operations interface accordingly.    

Resolution:
Revised Text:
Actions taken:
September 15, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1964: Creating TypeCodes safely in java (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: There are problems with creating recursive TypeCodes containing values.Our proposal is really quite simple.  We want to add a new class to the   org.omg.CORBA.portable package defined as follows:      package org.omg.CORBA.portable;      final public class TypeCodeLock {   }      All generated type() methods in Helper"s could synchronize on the   TypeCodeLock"s class object to grab a global lock which is used during   TypeCode creation to guarnatee the atomicity of TypeCode creation.   Note, this is essentialy what is done in C++ where TypeCodes are typically   initialized in a global static initalizer which is done from a single   thread.  We are just allowing the typecodes to be created lazily.    

Resolution: Close, no action
Revised Text:
Actions taken:
September 16, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1980: Updated proposal for the OBV Java mapping (java-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: updated proposal for the OBV Java mapping which addresses   a number of issues which have been raised by us and others.  This   proposal is based on a number of discussions and previous proposals   and current OMG submissions (thanks to Simon Nash and Bernard   Normier).  As with previous poposals, these are not currently formal   proposals, just working drafts. ;-)      Here are the current issues:      1. Java valuetypes cannot unmarshal recursive references to themselves.      This is the same problem that occurs with custom valuetypes.      2. The current language mapping mixes both generated code with user      written code in the same source file.  This poses a very complex "tool"      issue for IDL compilers which is unnecessarily complex.      3. Java valuetypes need a way to unmarshal the state of their base class.      4. The addition of the new Helper interface adds ~400 bytes to every       Helper class, of which there are about 250 in a typical ORB implementation.      Which is an overhead of about 100k just to support an optimization of      a corner case in RMI/IIOP where an RMI type happens to contain an IDL type.      This doesn"t even begin to address the bloat that would occur to user code      as well as any additional CORBA services.  The space/time tradeoff here      appears to have gone the wrong way.      5. The ValueHelper interface contains the method get_safe_base_ids, which is      inconsistent with current OBV terminology.      6. The marshaling of boxed types should be considered carefully, because of      the special casing required for boxed strings, arrays, and sequences.      7. The compiler should provide compile time enforcement of init() declarations.    

Resolution: resolved, see revised text
Revised Text: The solution is modify the mapping so as to use an easier deal with form of a 2 class mapping, much like C++, to add facilites that will fix the bugs that don't allow recursive structures to be marshaled and unmarshaled, reduce the "bloat", handle all the boxed values correctly, etc. This proposal, coupled with the proposal to fix Issue 1981, which deals with the "init" portion of the issue at the IDL level, fixes all the known problems with the OBV/Java mapping. Revised Text: The changes are relative to version of Chapter 25 which has had Issue 1897 Evolving the org.omg.* APIs applied to it (available as ftp://ftp.omg.org/orbrev/drafts/idljava_2_4v1.2.pdf ) Add in section 25.4.1.4 after ObjectHolder final public class ValueBaseHolder { public org.omg.CORBA.portable.ValueBase value; public ValueBaseHolder() {} public ValueBaseHolder(org.omg.CORBA.portable.ValueBase initial) {...} public void _read(org.omg.CORBA.portable.InputStream is) {...} public void _write(org.omg.CORBA.portable.OutputStream os){...} public org.omg.CORBA.TypeCode _type(){...} } Replace section 25.5.1 with: 25.5.1 Generic BoxedValueHelper Interface package org.omg.CORBA.portable; public interface BoxedValueHelper { java.io.Serializable read_value(InputStream is); void write_value(OutputStream os, java.io.Serializable value); java.lang.String get_id(); } In 25.5.2 delete the 2nd and 5th paragraphs. In 25.5.2 delete the specification of the "generated Java helper (value types) In 25.5.2, in the specification of the "generated Java helper (non value types): a. delete the "(non value types)" from the comment b. Add the following methods to the end of the generated <typename>Helper class specification: // for each initializer in non abstract value type (see section 25.5.2.1) public static <typename> <initializername> (org.omg.CORBA.ORB orb, [<initializer arguments>]) {...} c. Remove the paragraph following that starts with: "For any user defined, value type ... " Add a new section 25.5.2.1 "Value type initializer convenience functions" as follows: For each initializer in a value type declaration, a corresponding static convenience method is generated in the helper class for the value type. The name of this method is the name of the initializer. This method takes an orb instance and all the arguments specified in the initializer argument list. The implementation of each of these methods will locate a <typename>ValueFactory (see section xxx) and call the identically named method on the ValueFactory passing in the supplied arguments. Replace all of section 25.13 Mapping for Value Type with: 25.13.1 Supporting interfaces for value types 25.13.1.1 ValueBase interface package org.omg.CORBA.portable; public interface ValueBase extends IDLEntity { String[] _truncatable_ids(); } All values implement ValueBase either directly (for boxed primitives - see section 25.14.1), or indirectly by implementing either the StreamableValue or CustomValue interface (see below). 25.13.1.2 StreamableValue interface package org.omg.CORBA.portable; public interface StreamableValue extends Streamable, ValueBase { } All non-boxed IDL valuetypes that are not custom marshalled, implement this interface. 25.13.1.3 CustomMarshal interface package org.omg.CORBA; public interface CustomMarshal { public void marshal (org.omg.CORBA.DataOutputStream os); public void unmarshal (org.omg.CORBA.DataInputStream is); } Implementors of custom marshalled values implement the above interface to provide custom marshalling. 25.13.1.4 CustomValue interface package org.omg.CORBA.portable; public interface CustomValue extends ValueBase, org.omg.CORBA.CustomMarshal { } All custom value types generated from IDL implement this interface. 25.13.1.5 ValueFactory interface package org.omg.CORBA.portable; public interface ValueFactory { java.io.Serializable read_value(InputStream is); } The ValueFactory interface is the native mapping for the IDL type CORBA::ValueFactory. The ValueFactory's read_value() method is called by the ORB runtime in the process of unmarshaling a valuetype. A user must implement this method as part of implementing a type specific ValueFactory. In this implementation, the user must call java.io.Serializable is.read_value(java.io.Serializable) with a blank valuetype to use for unmarshalling. The value returned by the stream is the same value passed in with all the data unmarshalled. 25.13.2 Basics for stateful value types A concrete value type (i.e. one that is not declared as abstract) is mapped to an abstract Java class with the same name, and a factory Java interface with the suffix "ValueFactory" appended to the value type name. In addition, a helper class with the suffix "Helper" appended to the value type name and a holder class with the suffix "Holder" appended to the value type name shall be generated. The specification of the generated holder class is as follows: public final class <typename>Holder implements org.omg.CORBA.portable.Streamable { public <typename> value; public <typename>Holder () {} public <typename>Holder (final <typename> initial) { value = initial; } public void _read (final org.omg.CORBA.portable.InputStream input) {...} public void _write (final org.omg.CORBA.portable.OutputStream output) {...} public org.omg.CORBA.TypeCode _type () {...} } The value type's mapped Java abstract class contains instance variables that correspond to the fields in the state definition in the IDL declaration. The order and name of the Java instance variables shall be the same as the correspondng IDL state fields. Fields that are identified as public in the IDL are mapped to public instance variables. Fields that are identified as private in the IDL are mapped to protected instance variables in the mapped Java class. The Java class for the value type extends either org.omg.CORBA.portable.CustomValue or org.omg.CORBA.portable.StreamableValue, depending on whether it is declared as custom in IDL or not, respectively. The generated Java class shall provide implementation of the ValueBase interface for this value type. The value type's generated value factory interface extends org.omg.CORBA.portable.ValueFactory and contains one method corresponding to each initializer declared in the IDL. The name of the method is the same as the name of the initializer, and the initializer arguments are mapped in the same way as in parameters are for IDL operations. The implementor shall provide a factory class with implementations for the methods in the generated value factory interface. When no initializers are declared in IDL, then the value type's value factory is eliminated from the mapping and the implementor shall simply implement org.omg.CORBA.portable.ValueFactory to provide the method body for read_value(). The inheritance scheme and specifics of the mapped class depend upon the inheritance and implementation characteristics of the value type and are described in the following subsections. The mapped Java class contains abstract method definitions which correspond to the operations and attributes defined on the value type in IDL. An implementor of the value type extends the generated Java class to provide implementation for the operations and attributes declared in the IDL, including those for any derived or supported value types or interfaces. 25.13.2.1 Inheritance from values - Value types that do not inherit from other values or interfaces: For non custom values, the generated Java class also implements the StreamableValue interface and provides appropriate implementation to marshal the state of the object. For custom values, the generated class extends CustomValue but does not provide an implementation for the CustomMarshal methods. - inheritance from other stateful values The generated Java class extends the Java class to which the inherited value type is mapped - inheritance from abstract values The generated Java class implements the Java interface to which the inherited abstract value is mapped(see section 25.13.3). - supported interfaces The Java class implements the Operations Java interface of all the interfaces(if any) that it supports. (Note that the operations interface for abstract interfaces does not have the "Operations" suffix, see section 25.12.1.1). The implementation of the supported interfaces of the value type shall use the tie mechanism, to tie to the value type implementation. 25.13.3 Abstract Value Types An abstract value type maps to a Java interface that implements ValueBase and contains all the operations and attributes specified in the IDL, mapped using the normal rules for mapping operations and atttributes. Abstract value types cannot be implemented directly. They must only be inherited by other stateful value types or abstract value types. 25.13.4 CORBA::ValueBase CORBA::ValueBase is mapped to java.io.Serializable. The get_value_def() operation is not mapped to any of the classes associated with a value type in Java. Instead it appears as an operation on the ORB pseudo object in Java(see "public static org.omg.CORBA.Object get_value_def(String repId)" in section 25.19.10). Note: This implies fixing up the referenced text in !too 25.19.10 to have the correct signature 25.13.5 Examples In 25.13. 4 Example A In the IDL change init(in long w); to: factory create(in long w); Replace the generated Java by: // generated Java package ExampleA; public abstract class WeightedBinaryTree implements org.omg.CORBA.portable.StreamableValue { // instance variables protected int weight; protected ExampleA.WeightedBinaryTree left; protected ExampleA.WeightedBinaryTree right; abstract public int[] preOrder (); abstract public int[] postOrder (); public org.omg.CORBA.TypeCode _type () {...} public void _read (final org.omg.CORBA.portable.InputStream _input) { // read state information using the wire format ... } public void _write (final org.omg.CORBA.portable.OutputStream _output) { .... } public java.lang.String[] _truncatable_ids () {...} } public final class WeightedBinaryTreeHelper { < ed note: put all the helper methods here> public static WeightedBinaryTree create(ORB orb, int w) { ... } } final public class WeightedBinaryTreeHolder implements org.omg.CORBA.portable.Streamable { ... <Note: the code for this isn't changing so just leave the old code there> } public interface WeightedBinaryTreeValueFactory extends org.omg.CORBA.portable.ValueFactory { public ExampleA.WeightedBinaryTree create (int w); } In 25.13.5 Example B Keep the IDL and the Java mapping of the Printer interface as is. Replace the generated Java for the WeightedBinaryTree with the following: // generated java package ExampleB; public abstract class WeightedBinaryTree implements org.omg.CORBA.portable.StreamableValue, PrinterOperations { protected int weight; protected ExampleB.WeightedBinaryTree left; protected ExampleB.WeightedBinaryTree right; abstract public int[] preOrder (); abstract public int[] postOrder (); public org.omg.CORBA.TypeCode _type () { ... } public void _read (final org.omg.CORBA.portable.InputStream _input) { ... } public void _write (final org.omg.CORBA.portable.OutputStream _output) { ... } public java.lang.String[] _truncatable_ids () { ... } } public final class WeightedBinaryTreeHelper { .... // helper methods... < ed note: put all the helper methods here> } public final class WeightedBinaryTreeHolder { ... <note this hasn't changed, fill in old one here> } // user written code for default ValueFactory public class WeightedBinaryTreeDefaultFactory implements org.omg.CORBA.portable.ValueFactory { public java.io.Serializable read_value (org.omg.CORBA.portable.InputStream is) { //user implements code } } Add a new 25.13.5 Example C // IDL typedef sequence<unsigned long> WeightedSeq; module ExampleC { custom valuetype WeightedBinaryTree { private unsigned long weight; private WeightedBinaryTree left; private WeightedBinaryTree right; factory create(in long w); WeightedSeq preOrder(); WeightedSeq postOrder(); }; }; // generated Java package ExampleC; abstract public class WeightedBinaryTree implements org.omg.CORBA.portable.CustomValue {...} public final class WeightedBinaryTreeHelper {...} public final class WeightedBinaryTreeHolder {...} [ editing note: fill in the ... as an aid to the reader ] 25.13.6 Keep as is currently in the specification 25.13.7 ValueFactory and Marshaling Replace second bullet in factory lookup algorithm by: - If this is not successful and the repository id is a standard IDL repository id that starts with "IDL:",then extract the class name from the repository id by stripping of the "IDL:" header and ":<major>.<minor>" version information trailer and replacing all "/"s with "."s. Then attempt to load a value factory by appending a "DefaultFactory" suffix to the above class name. Replace third bullet in factory lookup algorithm by: - If this is not successful and the repository id is a standard RMI repository id that begins with "RMI:", then extract the class name from the repository id by stripping of the "RMI:" header and the ":<hashcode>:[<suid>]" trailer and applying all necessary conversions(see section 26.****). The ValueHandler interface is used to read in the value, if it does not implement IDL Entity. Replace paragraph following the bullets by: The IDL native type ValueFactory is mapped in Java to org.omg.CORBA.portable.ValueFactory. In 25.14 Mapping for Value Box Type, replace the 3rd paragraph with the following: A boxed value needs to be treated differently than regular values in Java. Boxed values don't have factories and don't implmenent either the StreamableValue or CustomValue interfaces, so their marshalling and unmarshalling is performed by a boxed value helper object. In all cases, code can be generated to unmarshal the boxed type. No user code is required for boxed values. The BoxedValueHelper interface is implemented by all generated Helper classes for boxed valuetypes. The inherited read_value() method is called by the ORB runtime in the process of unmarshalling a boxed valuetype. This is required for types that are immutable either in content (eg, string), or size (eg, sequences). The write_value() method call is used for marshalling the value box. There are two general cases to consider. value boxes of primitive Java types and value boxes for entities that are mapped to java classes. In Section 25.14.1 Replace the first Java class <box_name> to be: public class <box_name> implements ValueBase { public <mapped_primitive_Java_type> value; public <box_name>(<mapped_primitive_Java_type> initial) { value = initial; } private static String[] _ids = { <box_name>Helper.id() }; public String[] _truncatable_ids() { return _ids; } } Replace the third Java class <box_name>Helper to be: final public class <box_name>Helper implements org.omg.CORBA.portable.BoxedValueHelper { public <box_name> read_value(InputStream is) {...} public write_value(OutputStream is, <box_name> value) {....} public String get_id() { ... } .... // other helper methods } In Section 25.14.1.1 Primitive Type example: Replace the MyLong class by: public class MyLong implements ValueBase { public int value; public MyLong(int initial) { value = initial; } private static String[] _ids = { MyLongHelper.id() }; public String[] _truncatable_ids() { return _ids; } } Replace MyLongHelper by: final public class MyLongHelper implements org.omg.CORBA.portable.BoxedValueHelper { public MyLong read_value(InputStream is) {...} public write_value(OutputStream is, MyLong value) {....} public String get_id() { ... } .... // other helper methods } Add to end of paragraph on 25.14.2 //IDL valuetype <box_name> <IDLtype>; final public class <box_name>Helper implements org.omg.CORBA.portable.BoxedValueHelper { public <IDLType> read_value(InputStream is) {...} public write_value(OutputStream is, <IDLType> value) {....} .... // other helper methods } final public class <box_name>Holder implements org.omg.CORBA.portable.Streamable { public <mapped_java_class> value; ... } Add a new section 25.14.3 Examples // IDL module A { valuetype BoxedString string; }; // generated Java package A; public final class BoxedStringHelper implements org.omg.CORBA.portable.BoxedValueHelper { private static final BoxedStringHelper _instance = new BoxedStringHelper(); public static java.lang.String read (final org.omg.CORBA.portable.InputStream _input) { if (!(_input instanceof org.omg.CORBA_2_3.portable.InputStream)) { throw new org.omg.CORBA.BAD_PARAM(); } return (java.lang.String)((org.omg.CORBA_2_3.portable.InputStream)_input).read_value(_instance); } public static void write (final org.omg.CORBA.portable.OutputStream _output, final java.lang.String value) { if (!(_output instanceof org.omg.CORBA_2_3.portable.OutputStream)) { throw new org.omg.CORBA.BAD_PARAM(); } ((org.omg.CORBA_2_3.portable.OutputStream)_output).write_value(value, _instance); } public static void insert (org.omg.CORBA.Any any, java.lang.String value) {...} public static java.lang.String extract (org.omg.CORBA.Any any) {...} public static org.omg.CORBA.TypeCode type () {...} public static java.lang.String id () {...} public java.io.Serializable read_value (org.omg.CORBA.portable.InputStream _input) { java.lang.String result; result = _input.read_string(); return (java.io.Serializable)result; } public void write_value (org.omg.CORBA.portable.OutputStream _output, java.io.Serializable value) { if (!(value instanceof java.lang.String)) { throw new org.omg.CORBA.MARSHAL(); } java.lang.String valueType = (java.lang.String)value; _output.write_string(valueType); } public java.lang.String get_id () { return id(); } } public final class BoxedStringHolder implements org.omg.CORBA.portable.Streamable {....} Section 25.14.3.1 Example B // IDL struct idlStruct { short x; }; module A { valuetype BoxedStruct idlStruct; }; // generated Java package A; public final class BoxedStructHelper implements org.omg.CORBA.portable.BoxedValueHelper { private static final BoxedStructHelper _instance = new BoxedStructHelper(); public static idlStruct read (final org.omg.CORBA.portable.InputStream _input) { if (!(_input instanceof org.omg.CORBA_2_3.portable.InputStream)) { throw new org.omg.CORBA.BAD_PARAM(); } return (idlStruct)((org.omg.CORBA_2_3.portable.InputStream)_input).read_value(_instance); } public static void write (final org.omg.CORBA.portable.OutputStream _output, final idlStruct value) { if (!(_output instanceof org.omg.CORBA_2_3.portable.OutputStream)) { throw new org.omg.CORBA.BAD_PARAM(); } ((org.omg.CORBA_2_3.portable.OutputStream)_output).write_value(value, _instance); } public static void insert (final org.omg.CORBA.Any any, final idlStruct value) {...} public static idlStruct extract (final org.omg.CORBA.Any any) {...} public static org.omg.CORBA.TypeCode type () {...} public static java.lang.String id () {...} public java.io.Serializable read_value (final org.omg.CORBA.portable.InputStream _input) { final idlStruct result; result = idlStructHelper.read(_input); return (java.io.Serializable)result; } public void write_value (final org.omg.CORBA.portable.OutputStream _output, final java.io.Serializable value) { if (!(value instanceof idlStruct)) { throw new org.omg.CORBA.MARSHAL(); } idlStruct valueType = (idlStruct)value; idlStructHelper.write(_output, valueType); } public java.lang.String get_id () { return id(); } } public final class BoxedStructHolder implements org.omg.CORBA.portable.Streamable { .... } In Section 25.19.10 ORB in the definition of the org.omg.CORBA_2_3.ORB class: Change the signature of register_value_factory to: public org.omg.CORBA.portable.ValueFactory register_value_factory(String id, org.omg.CORBA.portable.ValueFactory factory); Change the return type lookup_value_factory() from: org.omg.CORBA.portable.ValueHelper to: org.omg.CORBA.portable.ValueFactory In Section 25.21.4 In the definition of the org.omg.CORBA_2_3.portable.InputStream: Change both declarations of read_Value to read_value In the 2nd overloaded read_Value change the parameter type from: ValueHelper helper to: java.lang.String rep_id Change both declarations of read_Abstract to read_abstract_interface Add the following new methods: public java.io.Serializable read_value(org.omg.CORBA.portable.BoxedValueHelper factory) { throw new org.omg.CORBA.NO_IMPLEMENT(); } public java.io.Serializable read_value(java.io.Serializable) { throw new org.omg.CORBA.NO_IMPLEMENT(); } In the definition of the org.omg.CORBA_2_3.portable.OutputStream: Change both declarations of write_Value to write_value In the 2nd overloaded write_Value change the 2nd parameter type from: ValueHelper value to: java.lang.String rep_id Change the declaration of write_Abstract to write_abstract_interface Delete the start_block and end_block methods Add the following new method: public void write_value(java.io.Serializable value, org.omg.CORBA.portable.BoxedValueHelper factory) { throw new org.omg.CORBA.NO_IMPLEMENT(); }
Actions taken:
September 18, 1998: received issue
February 26, 1999: moved from obv_rtf to java rtf
June 4, 1999: closed issue

Discussion:


Issue 1993: create_lname & create_lname_context (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The naming service states that LName and LNameComponent are created   in C/C++ using the create_lname and create_lname_context functions   respectively.   No mention is made as to how this is achieved in Java.      Should it be possible to simply create an instance of the class using new,   or is there a need for a factory class?          

Resolution: These functions (library) has been deprecated by the newly adopted Interoperable Naming Service.
Revised Text:
Actions taken:
September 23, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1994: Local stubs proposal (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Add the following new paragraph after the third paragraph of Section    25.20.5.1 "Stub/Skeleton Architecture":      Local stubs shall copy all valuetypes passed to them either as   parameters or as data within parameters, and shall pass the resulting    copies to the Servant in place of the originals.  The valuetypes shall   be copied using the same "deep copy" semantics as would result from   GIOP marshaling and unmarshaling.    

Resolution:
Revised Text:
Actions taken:
September 24, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 2079: Potential problem with Java Mapping ORB init for Applet (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: While working on the revised interoperable naming specification,   a java issue came up with regard to arguments to CORBA ORB_init.      The PIDL reads as:     module CORBA {        typedef string ORBid;        typedef sequence <string> arg_list;        ORB ORB_init(inout arg_list argv, in ORBid orb_identifier);     }      However the java mapping for init in an applet is:   // public static ORB init(Applet app, Properties props);      Using a property list for the argument list results in considerably   different behavior than the PIDl sequence<string> definition, mainly   no preservation of sequence order and no repeating elements    (properties).     

Resolution: resolved
Revised Text:
Actions taken:
October 14, 1998: received issue
June 4, 1999: closed issue

Discussion:
This is the proper design behavior. The use of sequence in PIDL does not necessarily imply any specific semantics with regards to such things. (There is  no primitive set concept which could be used in PIDL. Each language mapping maps PIDL as it sees fit. The current specification is the natural mapping for Java.   Revised Text: none


Issue 2096: Issue with Mapping for Constants within an interface (java-rtf)

Click
here for this issue's archive.
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


Issue 2228: typedefs in IDl when generating Java code (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: A question came up regarding the use of typedefs in idl when generating Java   >code.  Since Java has no support for typedefs the alias is not available to   >any Java code other than the idl generated code.  This seems to be a flaw in   >the design of the idl to Java mapping specification.      

Resolution: The helper is generated for all aliases, it can be used if needed.
Revised Text:
Actions taken:
November 25, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 2233: Helper "narrow" exception clarification (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Referring to 23_java-2_3base.pdf, section 23.11.1, page 23-26, second   paragraph, "The IDL exception CORBA::BAD_PARAM is thrown if the narrow   fails."      This statement can be interpreted in two different ways. Does it mean that    BAD_PARAM is thrown no matter what goes wrong in the narrow call, or that    BAD_PARAM is thrown only when the parameter doesn"t support the interface    being narrowed to?       

Resolution: The latter. A different exception shall be raised to indicate other errors.
Revised Text: In Section 23.12.1 Basics: Replace the last sentence of the 3rd paragraph: The IDL exception CORBA::BAD_PARAM is thrown if the narrow fails. with: The IDL exception CORBA::BAD_PARAM shall be thrown if the narrow fails because the object reference does not support the requested type. A different system exception shall be raised to indicate other kinds of errors. Trying to narrow a null will always succeed with a return value of null. Actions taken: Close, incorporate text
Actions taken:
December 1, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 2251: Java LocalStub (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: From IDL/Java specification (draft version 3.4 - August 9):          The remote stub must be named _<interface_name>Stub where       <interface_name> is the IDL interface name this stub is       implementing. The local stub must be named _<interface_name>LocalStub       where <interface_name> is the same IDL interface  name. Local stubs       are defined to be direct subclasses of remote stubs.        and:        The _is_local() method is provided so Helper classes may determine if a     particular object is implemented by a local servant and if so create a     local stub, rather than a remote stub. This function would typically     be called from within the narrow() method  of a Helper class. The     _is_local() method may only return true if the servant incarnating the     object is located in the same Java VM. The method may return false if     the servant is not local or the ORB does not support local stubs for     that particular servant. The default behavior of _is_local() is to     return false.      The design described in the specification seems to make it very difficult,   if not impossible, to do the following:      - Create a proxy that refers to some remote servant   - Upon a request to the remote servant, a LocationForward is generated that     refers to a colocated servant.    

Resolution: Merge the two stub classes together as one class with as minimal impact on the APIs and performance.
Revised Text: Replace the first five paragraphs of section 25.21.5.1 "Stub/Skeleton Architecture" with the following text: "The mapping defines a single stub which may be used for both local and remote invocation. Local invocation provides higher performance for collocated calls on Servants located in the same process as the client. Local invocation is also required for certain IDL types which contain parameter types which cannot be marshalled remotely. Remote invocation is used to invoke operations on objects which are located in an address space separate from the client. While a stub is using local invocation it shall provide complete location transparency. To provide the correct semantics, compliant programs shall comply with the parameter passing semantics defined in Section 25.11.2, "Parameter Passing Modes". When using local invocation the stub shall copy all valuetypes passed to them, either as in parameters, or as data within in parameters, and shall pass the resulting copies to the Servant in place of the originals. The valuetypes shall be copied using the same deep copy semantics as would result from GIOP marshaling and unmarshaling. The following sections describe the characteristics of the stubs and skeletons. The examples are based on the following IDL:" In Section 25.21.5.1.1 "Stub Design" replace the second paragraph with the following: "The stub shall be named _<interface_name>Stub where <interface_name> is the IDL interface name this stub is implementing. Stubs shall support both local invocation and remote invocation, except in the following cases: 1. The stub is implementing an IDL interface which may only be invoked locally (e.g. PortableServer::POA). In this case, the stub may choose to implement only local invocation. " In Section 25.21.5.1.1, remove the fourth paragraph. Replace the example in Section 25.21.5.1.3 "Stream-based Stub example" with the following: package Example; public class _AnInterfaceStub extends org.omg.CORBA.portable.ObjectImpl implements AnInterface { public java.lang.String[] _ids () { return __ids; } private static java.lang.String[] __ids = { "IDL:Example/AnInterface:1.0" }; final public static java.lang.Class _opsClass = Example.AnInterfaceOperations.class; public int length (java.lang.String s) throws Example.AnException { while(true) { if(!this._is_local()) { try { org.omg.CORBA.portable.OutputStream _output = this._request("length", true); _output.write_string(s); org.omg.CORBA.portable.InputStream _input = this._invoke(_output); return _input.read_long(); } catch (org.omg.CORBA.portable.RemarshalException _exception) { continue; } catch (org.omg.CORBA.portable.ApplicationException _exception) { java.lang.String _exception_id = _exception.getId(); if (_exception_id.equals(Example.AnExceptionHelper.id())) { throw Example.AnExceptionHelper.read(_exception.getInputStream()); } throw new org.omg.CORBA.UNKNOWN("Unexpected User Exception: " + _exception_id); } finally { this._releaseReply(_input); } } else { org.omg.CORBA.portable.ServantObject _so = _servant_preinvoke("length", _opsClass); if (_so == null) { continue; } Example.AnInterfaceOperations _self = (Example.AnInterfaceOperations)_so.servant; try { return _self.length(s); } finally { _servant_postinvoke(_so); } } } } } In Section 25.21.5.2 "Stub and Skeleton Class Hierarchy", Figure 25-1, remove the class "_FooLocalStub". In Section 25.21.5.3.1 "Streaming Stub APIs" replace the second paragraph with the following: "The method _invoke() is called to invoke an operation. The stub provides an OutputStream that was previously returned from a _request() call. The method _invoke() returns an InputStream which contains the marshalled reply. The _invoke() method may throw only one of the following: an ApplicationException, a RemarshalException, or a CORBA system exception. An ApplicationException shall be thrown to indicate the target has raised a CORBA user exception during the invocation. The stub may access the InputStream of the ApplicationException to unmarshal the exception data. A RemarshalException shall be thrown if the stub was redirected to a different target object and remarshalling is necessary, this is normally due to a GIOP object forward or locate forward messages. In this case, the stub shall then attempt to reinvoke the request on behalf of the client after verifying the target is still remote by invoking _is_local() (see section 25.21.5.3.2). If _is_local() returns True, then an attempt to reinvoke the request using the Local Invocation APIs shall be made. If a CORBA system exception is thrown, then the exception shall be passed on directly to the user." Rename section 25.21.5.3.2 "Local Stub APIs" to "Local Invocation APIs". Replace the first three paragraphs with the following: "Local invocation is supported by the following methods and classes: The _is_local() method is provided so stubs may determine if a particular object is implemented by a local servant and hence local invocation APIS may be used. The _is_local() method shall return true if the servant incarnating the object is located in the same process as the stub and they both share the same ORB instance. The _is_local() method returns false otherwise. The default behavior of _is_local() is to return false. The _servant_preinvoke() method is invoked by a local stub to obtain a Java reference to the servant which should be used for this request. The method takes a string containing the operation name and a Class object representing the expected type of the servant as parameters and returns a ServantObject object (Note, ORB vendors may subclass the ServantObject object to return additional request state that may be required by their implementations). The operation name corresponds to the operation name as it would be encoded in a GIOP request. The expected type shall be the Class object associated with the operations class of the stub's interface (e.g. A stub for an interface Foo, would pass the Class object for the FooOperations interface). The method shall return a null value if the servant is not local or the servant has ceased to be local as a result of the call (i.e, due to a ForwardRequest from a POA ServantManager). The method shall throw CORBA::BAD_PARAM if the servant is not of the expected type. If a ServantObject object is returned, then the servant field shall have been set to an object of the expected type (Note, the object may or may not be the actual servant instance). The local stub may cast the servant field to the expected type, and then invoke the operation directly. The ServantRequest object is valid for only one invocation, and cannot be used for more than one invocation."
Actions taken:
December 10, 1998: received issue
February 26, 1999: moved from java-rtf to orb_revision
June 4, 1999: closed issue

Discussion:


Issue 2255: Proposal for persistent valuetypes (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Here is my proposal for how to solve the persistent valuetype problem.   It allows valuetypes to be used for PSS with getter and setter   access to the data, without changing the OBV Java language bindings or   adding new keywords or pragmas to IDL.  Any additions to IDL that may   be desirable for improved functionality (e.g, query and finder support)   could be designed jointly by the components submission group and the   PSS group as part of some future RTF activity.      The proposal is very simple.  It is that persistent valuetypes   must be abstract valuetypes with attributes.  The attributes would   be used to specify the persistent state of the object.    

Resolution: closed, no action
Revised Text:
Actions taken:
December 15, 1998: received issue
June 4, 1999: closed issue

Discussion:
Persistent valuetypes are part of a proposed submission to the PSS RFP which has not  yet been adopted. If and when such a submission is adopted  as an OMG specification, it MAY be appropriate to resubmit this, or a similar issue. Until then, even the filing of this issue is premature at best.   Revised Text:   Actions taken: Close, no action.


Issue 2256: PSS requiremnets for the ObV/Java mapping (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The latest ObV/Java mapping, including George"s latest proposal, is not   usable for values with a persistent implementation.   I"d really like to solve this issue with the Java & ObV RTF, rather than   solve it through the adoption of a new spec that updates the Java mapping.      ==== Issue   - ObV/Java maps value types"s data members to Java data members   - providing a persistent implementation for such data members would      require byte-code post-processing or pre-processing, or     yet-to-be-specd-and-agreed JVM hooks; we do not see this as viable/     realistic options.       

Resolution: closed, no action
Revised Text:
Actions taken:
December 15, 1998: received issue
June 4, 1999: closed issue

Discussion:
 Persistent valuetypes are part of a proposed submission to the PSS RFP which has not  yet been adopted. If and when such a submission is adopted  as an OMG specification, it MAY be appropriate to resubmit this, or a similar issue. Until then, even the filing of this issue is premature at best.


Issue 2462: BAD_PARAM issue (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: This issue is with the 1998-08-22 "Mapping of OMG IDL to Java".      ptc/1998-08-22 (the IDL/Java mapping), section 25.3.5, says that   if a bounded string is too long, MARSHAL is thrown.      Meanwhile, ptc/1998-12-04 (2.3a Core chapters 1-15), section 3.17.1, says   that MARSHAL is to be used for "A request or reply is structurally invalid   ...indicates a bug in the runtime". Meanwhile, BAD_PARAM says "a parameter   passed to a call is out of range or otherwise illegal..."       Based on these descriptions, I propose that BAD_PARAM should    be thrown in Java when a string exceeds its bound rather than MARSHAL.    

Resolution: Make it so.
Revised Text: In section 25.4.5 Strings replace the 2 occurrences of MARSHAL with BAD_PARAM.
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2514: PortableServer Servant issue (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The currently specified definition of the org.omg.CORBA.PortableServer.Servant   class does not correctly implement the behavior specified.  In particular, the   POA returned by PortableServer::Current::get_POA is always used during the   processing of _this_object() even if _this_object() is not being called on the   Servant which is currently being invoked as part of the request.  This contradicts   the behavior defined in the first bullet item for _this_object as defined in    section 25.19.2.1 "Mapping of PortableServer::Servant".      Also, the overall behavior of _this() may need some tweaking (see my other email   "Behavior of POA Servant"s _this()"), which may require us to revisit the   definition of the Servant class.    

Resolution: resolved, see revised text
Revised Text: The current definition of org.omg.PortableServer.Servant does not correctly implement the specification defined for Servant as defined by the Java mapping. In particular, it does not correctly implement the semantics of bullet item number one defined for _this_object(). Furthermore, the current definition of Servant hard codes certain functionality and prevents vendors from making fixes or otherwise changing the implementation. To fix this problem, a delegation model for the Servant class similar to that used by stubs is proposed in order to allow vendors full control over the way that certain Servant operations are handled. We believe this is necessary to correctly implement the _this_object() method for which a correct implementation using the currently defined public POA APIs is somewhat problematic. The proposal also allows vendors flexibility in the implementation of the methods way which may allow for better optimization opporutunities. The proposed changes have minimum impact on end user applications as well as minimal impact on ORB vendors (the Visibroker ORB was converted to the new design in less than a day including time to implement _this_object()). The only API change end users will see is the removal of the method: void _orb(org.omg.CORBA.ORB orb); This method does not work well with the new delegation model, and it has been our experience that this method is rarely, if ever, used. The only need a user ever has to set the ORB on a Servant is for the case of implicit activation, and the prefered way is to use the method: org.omg.CORBA.Object _this_object(org.omg.CORBA.ORB orb); The _this_object() method is still provided, but now sets the delegate instead of setting a locally stored ORB variable. We believe this method is required and also commonly used so should remain part of the user API. The proposal defines a new Delegate interface which is defined in a new package org.omg.PortableServer.portable and mirrors the design pattern used by the Stub classes for the Java mapping. Unlike stubs, however, the Servant must have a way of setting its delegate given an instance of the ORB in order to support implicit activation via _this(). To accomplish this our proposal includes the addition of a new method on the ORB class: public void set_delegate(java.lang.Object object); This method will actually appear on org.omg.CORBA_2_3.ORB due to the org.omg.CORBA.ORB class being frozen in the Java 2 core. This method takes an object which is known to the ORB to follow the delegation model and sets it delegate. In this version of the proposal the only type that an ORB is required to support setting the delegate is org.omg.PortableServer.Servant. However, we expect in the future it may be possible to make use of this method to set delegates on stubs which have been reincarnated through Java serialization. Note, we also chose to make the Delegate an interface rather than an abstract class to provide for greater flexibility in the implementation. This proposal as it fixes an important piece of POA functionality and is required for correct operation of the POA. George Scott, [email protected] Revised Text: In Section 25.19.10 "ORB". Add the following new method to org.omg.CORBA_2_3.ORB: public abstract class ORB extends org.omg.CORBA.ORB { abstract public void set_delegate(java.lang.Object wrapper); } Add the following paragraph following the class definition for org.omg.CORBA_2_3.ORB: Add a new section: 25.19.10.1 set_delegate at the end of section 25.19.10 "The set_delegate() method supports the Java ORB portability interfaces by providing a method for classes which support ORB portability through delegation to set their delegate. This is typically required in cases where instances of such classes were created by the application programmer rather than the ORB runtime. The wrapper parameter is the instance of the object on which the ORB must set the delegate. The mechanism to set the delegate is specific to the class of the wrapper instance. The set_delegate() method shall support setting delegates on instances of the following Java classes: - org.omg.PortableServer.Servant If the wrapper paramter is not an instance of a class for which the ORB can set the delegate, the CORBA::BAD_PARAM exception shall be thrown." In Section 25.20.2.1 "Mapping of PortableServer::Servant", reformat the methods and group them to clarify their use as follows: Add the comment below and group the following 5 methods // Convenience methods for application programmer final public org.omg.CORBA.Object _this_object() {...} final public org.omg.CORBA.Object _this_object(ORB orb) {...} final public org.omg.CORBA.ORB _orb() {...} final public POA _poa() {...} final public byte[] _object_id() {...} Add the comment below and group the following 4 methods: // Methods which may be overriden by the application programmer public POA _default_POA() {...} public boolean _is_a(String repository_id) {...} public boolean _non_existent() {...} public org.omg.CORBA.InterfaceDef _get_interface() {...} Add the comment below and group the following 1 methods: // Methods for which the skeleton or application programmer must // provide an implementation abstract public String[] _all_interfaces(POA poa, byte[] objectId); Delete the following method: final public void _orb(ORB orb) {...} Replace the following paragraph which reads as "The Servant class is an abstract Java class which serves as the base classfor all POA Servant implementations." with the following 3 paragraphs: "The Servant class is an abstract Java class which serves as the base classfor all POA Servant implementations. It provides a number of methods which may be invoked by the application programmer, as well as methods which are invoked by the POA itself and may be overridden by the user to control aspects of Servant behavior. With the exception of the _all_interfaces() and _this_object(ORB orb) methods, all methods defined on the Servant class may only be invoked after the Servant has been associated with an ORB instance. Attempting to invoke the methods on a Servant which has not been associated with an ORB instance shall result in a CORBA::BAD_INV_ORDER exception being raised. A Servant is associated with an ORB instance via one of the following means: 1. Through a call to _this_object(ORB orb) passing an ORB instance as parameter. The Servant will become associated with the specified ORB instance. 2. By explicitly activating a Servant with a POA by calling either POA::activate_object or POA::activate_object_with_id. Activating a Servant in this fashion will associate the Servant with the ORB instance which contains the POA on which the Servant has been activated. 3. By returning a Servant instance from a ServantManager. The Servant returned from PortableServer::ServantActivator::incarnate() or PortableServer::ServantLocator::preinvoke() will be associated with the ORB instance which contains the POA on which the ServantManager is installed. 4. By installing the Servant as a default servant on a POA. The Servant will become associated with the ORB instance which contains the POA for which the Servant is acting as a default servant. It is not possible to associate a Servant with more than one ORB instance at a time. Attempting to associate a Servant with more than one ORB instance will result in undefined behavior. Replace Section 25.20.2.1.2 _orb with: The _orb() method is a convenience method which returns the instance of the ORB which is currently associated with the Servant." In Section 25.20.2.1.1 _this_object Replace the fourth bullet item with the following text: " * The _this_object(ORB orb) method first associates the Servant with the specified ORB instance and then invokes _this_object() as normal." In Section 25.21.2 "Overall Architecture" Add the following bullet after the "Portable Delegate" bullet: " * Portable Servant Delegate - provides the vendor specific implementation of PortableServer::Servant" In Section 25.21.2.1 "Portability Package" Change the first sentence to the following: "The APIs needed to implement portability are found in the org.omg.CORBA.portable and org.omg.PortableServer.portable packages." Add the following new sections after section 25.21.6 "Delegate": (ORB becomes 25.21.9) " 25.21.7 "Servant" The Servant class is the base class for all POA-based implementations. It delegates all functionality to the Delegate interface defined in section 25.21.6. package org.omg.PortableServer; import org.omg.CORBA.ORB; import org.omg.PortableServer.portable.Delegate; abstract public class Servant { private transient Delegate _delegate = null; final public Delegate _get_delegate() { if (_delegate == null) { throw new org.omg.CORBA.BAD_INV_ORDER("The Servant has not been associated with an ORB instance"); } return _delegate; } final public void _set_delegate(Delegate delegate) { _delegate = delegate; } final public org.omg.CORBA.Object _this_object() { return _get_delegate().this_object(this); } final public org.omg.CORBA.Object _this_object(ORB orb) { try { ((org.omg.CORBA_2_3.ORB)orb).set_delegate(this); } catch(ClassCastException e) { throw new org.omg.CORBA.BAD_PARAM("POA Servant requires an instance of org.omg.CORBA_2_3.ORB"); } return _this_object(); } // access to the ORB final public ORB _orb() { return _get_delegate().orb(this); } // convenience methods to the POA Current final public POA _poa() { return _get_delegate().poa(this); } final public byte[] _object_id() { return _get_delegate().object_id(this); } // Methods which may be overriden by the user public POA _default_POA() { return _get_delegate().default_POA(this); } public boolean _is_a(String repository_id) { return _get_delegate().is_a(this, repository_id); } public boolean _non_existent() { return _get_delegate().non_existent(this); } public org.omg.CORBA.InterfaceDef _get_interface() { return _get_delegate().get_interface(this); } // methods for which the user must provide an implementation abstract public String[] _all_interfaces(POA poa, byte[] objectId); } 25.21.8 "Servant Delegate" The Delegate interface provides the ORB vendor specific implementation of PortableServer::Servant. package org.omg.PortableServer.portable; import org.omg.PortableServer.Servant; import org.omg.PortableServer.POA; public interface Delegate { org.omg.CORBA.ORB orb(Servant self); org.omg.CORBA.Object this_object(Servant self); POA poa(Servant self); byte[] object_id(Servant self); POA default_POA(Servant self); boolean is_a(Servant self, String repository_id); boolean non_existent(Servant self); org.omg.CORBA.InterfaceDef get_interface(Servant self); } Rename Section 25.21.6 "Delegate" to "Stub Delegate".
Actions taken:
March 5, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2517: orb.properties search should include home directory (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The search for an orb.properties file to set a default ORB class and   ORB Singleton class looks only in the JDK lib directory.  In many   installations, this is read-only (e.g., on a shared drive) and not   updatable by users.  To allow users of these JDK installations to   set a default ORB, the search order should be:    1. The user"s home directory (user.home system property)    2. The <java.home>/lib directory.    

Resolution:
Revised Text: Make the search order for the file orb.properties: 1. The user's home directory (user.home system property) 2. The <java.home>/lib directory.
Actions taken:
March 8, 1999: received issue
January 9, 2001: closed issue

Discussion:


Issue 2518: Incorrect search order for ORB implementation class name (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The first bullet of the search order for an ORB implementation class   name in section 25.21.7 is:    . check in Applet parameter or application string array, if any   This seems wrong 

Resolution:
Revised Text:
Actions taken:
March 8, 1999: received issue
February 27, 2001: closed issue

Discussion:
Delete the words         "or application string array, if any"    from the first bullet in Section 21.9 (note that section    numbering has changed since this issue was filed).


Issue 2519: Need SerializableHolder class (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: There is currently no defined way to map out or inout parameters of   type ValueBase to Java.  Since ValueBase maps to java.io.Serializable,    there shoud be an org.omg.CORBA.SerializableHolder class.      Proposed Resolution:      Add SerializableHolder to section 25.4.1.4.    

Resolution: Close, no change.
Revised Text: Close, no change. The ValueBaseHolder class defined in Section 13.1.1 satisfies the mapping need.
Actions taken:
March 8, 1999: received issue
February 27, 2001: closed issue

Discussion:
Add SerializableHolder to section 25.4.1.4.


Issue 2520: Standard properties should include initial host and port (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The standard properties listed in section 25.21.7.1 allow the ORB   class and ORB singleton class to be set.  There should also be   standard properties to allow the initial host and port for the naming   service to be set.       

Resolution: Close no change.
Revised Text:
Actions taken:
March 8, 1999: received issue
May 13, 2002: closed issue

Discussion:
As was pointed out in the discussion in the archives, this function is achieved better with the Interoperable name service. The -ORBInitRef and -ORBDefaultInitRef arguments directly translate to org.omg.CORBA.ORBInitRef and org.omg.CORBA.ORBDefaultInitRef properties which can be used to configure services such as the name service, including the host and port. This issue should be closed no change.    


Issue 2528: Mapping Messaging sendc_ (and sendp_) methods to Java (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary:     I am having a hard time determining just where the sendc_ methods should be declared when the AMI spec is mapped to Java (this issue is evident on sendp_"s as well, but I don"t care right now:).  I am sure that someone has determined this, but it is not obvious in the spec.     

Resolution: Close no change
Revised Text:
Actions taken:
March 11, 1999: received issue
April 3, 2001: moved from the Messaging RTF to the java RTF
May 13, 2002: closed issue

Discussion:
The sendc and sendp operations should almost certainly go into the signature interface rather than the operations interface, but the IDL to Java RTF are better placed to make changes in their specification.   Move to IDL to Java RTF. The sendc and sendp operations should almost certainly go into the signature interface rather than the operations interface, but the IDL to Java RTF are better placed to make changes in their specification. Move to IDL to Java RTF  This issue is subsumed by issue 3068, so close this issue and handle the problem in issue 3068.  


Issue 2531: Serializable objects in Anys need reference semantics (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Section 25.16 (fifth paragraph) says that Streamable types have   reference semantics.  The same should apply to Serializable types,   for consistency and so that valuetypes can be sent across DII.    

Resolution: see below
Revised Text: Insert the following paragraph after the 5th paragraph in Section 16: The insert and extract methods for Serializables implement reference semantics. For a serializable type, an Any is a container in which the data is inserted and held. The Any does not copy or preserve the state of the serializable object that it holds when the insert method is invoked. The contents of the Any are not serialized until the write_value() method is invoked, or the create_input_stream() method is invoked. Invoking create_output_stream() and writing to the Any, or calling read_value(), will update the state of the last serializable object that was inserted into the Any, if one was previously inserted. Similarly, calling the extract_Value() method multiple times will return the same contained serializable object.
Actions taken:
March 12, 1999: received issue
February 27, 2001: closed issue

Discussion:


Issue 2532: Mapping of AbstractBase and abstract interfaces (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: There is a problem with current mapping of abstract interface types   to Java.  These do not implement org.omg.CORBA.portable.IDLEntity.   Even if they did, it would not be possible for the Java to IDL mapping   to distinguish them from abstract valuetypes, which also map to   Java interfaces that implement org.omg.CORBA.portable.IDLEntity.    

Resolution: Close, no change
Revised Text:
Actions taken:
March 12, 1999: received issue
October 3, 2001: closed issue

Discussion:


Issue 2540: _servant_postinvoke (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary:   It would be extremely useful for the _servant_postinvoke call to include     the operation name since this is a logical place to hook into the POA"s     servant locator postinvoke method - which needs the operation name.        Without a provided operation name argument, this information must be     saved in some other, potentially inconvenient, place.       

Resolution: closed, no change
Revised Text:
Actions taken:
March 15, 1999: received issue
January 9, 2001: closed issue

Discussion:
CLOSE, NO CHANGE because "This is typically stored in the ServantObject      returned by _servant_preinvoke (or more correctly a vendor specific      subclass of ServantObject).  Considering that you have to store much      more than just the operation name (i.e. the Cookie for ServantLocators)      I'm not sure why the operation name is of particular concern."    


Issue 2550: Dealing with reserved suffixes (e.g. POA) (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: ptc/98-10-14 changes the mapping of names for skeleton classes; for:          Module M {         interface Face {};       };      the name of the skeleton and tie classes are now M.FacePOA and M.FacePOATie   instead of the C++-style POA_M.Face and POA_M.Face_tie.    

Resolution: Close, no change.
Revised Text:
Actions taken:
March 18, 1999: received issue
February 27, 2001: closed issue

Discussion:
Close, no change. Section 2.1 seems clear that the mapping rules apply to names of the form *interface*POA, not  to plain POA


Issue 2608: Java - Mapping for Struct issue (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The Mapping of OMG IDL to Java, Section 25-20, Mapping for Struct, has a   String field that is not initialized.  I would like to consider that the   String value is initialized to a empty String within a Struct eg., String   foo = new String();      I have an application with a Sequence of Structs.  The Struct has two   attributes, a boolean and String.  The boolean is initialized to "false"   but the String is not initialized.  When I try to add the containing   object, the attribute of Sequence of Structs fails.  I do not want to   require the use to initialize each Struct within the Sequence  before   createing the object.          

Resolution:
Revised Text:
Actions taken:
April 14, 1999: received issue
January 9, 2001: closed issue

Discussion:
In Section 25-20, Mapping for Struct, have the String value be initialized to      an empty String within a Struct eg., String foo = "";    


Issue 2609: Issues with ObjectImpl implementations (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: I have some issues with the defined implementation of methods on   org.omg.CORBA.portable.ObjectImpl.      First, document 98-10-14 says the definitive place to find the   implementation for this class is in some zip file which I haven"t been able   to find.  Is it available somewhere?  Since I couldn"t find the zip file,   I"m depending on 98-10-14 for the implementation.      Second, given that all ObjectImpl methods delegate their implementation to   a locally contained Delegate, if any given ObjectImpl subclass has not been   connected to an ORB, then it does not have a delegate, and calling any of   these methods causes a NullPointerException to be thrown.  Is there a   "friendlier" way to fail?  Or at least a more intuitively obvious   exception?      Finally, toString, hashCode, and equals are methods common to ALL Java   Objects.  These methods should ALWAYS behave as expected, ie., no   exceptions should be thrown.  These were NOT defined to be implemented on   ObjectImpl in CORBA 2.2.  They are defined to be implemented by document   98-10-14.  These methods should either:  not be implemented at all on   ObjectImpl; or be implemented in such a way that they do not throw   NullPointerException.    

Resolution: Close, no change
Revised Text:
Actions taken:
April 15, 1999: received issue
February 27, 2001: closed issue

Discussion:
Close, no change. All the points made in the issue are addressed in the current specification.  If Delegate is not set, BAD_OPERATION is thrown.  The implementations of toString, hashCode, and equals test for null Delegate and do reasonable things if it is.  (Perhaps this one got resolved earlier and somehow didn't get marked as closed?)


Issue 2647: Modification of Constant Mapping (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: When we split the mapping of interfaces into the operations and signature   interfaces, we had to make a decision what to do with constants that are   declared within interfaces.   At the time it seemed that most analogous thing to do was to leave it on   the signature interface.   Upon further consideration it would probably be better if it were on the   operations interface. This would make it available on the server side. This   is a backwards compatible change because operations is inherited by the   signature interface so the contstant would still be visible to clients   without changing their code. It only involves a small change to the   generated code.    

Resolution:
Revised Text: An Interface: Para 1: change "in either the Java signature interface" to "in either the Java operations interface" Add a new para following para 1: "Note that because the signature interface extends the operations interface for non-abstract IDL interfaces, the constant is available in all the mapped Java interfaces." In the example: Move the declaration: int aLongerOne = (int) (-321L) from interface Face to interface FaceOperations
Actions taken:
May 10, 1999: received issue
January 9, 2001: closed issue

Discussion:


Issue 2661: Valuetype packages (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: For certain IDL types defined in an interface Foo, the Java classes are   placed in the package FooPackage. The reason given in the mapping document   is that Java classes cannot be defined in Java interfaces, therefore a new   package is required.      However, since valuetypes are defined as abstract classes, does that imply   that IDL types such as struct, exception, etc., that are defined within a   valuetype are mapped to nested classes of the valuetype class?  Or is a   separate package used, a la interfaces?    

Resolution:
Revised Text: In section 1.2.1, change the fifth bullet to: * The nested scope Java package name <type>Package, where <type> is the name of an IDL interface, valuetype, struct, union or exception (Section 1.17, "Mapping for Certain Nested Types," on page 1-61). And in section 1.17, change the text to: IDL allows type declarations nested within interfaces. Java does not allow classes to be nested within interfaces. Hence those IDL types that map to Java classes and that are declared within the scope of an interface must appear in a special "scope" package when mapped to Java. For consistency, the "scope" package is also used for those IDL type declarations nested within valuetypes, structs, unions and exceptions. IDL types that contain these nested type declarations will generate a scope package to contain the mapped Java class declarations. The scope package name is constructed by appending Package to the IDL type name.
Actions taken:
May 25, 1999: received issue
January 9, 2001: closed issue

Discussion:


Issue 2721: DII and SystemException semantics (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
There needs to be a clarification of the expected semantics for DII  Request objects when a system exception is received over-the-wire  after a call to invoke().

Resolution: Close no change
Revised Text:
Actions taken:
June 9, 1999: received issue
January 19, 2000: Deferred
May 13, 2002: closed issue

Discussion:
This issue is lacking in detail and discussion


Issue 2770: Java substitutability issue: value instance -> interface type (java-rtf)

Click
here for this issue's archive.
Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl(at)ubs.com)
Nature: Uncategorized Issue
Severity:
Summary:
How is it possible to substitute an instance of a value type, that supports  an interface, to a parameter whose formal type is the interface?  

Resolution: Close no change.
Revised Text:
Actions taken:
June 25, 1999: received issue
May 13, 2002: closed issue

Discussion:
This is addressed in section 5.2.5.1 of the CORBA 2.5 specification: it is not possible to do what is requested, because the value type is not a subtype of the interface. Therefore this issue should be closed.  


Issue 2823: Java mapping for PolicyType... (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
formal-99-07-53 (IDL to Java Language Mapping Specification) has the following  method signature in ORB (page 1-83):  public Policy create_policy(short policy_type, Any val)       throws org.omg.CORBA.PolicyError  whereas formal-98-12-01 (CORBA) has PolicyType defined as (page 4-20):  typedef unsigned long PolicyType; Thus, shouldn't the Java mapping be?:  public Policy create_policy(int policy_type, Any val) throws org.omg.CORBA.PolicyError  

Resolution: closed, editorial change
Revised Text:
Actions taken:
July 28, 1999: received issue
January 19, 2000: Deferred
April 17, 2001: closed issue

Discussion:


Issue 2889: Should Any.extract_string work for bounded strings? (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: It is not clear from the OMG specs or from looking at existing Java ORB   products what behavior is intended for the following case:    1. Create an Any with a TypeCode for a bounded string.    2. Call extract_string on the Any object.      I have tried this on two Java ORBs and it fails in both cases.  It works   when the Any"s TypeCode is for an unbounded string.  The spec is silent on   whether or not this should work.  The only relevant statement in the spec is   the following from section 1.16:    

Resolution: close no change
Revised Text:
Actions taken:
September 15, 1999: received issue
April 28, 2003: closed issue

Discussion:
I can't see any reason why this should not work. It works in the current Sun ORB. I also do not see any place in the mapping spec or in the core spec where this question is addressed. It seems that this issue really has more to do with the core CORBA architecture than the Java mapping. As no one has made any comment on this issue in over 3 years, I propose that we close it no change.   


Issue 2979: Java SystemException should contain nested exception field (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
The Java org.omg.CORBA.SystemException class should contain a nested exception  field.  This would assist debugging when a Java exception occurs locally   within the client ORB when marshalling a request or unmarshalling a reply.  At present, when generic system exceptions such as COMM_FAILURE or BAD_PARAM  are returned to the application by the client ORB, it can be difficult to   identify the precise lower-level failure that caused the problem.    This issue applies specifically to system exceptions arising locally within  a Java client, not those returned by the server to the client.  

Resolution: see above
Revised Text:
Actions taken:
November 4, 1999: received issue
May 13, 2002: closed issue

Discussion:
JDK 1.4 has added nested exceptions to all exceptions. Any Throwable can have a nested Throwable added simply by calling the initCause method. This supports general exception chaining. Given this change in Java, we should leave this aspect of error handling as an implementation detail. So, close this issue no change.   


Issue 3068: Messaging sendc and sendp missing from portability interfaces (java-rtf)

Click
here for this issue's archive.
Source: Ericsson (Mr. Chris Smith, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
The Messaging Specification was adopted before Java Portability  layer was really in place. In order to make portability work  with the asynchronous stubs which will in future be generated,   some things may be added to the portability interface.      Each stub has a sendc_<op> and sendp_<op> operation which  will need to call on the portable stub layer.    A first glance at the requirements to make a portable   implementation suggest that a sendc_invoke and sendp_invoke  operation will probably need to be added to ObjectImpl and  Delegate.    I dont know if this is viewed as a "compatible" class change  for JDK, or whether we will need to put derived classes   in CORBA_3_0 package....

Resolution:
Revised Text:
Actions taken:
November 23, 1999: received issue
April 3, 2001: moved from the Messaging RTF to the Java RTF

Discussion:
Move to Java RTF?  Clearly an IDL Java mapping issue. Send to IDL-Java RTF   


Issue 3204: ORB Init problems (java-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Russell Butek, )
Nature: Uncategorized Issue
Severity:
Summary:
 Being new to this game, what is the "Java ORB instance" problem that you  > tried solving?  There is another problem with the Java ORB that I'd also  > like to bring up, but I don't know the proper place to do it.  Would the  > Java RTF address it?  >   > The problem:  the spec talks about an ORB ID.  The Java mapping, for some  > reason, chose to ignore the ID.  I'd like to understand the reason why.  > Could you enlighten us?

Resolution: see above
Revised Text:
Actions taken:
December 6, 1999: received issue
May 13, 2002: closed issue

Discussion:
ORBId is now provided as a result of the Object Reference Template spec. Close no change  


Issue 3209: Illegal return statement (java-rtf)

Click
here for this issue's archive.
Source: NetAcquire Corporation (Mr. Joachim Achtzehnter, joachima(at)netacquire.com)
Nature: Uncategorized Issue
Severity:
Summary:
The method _releaseReply in class org.omg.CORBA.portable.ObjectImpl  has a return value of type void, yet the specification requires this  implementation:    public void _releaseReply(org.omg.CORBA.portable.InputStream is) {    return _get_delegate().releaseReply(this, is);  }    The return statement is illegal in a method with a void return type. Should  delete the word 'return' from the specification.    PS: Editorial: the diagram on page 1-115 has 'CORBA' missing from some  of the class names.  

Resolution: Closed...editorial issue
Revised Text:
Actions taken:
January 11, 2000: received issue
February 7, 2000: closed issue

Issue 3267: How to create marshalel data of java.lang.Throwable instance? (java-rtf)

Click
here for this issue's archive.
Source: Fujitsu (Mr. Masayoshi Shimamura, shima.masa(at)jp.fujitsu.com)
Nature: Uncategorized Issue
Severity:
Summary:
I don't understand that how to create marshaled data of  java.lang.Throwable instance to set it to context_data in  UnknownExceptionInfo.     In CORBA 2.3.1, section "13.6.7 Object Service Context" on 13-25 page  says:        UnknownExceptionInfo identifies a CDR encapsulation of a marshaled instance      of a java.lang.throwable or one of its subclasses as described in Java      to IDL Language Mapping, Section 1.4.8.1, "Mapping of UnknownExceptionInfo      Service Context," on page 1-32.    In Java to IDL Language Mapping specification revised by RTF  (ptc/99-03-09), section "28.4.8.1 Mapping of UnknownExceptionInfo  Service Context" on page 28-32 says:        CORBA UNKNOWN exceptions whose GIOP Reply message includes an      UnknownExceptionInfo service context containing a marshaled      instance of java.lang.Throwable or one of its subclasses are mapped      to RMI exceptions according to the type of the object contained in      the service context, as shown in follows:      -------------------------------------------------------------------      UnknownExceptionInfo          RMI Exception      -------------------------------------------------------------------      java.lang.Error               java.rmi.ServerError      java.rmi.RemoteException      java.rmi.ServerException      java.lang.RuntimeException    java.rmi.ServerRuntimeException(JDK 1.1)                                    java.lang.RuntimeException(Java 2)         -------------------------------------------------------------------    It seems to me that these specifications above are not clear. How to  create the context_data from java.lang.Throwable instance? I guess the  context_data should be created by one of following two ways. Which way  is correct? Or is there any other correct way?    1. A instance of java.lang.Throwable or its subclasses should be     serialized by Java language specific serialization function and then     should be set to the context_data as sequence of octet.    2. A instance of java.lang.Throwable or its subclasses should be     marshaled as CORBA Value type data and then should be set to the     context_data as sequence of octet.    

Resolution: see revised text below
Revised Text: Add the following sentence to the end of section 1.4.7: "The Java exception is marshaled using the rules for CDR marshaling of value types as defined by the GIOP specification, applied in conjunction with the rules for mapping RMI/IDL value types to IDL as defined in section 1.3.5 of this specification."
Actions taken:
February 1, 2000: received issue
May 24, 2001: closed issue

Discussion:
Section 1.4.7 states that "All other Java exceptions are marshaled as CORBA UNKNOWN system exceptions whose GIOP  Reply message includes an UnknownExceptionInfo service context containing the marshaled Java exception thrown by the server  implementation."   The phrase "marshaled Java exception" should be clarified to avoid possible confusion as to how this marshaling is done.


Issue 3320: Java language mapping: Tie classes for local interfaces. (java-rtf)

Click
here for this issue's archive.
Source: ICL (Mr. Chris Wood, )
Nature: Uncategorized Issue
Severity:
Summary:
The new java mapping as specified in 99-10-10 for local classes generates a  class which is subclassed much as previous implementations subclassed the  POA class.     ie:    local interface Test {  	void call();  };    maps to:    class Test extends org.omg.CORBA.portable.LocalImpl implements  TestOperations {}    then implementers subclass Test to get desired functionality.    I believe there is a need for a tie class similar to the POATie class:    class TestTie extends Test {  	public TestTie(TestOperations delegate) {  		_delegate = delegate;   	}    	private TestOperations _delegate;    	public void call() {  		_delegate.call();  	}  }        Also the implementation for _hash is not correct :    public int _hash(int max) {  	// return hashCode(); // incorrect, return value exceeds max.  	return hashCode() % (max+1);  }  

Resolution: Incorporate revised text and close issue
Revised Text: In section 1.20.2.7, add a new subsection at the end of the section titled: Ties for local interface implementations Ties for local interfaces are defined in a manner very similar to the normal POA-based Ties. The major difference is that no POA is present in the Tie, since local interfaces do not use the POA. Ties are useful for local interfaces for the same reason as they are for normal interfaces: java does not support multiple inheritance. For each local interface <interface_name> the mapping defines a Java local tie class as follows: //Java public class <interface_name>LocalTie extends LocalBase { private <interface_name>Operations _impl; public <interface_name>LocalTie ( <interface_name>Operations delegate ) { this._impl = delegate; } public <interface_name>Operations _delegate() { return this._impl; } public void _delegate (<interface_name>Operations delegate ) { this._impl = delegate; } // For each <method> defined in <interface_name>Operations // (the return statement is present for methods with non-void // <method_return_type>): public <method_return_type> <method>( <params> ) { [return] _impl.<method>( <param_names> ); } } Assume that we have the interface Alocal defined as follows: local interface A { short op1() ; void op2( in long val ) ; } ; Then the LocalTie class for ALocal is as follows: public class ALocalTie extends ALocalBase { public ALocalTie ( AOperations delegate ) { this._impl = delegate; } public AOperations _delegate() { return this._impl; } public void _delegate (AOperations delegate ) { this._impl = delegate; } public short op1 () { return _impl.op1(); } public void op2 (int val) { _impl.op2(val); } private AOperations _impl; } To implement a local interface using the Tie approach, a developer must write an implementation class, which implements the operations class associated with the interface they wish to implement. The developer then instantiates an instance of the implementation class and uses this instance in the constructor of the LocalTie class associated with the interface. The Tie class then provides an implementation of the local interface.
Actions taken:
February 16, 2000: received issue
May 13, 2002: closed issue

Discussion:
.  


Issue 3323: Need clarification on custructor(s) for stream-based stubs/skeletons (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
In OMG IDL to Java Language Mapping spec, $1.21.51 "Stub/Skeleton Architecture" there are examples of stream- and DSI- based stubs/skeletons. These examples do not provide any constructors (this mean thay have only default ones). But, it seems that signatures of constructors should be clarified, because orb vendors have a freedom in defining these signatures. For example, the VisiBroker's 4.0 idl2java compiler generates stubs that have only default constructors, but in jdk 1.2 there stubs that have only constructors that take org.omg.CORBA.portable.Delegate as a single parameter. This leads to impossibility for generated stubs to extend the jdk 1.2 provided ones.

Resolution: closed, duplicate of issue 3707
Revised Text:
Actions taken:
February 11, 2000: received issue
October 23, 2000: closed issue

Issue 3410: IDL/Java: methods marked final in PortableServer.Servant (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
The Java language mapping  says (p 1-89) that the following four  methods in PortableServer.Servant may be overridden by application  programmers:    _is_a, _default_POA(), _non_existent(), _get_interface().    The Java source files provided with the written spec. have all   these methods marked as final, so they cannot be overridden. While  the spec. says the source files are authoritative, this seems to  be a clear contradiction between text and code.     If the intention whether or not these methods may be overridden has   changed, this needs to be explained in the text (for application  programmers). Otherwise, it might just be an editorial issue, i.e.   the Java source files need to be corrected.  

Resolution: see below
Revised Text: Remove "final" from the _is_a, _default_POA(), _non_existent(), and _get_interface() methods in the source code file org/omg/PortableServer/Servant.java
Actions taken:
March 11, 2000: received issue
February 27, 2001: closed issue

Issue 3570: org.omg.CORBA.portable.UnknownException does not have all constructors (java-rtf)

Click
here for this issue's archive.
Source: Borland Software Corporation (Mr. Vijaykumar Natarajan, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
All system exceptions have the following constructors, (BAD_PARAM as eg.)    BAD_PARAM();  BAD_PARAM(int minor_code, CompletionStatus status);  BAD_PARAM(String message);  BAD_PARAM(String message, int minor_code, CompletionStatus status);    UnknownException however has only one. This seems inconsistent.    Proposal:    Add the following constructors to org.omg.CORBA.portable.UnknownException  UnknownException(Throwable orig, int minor_code, CompletionStatus status);  UnknownException(Throwable orig, String message);  UnknownException(Throwable orig, String message, int minor_code,  CompletionStatus status);

Resolution:
Revised Text: Add the following constructors to org.omg.CORBA.portable.UnknownException UnknownException(Throwable orig, int minor_code, CompletionStatus status); UnknownException(Throwable orig, String message); UnknownException(Throwable orig, String message, int minor_code, CompletionStatus status);
Actions taken:
April 19, 2000: received issue
January 9, 2001: closed issue

Issue 3575: Custom marshal does not work for certain valuetypes (java-rtf)

Click
here for this issue's archive.
Source: Borland Software Corporation (Mr. Vijaykumar Natarajan, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
This was discussed in the core rtf in boston, and the consensus was that this  would be a java only issue and could be fixed in the language mapping directly.    The issue:  Boxed valuetypes, abstract interfaces and regular valuetypes (these can be  marshaled but not in optimized format) cannot be marshaled or unmarshaled when  using custom marshaling. This is because the Data*Stream APIs do not provide the  requisite interfaces.    Proposal:    Add two new interfaces in java defined as follows  package org.omg.CORBA;    public interface CustomOutputStream extends org.omg.CORBA.DataOutputStream {    public void write_Value(java.io.Serializable value, java.lang.String repId);  // optimized valuetype writes    public void write_Value(java.io.Serializable value,  org.omg.CORBA.portable.BoxedValueHelper helper); //boxed valuetypes    public void write_Abstract(java.lang.Object obj); // abstract interfaces  }    public interface CustomInputStream extends org.omg.CORBA.DataInputStream {      public java.io.Serializable read_value(java.lang.String repId); // optimized  valuetype reads      public java.io.Serializable read_value(java.lang.Class expected); // Is this  needed???      public java.lang.Object read_abstract_interface(); // abstract interfaces      public java.lang.Object read_abstract_interface(java.lang.Class expected);  // Is this needed???      public java.io.Serializable  read_value(org.omg.CORBA.portable.BoxedValueHelper helper); // boxed valuetypes  }  

Resolution: resolved, see below
Revised Text: Add paragraph to section 1.13.1.3 CustomMarshal interface The stream APIs that are passed as arguments for the marshal and unmarshal methods are not sufficient to marshal all valuetypes. In order to support custom marshaling of valuetypes, the ORB shall actually pass an instance of CustomOutputStream and CustomInputStream to these methods respectively (see section 1.21.5 for information on Custom stream APIs). Add section following Streaming APIs (section 1.21.4), and adjust section numbers following; also add the CustomOutputStream and CustomInputStream interfaces to the Source zip file, in the org.omg.CORBA package 1.21.5 Custom Streaming APIs The Custom streaming APIs provide for the reading and writing of all the different valuetypes that may be custom marshaled. The semantics of the methods in these interfaces are identical to their counterparts (with identical signatures) in the CORBA_2_3 portable streaming APIs. public interface CustomOutputStream extends org.omg.CORBA.DataOutputStream { public void write_value(java.io.Serializable value); public void write_value(java.io.Serializable value, java.lang.String repId); public void write_value(java.io.Serializable value, org.omg.CORBA.portable.BoxedValueHelper helper); public void write_abstract_interface(java.lang.Object obj); } public interface CustomInputStream extends org.omg.CORBA.DataInputStream { public java.io.Serializable read_value(); public java.io.Serializable read_value(java.lang.String repId); public java.io.Serializable read_value(java.lang.Class expected); public java.lang.Object read_abstract_interface(); public java.lang.Object read_abstract_interface(java.lang.Class expected); public java.io.Serializable read_value( org.omg.CORBA.portable.BoxedValueHelper helper); // boxed valuetypes }
Actions taken:
April 20, 2000: received issue
October 3, 2001: closed issue

Issue 3633: Request clarification for use of alias typecodes in typedef helper classes (java-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity:
Summary:
I've noticed that there appears to be a lack of consistency between ORB vendors  when it comes to the use of alias typecodes in Java helper classes generated for  IDL typedefs.    Specifically, both Visibroker 4 and Orbix 2000 return an appropriate alias  typecode from the helper class's type () method. However, the Visibroker 4  generated helper class does not use it in either the insert or extract methods,  whilst the Orbix 2000 helper class uses it to set the typecode of the Any passed  to the insert method and to check that the Any passed to the extract method is  of the correct type.    Would it be possible to clarify which of these approaches is correct? From the  specification of the IDL to Java mapping, it appears that typdef types are  intended to be 'unwound' to the first non-typedef type, which would suggest that  the first approach is OK. However, if this is the case, for what purpose is the  alias typecode produced, if not for the setting/checking of typecodes of Anys  containing instances of the associated type?  

Resolution: close no change
Revised Text:
Actions taken:
May 19, 2000: received issue
April 28, 2003: closed issue

Discussion:
Either approach appears to be valid, especially since the typecode equality semantics simply unwind tk_alias typecodes until they reach a non-tk_alias typecode. I think no change is needed here


Issue 3643: Description of ORB.init parameters insufficient (java-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Russell Butek, )
Nature: Uncategorized Issue
Severity:
Summary:
I have a number of questions/concerns about the description/usage of  ORB.init arguments/properties.    1.  There are only two properties described in the Java mapping spec:  org.omg.CORBA.ORBClass and org.omg.CORBA.ORBSingletonClass.  Setting these  via property are described, but not setting these via application string  array (ie., args in main).  Yet the spec says these values can be obtained  via the args array.  I believe most folks assume "-ORBClass xxx" is the  convention, since that's what the JDK's ORB uses, but it's not documented.      2.  Ditto for applet parameters.  It's assumed that they are of the form    <param name = "org.omg.CORBA.ORBClass" value = "xxx">    but it is not documented.      3.  Can this convention be generalized to accommodate the argument naming  convention in the core spec?  If we follow the convention that says  org.omg.CORBA.ORBClass becomes -ORBClass; then can we say that a parameter  -ORBXXX may also be specified by the property or applet parameter  org.omg.CORBA.ORBXXX?      4.  The text around the ORB arguments is tightly coupled to only ORBClass  and ORBSingletonClass.  It does not seem to expect other args/properties.  For example:  "...when creating an ORB instance, the class names of the ORB  implementation are located using the following search order: ...".  I  assume the following search order also applies to any args/props.      5.  The spec doesn't allow for extensions.    "See Table 1-3 for a list of the property names and values that are  recognized by  ORB.init. Any property names not in this list shall be ignored by  ORB.init()."    Has the INS spec updated this table with -ORBInitRef and  -ORBDefaultInitRef, for example?  And the interceptor spec assumes that  services are allowed to have their own arguments.  And what about  proprietary extensions?  Given the word "shall", any extensions are  non-CORBA-compliant.      6.  Repeated arguments fall apart when presented as Properties.  For  example, the INS spec allows for the following invocation:    java myapp -ORBInitRef XX=xx -ORBInitRef YY=yy -ORBInitRef ZZ=zz    Since Properties entries are <key, value> pairs, and only one pair for a  given key can exist, then if we tried entering the above as Properties we'd  only get on of them, not all.  I'm not sure how to fix this.  Dictate that  XX, YY, ZZ be the end of the ORBInitRef string rather than the start of a  new string, perhaps?  So then, specifying these as system properties for  example, we'd have:    java myapp -Dorg.omg.CORBA.ORBInitRefXX xx -Dorg.omg.CORBA.ORBInitRefYY yy  -Dorg.omg.CORBA.ORBInitRefZZ zz    That causes ugly parsing problems.  We'd have to search the whole list of  properties that contained a key that merely BEGAN with  "org.omg.CORBA.ORBInitRef".  And this falls apart in applets; we can get a  list of all Properties, but we cannot get a list of all applet parameters.  Personally I think this is a failing in the applet class, but that's life  as we know it.      I'm sorry to raise this as one issue instead of six, but most of these  points are tightly coupled, so I didn't want to distance them from each  other.  And I'd like them all to be answered together anyway.  

Resolution:
Revised Text:
Actions taken:
May 25, 2000: received issue

Issue 3654: OMG ZIP FILE ISSUES for IDL to Java RTF (01) (java-rtf)

Click
here for this issue's archive.
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

Issue 3655: OMG ZIP FILE ISSUES for IDL to Java RTF (02) (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Anita Jindal, nobody)
Nature: Uncategorized Issue
Severity: Significant
Summary:
(2).  Wrong mapping for all Enum types, specifically method from_int() is not   according to IDL to Java mapping spec.    	According to ptc/00-01-08.pdf, the mapping for from_int() method is  	  	// get enum with specified value public   	static <enum_name> from_int(int value);    whereas in the OMG published interfaces for all Enums, the mapping for this  signature is something like:    	public static IdAssignmentPolicyValue from_int(int val)                         throws org.omg.CORBA.BAD_PARAM                     PLS. NOTE THAT IT IS THROWING AN EXCEPTION NOT SPECIFIED BY THE MAPPING.

Resolution: Close, duplicate of 3669
Revised Text:
Actions taken:
May 30, 2000: received issue
January 9, 2001: closed issue

Issue 3656: OMG ZIP FILE ISSUES for IDL to Java RTF (03) (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Anita Jindal, nobody)
Nature: Uncategorized Issue
Severity: Significant
Summary:
(3).   org.omg.PortableServer.ServantLocatorPackage.CookieHelper.java is   published for "native" Cookie.  The IDL to Java specification does not specify  mapping for Helper classes for native types, nor does it mention that one  exists for native types.  This should be removed as part of the ZIP file  or the IDL to Java specification needs to be modified to completely specify the  mapping for CookieHelper.java

Resolution:
Revised Text: Remove org.omg.PortableServer.ServantLocatorPackage.CookieHelper.java from the ZIP file.
Actions taken:
May 30, 2000: received issue
January 9, 2001: closed issue

Issue 3657: OMG ZIP FILE ISSUES for IDL to Java RTF (04) (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Anita Jindal, nobody)
Nature: Uncategorized Issue
Severity: Significant
Summary:
(4).  The "const" mapping does not specify "public static final", please note  that without this, no one will be able to directly access the value specified  for the const's directly.

Resolution: close, no change
Revised Text:
Actions taken:
May 31, 2000: received issue
January 9, 2001: closed issue

Discussion:
Close, no change.  The Java language automatically declares      constants in an interface "public static final".


Issue 3658: OMG ZIP FILE ISSUES for IDL to Java RTF (05) (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Anita Jindal, nobody)
Nature: Uncategorized Issue
Severity: Significant
Summary:
(5).  The OMG ZIP file is missing the following interfaces:    	ServantActivatorHelper.java  	ServantActivatorPOA.java  	_ServantActivatorStub.java  	ServantLocatorHelper.java  	ServantLocatorPOA.java  	_ServantLocatorStub.java    In order to enable, application programmers, register their own servant managers  these need to be provided as part of the PortableServer package (in the absence  of the local interfaces).

Resolution: close, no change
Revised Text:
Actions taken:
May 31, 2000: received issue
January 9, 2001: closed issue

Discussion:
CLOSE, NO CHANGE, because "these files are generated from standard IDL and      are vendor-specific. There would actually be more files on the "missing"      list, except that "dummy" versions were generated so that everything      provided would compile."    


Issue 3659: OMG ZIP FILE ISSUES for IDL to Java RTF (06) (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Anita Jindal, nobody)
Nature: Uncategorized Issue
Severity: Significant
Summary:
(6).  The mapping for org.omg.PortableServer.Servant.java specifies the   following signature for _get_interfaces.        final public org.omg.CORBA.InterfaceDef _get_interface() {          return _get_delegate().get_interface(this);      }    Also, for org.omg.PortableServer.portable.Delegate.java        org.omg.CORBA.InterfaceDef get_interface(                      org.omg.PortableServer.Servant self);      The above mapping for server-side should be changed to match the  client side mapping.  Please note, that in the   org.omg.CORBA.portable.ObjectImpl, the following signature has been deprecated.        /**      *@deprecated Deprecated by CORBA 2.3      */      public org.omg.CORBA.InterfaceDef _get_interface() {          return _get_delegate().get_interface(this);      }    the new signature according to CORBA 2.3 spec is:        public org.omg.CORBA.Object _get_interface_def() {          return _get_delegate().get_interface_def(this);      }  

Resolution: see below
Revised Text: - Add the following paragraph after the third paragraph in section 1.19.11: The _get_interface() and _get_interface_def() operations both return an InterfaceDef object that defines the runtime type of the CORBA::Object on which they are invoked. The deprecated _get_interface() method returns the InterfaceDef directly as an InterfaceDef. Because this operation is deprecated, new applications should not use it, and it may be removed in a future release of this specification. The _get_interface_def() operation returns the InterfaceDef as a CORBA::Object, and the invoker of _get_interface_def() must narrow the CORBA::Object to an InterfaceDef in order to use it. - Replace the first paragraph of section 1.20.2.1 with the following paragraphs: The PortableServer module for the Portable Object Adapter (POA) defines the native Servant type. In Java, the Servant type is mapped to the Java org.omg.PortableServer.Servant class. The implementation of the Servant must delegate all operations to the org.omg.PortableServer.portable.Delegate class defined in Section 1.21.8, "Servant Delegate", on page 1-127. The Servant class is defined as follows: - In section 1.20.2.1, replace the three occurrences of the type Delegate with org.omg.PortableServer.portable.Delegate to match the code in ptc/00-07-04.zip. - In section 1.20.2.1, change the signature: public org.omg.CORBA.InterfaceDef _get_interface() { return _get_delegate().get_interface(this); } to: /** @deprecated Deprecated by CORBA 2.4 */ public org.omg.CORBA.InterfaceDef _get_interface() { return _get_delegate().get_interface( this ) ; } public org.omg.CORBA.Object _get_interface_def() { return _get_delegate().get_interface_def(this); } - In section 1.20.2.1 on page 1-92, replace the description of _get_interface with the following text: The _get_interface_def() operation returns an InterfaceDef object as a CORBA::Object that defines the runtime type of the CORBA::Object that is implemented by the Servant. The invoker of _get_interface_def must narrow the result to an InterfaceDef in order to use it. Servant provides a default implementation of _get_interface_def() that can be overridden by derived servants if the default behavior is not adequate. As defined in the CORBA 2.3.1 specification, section 11.3.1, the default behavior of _get_interface_def() is to use the most derived interface of a static servant or the most derived interface retrieved from a dynamic servant to obtain the InterfaceDef. This behavior must be supported by the Delegate that implements the Servant. - Delete section 1.21.7, as it does not add anything after the above changes to 1.20.2.1. The Delegate should be defined under Portability, while the Servant should be completely defined under Server-Side mapping. - In section 1.21.8, and in the Source code for PortableServer.portable.Delegate, replace the text org.omg.CORBA.InterfaceDef get_interface( org.omg.PortableServer.Servant self); with the text /** @deprecated Deprecated by CORBA 2.4 */ org.omg.CORBA.InterfaceDef get_interface( org.omg.PortableServer.Servant self); org.omg.CORBA.Object get_interface_def( org.omg.PortableServer.Servant self); - In the Source code for PortableServer.Servant: change the _get_interface method to /** @deprecated Deprecated by CORBA 2.4 */ public org.omg.CORBA.InterfaceDef _get_interface() { return _get_delegate().get_interface( this ) ; } and add the following method: public org.omg.CORBA.Object _get_interface_def() { // First try to call the delegate implementation class's // "Object get_interface_def(..)" method (will work for ORBs // whose delegates implement this method). // Else call the delegate implementation class's // "InterfaceDef get_interface(..)" method using reflection // (will work for ORBs that were built using an older version // of the Delegate interface with a get_interface method // but not a get_interface_def method). org.omg.PortableServer.portable.Delegate delegate = _get_delegate(); try { // If the ORB's delegate class does not implement // "Object get_interface_def(..)", this will throw // an AbstractMethodError. return delegate.get_interface_def(this); } catch( AbstractMethodError aex ) { // Call "InterfaceDef get_interface(..)" method using reflection. try { Class[] argc = { org.omg.PortableServer.Servant.class }; java.lang.reflect.Method meth = delegate.getClass().getMethod("get_interface", argc); Object[] argx = { this }; return (org.omg.CORBA.Object)meth.invoke(delegate, argx); } catch( java.lang.reflect.InvocationTargetException exs ) { Throwable t = exs.getTargetException(); if (t instanceof Error) { throw (Error) t; } else if (t instanceof RuntimeException) { throw (RuntimeException) t; } else { throw new org.omg.CORBA.NO_IMPLEMENT(); } } catch( RuntimeException rex ) { throw rex; } catch( Exception exr ) { throw new org.omg.CORBA.NO_IMPLEMENT(); } } }
Actions taken:
May 31, 2000: received issue
February 27, 2001: closed issue

Issue 3665: Java ORB Id (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Harold Carr, Ph.D., nobody)
Nature: Uncategorized Issue
Severity:
Summary:
There are several reasons that Java ORB.init should support  ORBId (without compromising security).  For example:    - Services built on Portable Interceptors work in relation to the ORB  with which they are registered.  There needs to be some means of  identifying this ORB (besides its reference) so other services or  facades (e.g., JNDI) can use the same ORB.    - A Server Activation Framework needs an ORB Id to identify a particular  orb (which hosts a persistent POA) within a server.  The triple:  server id, orb id, poa name is *conceptually* embedded in the adapter  id of a POA making it unique.  

Resolution:
Revised Text:
Actions taken:
May 30, 2000: received issue
August 18, 2000: moved from interceptors ftf to java RTF

Discussion:
  Incorporate change and close issue. However, this is out-of-scope for the interceptors FTF. It is being  transferred to the IDL to java RTF.


Issue 3668: Possible problem with IDL to Java mapping of fixed-point decimal types (java-rtf)

Click
here for this issue's archive.
Source: SAP SE (Mr. Evan Ireland, eireland(at)sybase.com)
Nature: Uncategorized Issue
Severity:
Summary:
I'm wondering how other folks interpret the following section from CORBA 2.3.1  (for the CDR Transfer Syntax).    15.3.2.8 Fixed-Point Decimal Type      The IDL fixed type has no alignment restrictions, and is represented as shown in Table    15-4 on page 15-13. Each octet contains (up to) two decimal digits. If the fixed type    has an odd number of decimal digits, then the representation begins with the first (most    significant) digit � d0 in the figure. Otherwise, this first half-octet is all zero, and the    first digit is in the second half-octet � d1 in the figure. The sign configuration, in the    last half-octet of the representation, is 0xD for negative numbers and 0xC for positive    and zero values.    I interpret this to mean that the encoded size of any given fixed-point  decimal IDL type is determined statically according to the 'digits' and 'scale'  in the fixed<digits,scale> IDL definition, rather than dynamically by the  number of digits in the value to be encoded.    Unfortunately if my interpretation is correct, there appears to be a problem  in the IDL to Java mapping for fixed-point decimals, as we have  in org.omg.CORBA.portable.OutputStream:      public void write_fixed(java.math.BigDecimal value) ...    Since a Java BigDecimal has a scale but no precision, I would think there  would be a problem if the BigDecimal value "1.23" was to be encoded as  a fixed<5,2>, since the write_fixed method has no 'digits' parameter,  so it doesn't know the correct size for the CDR encoding.  The 'read_fixed' method on the InputStream class has similar problems.    Has anyone encountered this issue before, and if so what was the resolution?

Resolution: see below
Revised Text: In Section 21.4 and in the Source Code: Change org.omg.CORBA.portable.InputStream.read_fixed to /** @deprecated Deprecated by CORBA 2.4 */ java.math.BigDecimal org.omg.CORBA.portable.InputStream.read_fixed() { throw new org.omg.CORBA.NO_IMPLEMENT(); } java.math.BigDecimal org.omg.CORBA.portable.InputStream.read_fixed( short digits, short scale) { throw new org.omg.CORBA.NO_IMPLEMENT(); } Change org.omg.CORBA.portable.OutputStream.write_fixed to /** @deprecated Deprecated by CORBA 2.4 */ void org.omg.CORBA.portable.OutputStream.write_fixed(java.math.BigDecimal value) { throw new org.omg.CORBA.NO_IMPLEMENT(); } void org.omg.CORBA.portable.OutputStream.write_fixed( java.math.BigDecimal value, short digits, short scale) { throw new org.omg.CORBA.NO_IMPLEMENT(); } Add a new subsection at the end of Section 21.4.1: read_fixed The short parameters indicate the digits and scale of the fixed-point decimal. These parameters are needed because when the fixed is read off the stream, the BigDecimal can't be reconstructed to the original digits and scale without explicitly passing in the digits and scale. Add a new subsection at the end of Section 21.4.2: write_fixed The short parameters indicate the digits and scale of the fixed-point decimal. These parameters are needed because the information of the maximum number of digits and scale is lost when the IDL fixed is mapped to a BigDecimal for write_fixed.
Actions taken:
May 31, 2000: received issue
February 27, 2001: closed issue

Issue 3669: Enum mapping issue (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Ken Cavanaugh, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
The IDL to Java mapping spec (ptc/00-02-07) defines the  mapping for IDL to Enums to Java.  The generated enum  class contains a method    public static <TYPE> from_int( int i )    However, the mapping spec does not call for an exception  to be thrown if the parameter does not correspond to a  valid enum for this enum type.    ptc/00-02-08 defines the standard Java classes for  the PIDL native types and the ORB portability interfaces.  It includes several IDL enums in org.omg.CORBA:    AttributeMode, CompletionStatus, DefinitionKind, OperationMode,  ParameterMode, PrimitiveKind, SetOverrideType, and TCKind.    All have signatures similar to:    public static TCKind from_int( int val ) throws org.omg.CORBA.BAD_PARAM    This is not compliant with the specification.    If we look at the definition of BAD_PARAM, it is a SystemException, which  extends java.lang.RuntimeException, so BAD_PARAM, like all system exceptions,  is an unchecked java exception.  Consequently there is no need to declare  BAD_PARAM in the signature of the from_int methods.  However, the behavior is  useful and should be specified.    I think this issue should be resolved with the following changes:    1. Update ptc/00-02-08.zip to remove the "throws BAD_PARAM" clauses     on all from_int methods for enums.       2. Update ptc/00-02-07 section 1.7 as follows:    replace the paragraph    	"The java class for the enum has an additional method from_int(),  	which returns the enum with the specified value."  	  with    	"The java class for the enum has an additional method from_int(),  	which returns the enum with the specified value if the specified  	value corresponds to an element of the enum.  If the specified  	value is out of range, a BAD_PARAM exception with a minor code  	of XXX is raised."  	  where as usual XXX needs to be filled in with an appropriate minor code.  

Resolution:
Revised Text: 1. Update ptc/00-02-08.zip to remove the "throws BAD_PARAM" clauses on all from_int methods for enums. 2. Update ptc/00-02-07 section 1.7 as follows: replace the paragraph "The java class for the enum has an additional method from_int(), which returns the enum with the specified value." with "The java class for the enum has an additional method from_int(), which returns the enum with the specified value if the specified value corresponds to an element of the enum. If the specified value is out of range, a BAD_PARAM exception with a minor code of XXX is raised." where as usual XXX needs to be filled in with an appropriate minor code.
Actions taken:
May 30, 2000: received issue
January 9, 2001: closed issue

Issue 3686: How can org.omg.CORBA.portable.InputStream.read_fixed possibly work? (java-rtf)

Click
here for this issue's archive.
Source: SAP SE (Mr. Evan Ireland, eireland(at)sybase.com)
Nature: Uncategorized Issue
Severity:
Summary:
If you look at the signature of org.omg.CORBA.portable.InputStream.read_fixed,  you will see that it does not accept parameters for the fixed digits and scale.  Since the GIOP CDR encoding for fixed-point decimals does not include meta-data  on the wire (e.g. the scale is not explicit in the wire-encoding), how can the  Java portable InputStream's read_fixed method reliably determine the scale of  the value being read? Maybe I'm missing something, or maybe the mapping spec is  just plain broken. Can someone please shed some light on this.  

Resolution: Close, Duplicate of 3668
Revised Text:
Actions taken:
June 9, 2000: received issue
February 27, 2001: closed issue

Issue 3707: Need clarification on custructor(s) for stream-based (java-rtf)

Click
here for this issue's archive.
Source: Borland Software Corporation (Mr. Vijaykumar Natarajan, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
In OMG IDL to Java Language Mapping spec, $1.21.5.1 "Stub/Skeleton Architecture" there  are examples of stream- and DSI- based   stubs/skeletons. These examples do not  provide any constructors (this mean thay have only default ones). But, it seems that  signatures of constructors should be clarified, because orb vendors have a freedom in  defining these signatures. For example, the VisiBroker's 4.0 idl2java compiler  generates stubs that have only default constructors, but in jdk 1.2 there stubs that  have only constructors that take org.omg.CORBA.portable.Delegate as a single  parameter. This leads to impossibility for generated stubs to extend the jdk 1.2  provided ones.    Since the example is not normative, vendors are free to add whatever constructors they  would like. This makes it impossible to generate code for interfaces that are  inherited from interfaces for which code is generated by another vendor, which is true  especially in the case of Java 2 and its inclusion of some stubs.    I would like to propose the following:  To Seciton 1.21.5.1 under subheading Stub Design, add a bullet:    Stubs are not required to define any constructors. However, if they do define special  constructors, a constructor with no arguments must also be defined.    This ensures that all stubs are guaranteed to have the no argument constructor  irrespective of whether they have other constructors or not.  

Resolution: see below
Revised Text: To Section 1.21.5.1 under subheading Stub Design, add a bullet: Stubs are not required to define any constructors. However, if they do define special constructors, a constructor with no arguments must also be defined.
Actions taken:
June 14, 2000: received issue
February 27, 2001: closed issue

Issue 3750: SystemExceptionHelper missing (java-rtf)

Click
here for this issue's archive.
Source: IONA (Mr. Mark Spruiell, )
Nature: Uncategorized Issue
Severity:
Summary:
There is no standard way for an application to insert/extract  a SystemException into/from an Any. This would be especially  useful for Portable Interceptors, where an exception is provided  in the form of an Any.    In the absence of a SystemExceptionHelper.extract() method, an  application is forced to a) use DynAny or b) compare the  exception's repository ID against dozens of system exception  IDs in order to determine which Helper to use.    Proposal:    Add org.omg.CORBA.SystemExceptionHelper. All of the standard  exception Helper methods are implemented.  

Resolution: see below
Revised Text: In section 1.15.2, add the following paragraph after the first paragraph: "A Helper class is provided for each concrete system exception. In addition, a Helper class is provided for org.omg.CORBA.SystemException which can be used to manipulate system exceptions when the concrete type is unknown. The Helper classes for system exceptions follow the normal rules defined in Section 1.5, "Helpers", on page XX."
Actions taken:
July 19, 2000: received issue
February 27, 2001: closed issue

Discussion:
Proposal:        Add org.omg.CORBA.SystemExceptionHelper. All of the standard    exception Helper methods are implemented.


Issue 3788: Mapping for Sequences -> <sequence_class>Holder (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Ram Jeyaraman, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
Re : ptc/00-01-08 IDL to Java Language mapping spec, Section 1.10    The <sequence_class>Holder class shown below does not implement org.omg.CORBA.portable.Streamable  interface, whereas the basic type holders like ShortHolder implement the Streamable interface.    final public class <sequence_class>Holder {  	public <sequence_element_type>[] value;  	public <sequence_class>Holder() {};  	public <sequence_class>Holder(  		<sequence_element_type>[] initial)  		{...};  	public void _read(  		org.omg.CORBA.portable.InputStream is)  		{...}  	public void _write(  		org.omg.CORBA.portable.OutputStream os)  		{...}  	public org.omg.CORBA.TypeCode _type() {...}

Resolution: see below
Revised Text: Add "implements org.omg.CORBA.portable.Streamable" to final public class <sequence_class>Holder in Section 10.
Actions taken:
August 19, 2000: received issue
February 27, 2001: closed issue

Issue 3794: IDLEntity interface has to be public. (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Hemanth Puttaswamy, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
Interface IDLEntity is declared as package private in the IDL To Java document  (ptc/00-01-08.pdf) Section 14.1.2. I propose it to change it to public.    from     package org.omg.CORBA.portable;   interface IDLEntity extends java.io.Serializable {}    to     package org.omg.CORBA.portable;   public interface IDLEntity extends java.io.Serializable {}

Resolution: editorial fix, issue closed
Revised Text:
Actions taken:
August 29, 2000: received issue
August 31, 2000: closed issue

Issue 3795: Incorrect method declaration in CORBA_2_3/portable/InputStream.java and Out (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Hemanth Puttaswamy, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
Looks like there is a typo in the IDL to Java document(ptc/00-01-08) Section   1.21.4.     The method signature     public java.io.Serializable read_value( org.omg.CORBA.BoxedValueHelper factory)    has to be     public java.io.Serializable read_value( org.omg.CORBA.portable.BoxedValueHelper   factory)     Because BoxedValueHelper belongs to org.omg.CORBA.portable package.    Also The method signature    public void write_value( java.io.Serializable value,                                  org.omg.CORBA.BoxedValueHelper factory)                                                      has to be                             public void write_value( java.io.Serializable value,                                  org.omg.CORBA.portable.BoxedValueHelper factory)                             Again for the same reason.  

Resolution: editorial fix, issue closed
Revised Text:
Actions taken:
August 29, 2000: received issue
August 31, 2000: closed issue

Issue 3801: policy_type should map to a Java int. (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Masood (Max) Mortazavi, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
It appears that there's an error in the OMG specification ptc/00-01-08  OMG IDL to Java Language Mapping. In the mapping for ORB as given in the  org.omg.CORBA.ORB in section 1.19.10, the IDL signature        Policy create_policy(          in PolicyType type,          in any val      ) raises (PolicyError);    has been mapped to        public Policy create_policy(short policy_type, Any val)              throws org.omg.CORBA.PolicyError      However, note that in formal/99-10-07, as in elsewhere, it's clearly  stated that PolicyType is unsigned long        4.9.1 Definition of Policy Object        typedef unsigned long PolicyType;      // Basic IDL definition      interface Policy {          readonly attribute PolicyType policy_type;          Policy copy();          void destroy();      };    and that the Java mapping for unsigned long is an "int" not a  "short," as erroneously implied in 1.19.10 of  ptc/00-01-08.    I believe this is an error in the  ptc/00-01-08 OMG IDL to Java Language  Mapping that needs to be cleared.  

Resolution: closed issue, editorial change
Revised Text:
Actions taken:
August 29, 2000: received issue
April 17, 2001: closed issue

Issue 3818: Operations signatures include throws clauses on system exceptions. (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Ken Cavanaugh, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
There are several places in the IDL to Java mapping spec  (ptc/00-01-08) where operations signatures include  throws clauses on system exceptions.  Since system   exceptions are unchecked Java exceptions, they need  never be declared in operation signatures.  As normal  Java practice only declares checked exceptions, the throws  clauses for unchecked exceptions should be removed.    I have found this problem in the following places in the spec:    p. 58-61 various methods throw DATA_CONVERSION, MARSHAL, and BAD_OPERATION  p. 85 get_value_def throws BAD_PARAM  p. 122 _invoke(...) throws SystemException    

Resolution: see below
Revised Text: Remove the "throws" clause from the following places in the chapter, and from the corresponding places in the source code: Section 1.16 class Any abstract public void read_value( org.omg.CORBA.portable.InputStream is, org.omg.CORBA.TypeCode t) throws org.omg.CORBA.MARSHAL; abstract public short extract_short() throws org.omg.CORBA.BAD_OPERATION; abstract public int extract_long() throws org.omg.CORBA.BAD_OPERATION; abstract public long extract_longlong() throws org.omg.CORBA.BAD_OPERATION; abstract public short extract_ushort() throws org.omg.CORBA.BAD_OPERATION; abstract public int extract_ulong() throws org.omg.CORBA.BAD_OPERATION; abstract public long extract_ulonglong() throws org.omg.CORBA.BAD_OPERATION; abstract public float extract_float() throws org.omg.CORBA.BAD_OPERATION; abstract public double extract_double() throws org.omg.CORBA.BAD_OPERATION; abstract public boolean extract_boolean() throws org.omg.CORBA.BAD_OPERATION; abstract public char extract_char() throws org.omg.CORBA.BAD_OPERATION; abstract public void insert_char(char c) throws org.omg.CORBA.DATA_CONVERSION; abstract public char extract_wchar() throws org.omg.CORBA.BAD_OPERATION; abstract public byte extract_octet() throws org.omg.CORBA.BAD_OPERATION; abstract public org.omg.CORBA.Any extract_any() throws org.omg.CORBA.BAD_OPERATION; abstract public org.omg.CORBA.Object extract_Object() throws org.omg.CORBA.BAD_OPERATION; abstract public java.io.Serializable extract_Value() throws org.omg.CORBA.BAD_OPERATION; abstract public void insert_Value( java.io.Serializable v, org.omg.CORBA.TypeCode t) throws org.omg.CORBA.MARSHAL; abstract public void insert_Object( org.omg.CORBA.Object obj, org.omg.CORBA.TypeCode t).1 throws org.omg.CORBA.BAD_PARAM; abstract public String extract_string() throws org.omg.CORBA.BAD_OPERATION; abstract public void insert_string(String s) throws org.omg.CORBA.DATA_CONVERSION, org.omg.CORBA.MARSHAL; abstract public String extract_wstring() throws org.omg.CORBA.BAD_OPERATION; abstract public void insert_wstring(String s) throws org.omg.CORBA.MARSHAL; abstract public org.omg.CORBA.TypeCode extract_TypeCode() throws org.omg.CORBA.BAD_OPERATION; public org.omg.CORBA.Principal extract_Principal() throws org.omg.CORBA.BAD_OPERATION public org.omg.CORBA.portable.Streamable extract_Streamable() throws org.omg.CORBA.BAD_INV_ORDER public void insert_fixed( java.math.BigDecimal value, org.omg.CORBA.TypeCode type) throws org.omg.CORBA.BAD_INV_ORDER Section 19.10 package org.omg.CORBA_2_3; public abstract class ORB extends org.omg.CORBA.ORB { public org.omg.CORBA.Object get_value_def( String repid) throws org.omg.CORBA.BAD_PARAM Section 21.5.4 public interface InvokeHandler { OutputStream _invoke( String method, InputStream is, ResponseHandler handler) throws org.omg.CORBA.SystemException;
Actions taken:
September 8, 2000: received issue
February 27, 2001: closed issue

Discussion:


Issue 3819: Issues with Java mapping of Typecode (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Ken Cavanaugh, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
In the IDL to Java spec (ptc/00-01-08) there are several minor  editorial errors in the Java mapping for Typecode:    1. p. 74 the example has           class TypeCode extends IDLEntity       However, IDLEntity is an interface, so this must be implements,     not extends.      2. p. 75 the declaration          public abstract short member_visibility( long index )       should be           public abstract short member_visibility( int index )       since the IDL for member_visibility has a long argument,     and IDL long type maps to int in Java.    3. Throughout class Typecode on pp. 74-75, TypeCodePackage.BadKind     and TypeCodePackage.Bounds are illegal java.  The exception names     must either be fully qualified or unqualified with appropriate      import statements.    

Resolution: closed issue...editorial
Revised Text:
Actions taken:
September 8, 2000: received issue
April 17, 2001: closed issue

Issue 3903: mapping for Request.target will not compile (java-rtf)

Source: Oracle (Dr. Harold Carr, Ph.D.,
nobody)
Nature: Uncategorized Issue
Severity:
Summary:
This is a IDL to Java issue.    	ptc/00-01-08 specifies the mapping for Request.    	The mapping of target is specified on p 69 as:    		public abstract Object target();    	It should say:  		  		public abstract org.omg.CORBA.Object target();    	Otherwise it will not compile.  

Resolution: closed issue, editorial change
Revised Text:
Actions taken:
September 20, 2000: received issue
April 17, 2001: closed issue

Issue 3904: ptc/00-01-08: Conflict 1.15.1 paragraph 2 - 1.19.2 paragraph 2 (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Harold Carr, Ph.D., nobody)
Nature: Uncategorized Issue
Severity:
Summary:
This is a IDL to Java issue.    ptc/00-01-08    	1.15.1 paragraph 2 states that the "string reason parameter  	... is concatenated to the id before calling the base  	UserException constructor."    	However, 1.19.2 paragraph 2 states that "no holder and helper  	classes are define for these exceptions," (i.e., Bounds, BadKind,  	InvalidName) ... they are mapped as normal user exceptions."    	Since a helper class is not generated it is impossible to to  	concatenate an id before calling the base UserException constructor in  	these cases.    	Therefore they are not mapped as normal user exceptions.  They  	are mapped as normal user exceptions EXCEPT that the additional "full"  	constructor does not concatenate an id before calling the base  	UserException constructor.  	  	The text and non-normative examples should be updated to make   	this clear.  

Resolution: see below
Revised Text: Rewrite the second paragraph of Section 19.2, to say "No holder classes are defined for these exceptions, nor are they in the interface repository. However, so that users can treat them as "normal exceptions" for programming purposes, they are otherwise mapped as normal user exceptions, including the generation of helper classes."
Actions taken:
September 20, 2000: received issue
February 27, 2001: closed issue

Discussion:
The Source Zip Files actually have Helpers for the exceptions in Section 19.2, and these Helpers are used in the  Source for the exceptions themselves, to do the concatenation as described in Section 15.1.  Resolution:


Issue 3911: Incomplete union mapping (java-rtf)

Click
here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:
it appears that the Java mapping for unions is incomplete. For example:    	enum E { A, B, C };    	union U switch (E) {  	case A:  		long l;  	};    Something like this is actually used in the trader specification. For  a discriminator value of B or C, the union contains no member (but does  contain the discriminator value, of course). The problem arises because  the semantics of an operation can differ depending on the discriminator  value. For example:    	interface foo {  		SomeType op(in U param);  	};    op() can do different things (and indeed, *does* do different things in the  trader spec), depending on whether the discriminator value for the union  is B or C.    The problem is that the Java mapping does not offer a modifier for  the discriminator, thereby making it impossible to control the discriminator  value if more than one discriminator value is possible for the same union  member.  

Resolution: withdrawn by submitter
Revised Text:
Actions taken:
September 28, 2000: received issue
September 28, 2000: closed issue

Issue 3912: How is an ORB to determine whether or not it is in an applet context? (java-rtf)

Click
here for this issue's archive.
Source: Improv Technologies (Dr. Mary Leland, )
Nature: Uncategorized Issue
Severity:
Summary:
How is an ORB to determine whether or not it is in an applet context?  The nearest that I can see is to check for the presence of  a SecurityManager. If we are in an applet context, then there is a  SecurityManager present, but the inverse (that the presence of a  SecurityManager implies that we are in an applet) is not true.  It is however the case that whenever a SecurityManager is present,  potentially untrusted code is present, so the same constraints on the  singleton ORB are probably appropriate.  Therefore, I propose that the specification be changed to state  that if System.getSecurityManager() returns a non-null result,  the singeton ORB should be constrained to creating TypeCodes and Anys.  

Resolution: see below
Revised Text: Replace the second paragraph under "Default Initialization" in Section 21.9.3 (bottom of page 129 in ptc/2000-07-03) with the following 2 paragraphs. They preserve the useful information about the Applet case, but make it clear that the singleton ORB returned by the no-argument ORB.init is constrained in any context. Replacement Text: "The primary use of the no-argument version of ORB.init() is to provide a factory for TypeCodes for use by Helper classes implementing the type() method, and to create Any instances that are used to describe union labels as part of creating a union TypeCode. In the case of an ORB within a browswer, these Helper classes may be baked-in to the browser (e.g., for the interface repository stubs or other wildly popular IDL) and so may be shared across untrusted applets downloaded into the browser. The returned ORB instance is shared across all applets and therefore must have sharply restricted capabilities so that unrelated applets can be isolated from each other. It is not intended to be used directly by applets."
Actions taken:
September 28, 2000: received issue
February 27, 2001: closed issue

Discussion:
This is a re-submission of Issue 1751, which disappeared from  the database without ever being actually resolved.


Issue 3913: Vendor-specific ORB_init methods (java-rtf)

Click
here for this issue's archive.
Source: Improv Technologies (Dr. Mary Leland, )
Nature: Uncategorized Issue
Severity:
Summary:
The first two bullets in Section 1.1.1.1 of ptc/2000-07-03  refer to the fields DEFAULT_ORB and DEFAULT_ORB_SINGLETON in  omg/omg/CORBA/ORB.java.  However, these fields do not exist  in that file (nor are they in org/omg/CORBA_2_3/ORB.java).  The intention of these bullets is to permit vendors to  appropriately modify the implementations of the ORB_init  methods, but since these methods are not implemented using  those fields, the intention is not achieved.    Proposed resolution:     Add a point #3 to Section 1.1, along the lines of     "In certain rare cases, the actual body of a method     must be replaced by a vendor-specific implementation.     These cases are clearly identified in this specification     and by comments in the org.omg.* packages."       Change the first two bullets in Section 1.1.1.1 to     "Vendor-specific implementations for the ORB_init     methods of org.omg.CORBA.ORB must be supplied.     Since these methods are static, they cannot be     overridden by the vendor-specific ORB subclass,     but must be provided in the org.omg.CORBA.ORB class     itself."       Add a comment          /* VENDOR MUST SUPPLY IMPLEMENTATION */     to the ORB_init methods, and a line in the     header comments of the org/omg/CORBA/ORB.java     file saying that implementations of the ORB_init     methods are required.

Resolution:
Revised Text: Add a point #3 to Section 1.1, saying "In certain rare cases, the actual body of a method must be replaced by a vendor-specific implementation. These cases are clearly identified in this specification and by comments in the org.omg.* packages." Change the first two bullets in Section 1.1.1.1 to "Vendor-specific implementations for the init methods of org.omg.CORBA.ORB must be supplied. Since these methods are static, they cannot be overridden by the vendor-specific ORB subclass, but must be provided in the org.omg.CORBA.ORB class itself." Add a comment /* VENDOR MUST SUPPLY IMPLEMENTATION */ to the init methods, and a line in the header comments of the org/omg/CORBA/ORB.java file saying that implementations of the init methods are required.
Actions taken:
September 28, 2000: received issue
February 27, 2001: closed issue

Discussion:
Proposed resolution:       Add a point #3 to Section 1.1, along the lines of       "In certain rare cases, the actual body of a method       must be replaced by a vendor-specific implementation.       These cases are clearly identified in this specification       and by comments in the org.omg.* packages."           Change the first two bullets in Section 1.1.1.1 to       "Vendor-specific implementations for the init       methods of org.omg.CORBA.ORB must be supplied.       Since these methods are static, they cannot be       overridden by the vendor-specific ORB subclass,       but must be provided in the org.omg.CORBA.ORB class       itself."           Add a comment            /* VENDOR MUST SUPPLY IMPLEMENTATION */       to the init methods, and a line in the       header comments of the org/omg/CORBA/ORB.java       file saying that implementations of the init       methods are required.


Issue 3923: #pragma prefix issue (java-rtf)

Click
here for this issue's archive.
Source: SciTegic Inc. (Scott Markel, Ph.D., nobody)
Nature: Uncategorized Issue
Severity:
Summary:
Section 1.5.3 of the OMG's IDL Style Guide (ab/98-06-03) indicates that      #pragma prefix "omg.org"    should appear in any IDL file belonging to an OMG-approved  specification.  With the use of this prefix, the RepositoryID of a  valuetype V in module M would be      "IDL:omg.org/M/V:1.0"    Section 1.13.8 of the IDL to Java Language Mapping Specification  (formal/99-07-53) specifies the algorithm to be used in determining the  location of a valuetype and its corresponding default factory, where  location is in the Java package sense.  If an ORB vendor follows this  algorithm, the default value factory will be assumed to be in the Java  package given by      omg.org.M    Following the Java convention of reversing a domain name to obtain a  package hierarchy, one would expect to have implementation code in      org.omg.M    This mismatch requires users to register default value factories, which  seems to go against the spirit of the second paragraph of section 5.4.3  of the CORBA 2.3.1 Specification (formal/99-10-07) where the term  "implicit registration" is used.    Proposed resolution:      In the IDL to Java language mapping the omg.org prefix is reversed to    org.omg.    Comments?

Resolution: see below
Revised Text: Add a sub-bullet to the second bullet in Section 13.8: If this is not successful and the first two components of the Java class name are "omg.org", then reverse the order of these components to be "org.omg" and repeat the above step.
Actions taken:
September 28, 2000: received issue
February 27, 2001: closed issue

Discussion:
In the IDL to Java language mapping the omg.org prefix is reversed to      org.omg.        Comments?


Issue 3946: CompletionStatus needs to implement org.omg.CORBA.portable.IDLEntity (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Everett Anderson, )
Nature: Uncategorized Issue
Severity:
Summary:
IDL to Java specification  ptc-00-01-08  Section 1.15.2  Page 56    Problem:    CompletionStatus needs to implement org.omg.CORBA.portable.IDLEntity  since it's mapped as an enum.    IDLEntity extends java.io.Serializable, and that is crucial for  CompletionStatus since it's a member of SystemExceptions.  If it isn't  Serializable, then none of the exceptions are, either.    Solution:    OLD:  public final class CompletionStatus {    NEW:  public final class CompletionStatus       implements org.omg.CORBA.portable.IDLEntity {  

Resolution: closed issue...editorial change
Revised Text:
Actions taken:
October 10, 2000: received issue
April 17, 2001: closed issue

Issue 3979: IDL to Java Spec Issue : need to add SystemExceptions introduced in CORBA 2 (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Ram Jeyaraman, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
The mapping from IDL names to Java Class names provided in Page 1-55 Table 1-2 should include the  following exceptions (introduced in CORBA 2.4) as well.    TRANSACTION_MODE  TRANSACTION_UNAVAILABLE  

Resolution: see below
Revised Text: Add the following at the end of Table 1.2 in Section 15.2 CORBA::TRANSACTION_MODE org.omg.CORBA.Transaction_Mode CORBA::TRANSACTION_UNAVAILABLE org.omg.CORBA.Transaction_Unavailable Add Source Code files for org.omg.CORBA.Transaction_Mode and org.omg.CORBA.Transaction_Unavailable, modeling them on the existing source code files for other System Exceptions.
Actions taken:
October 23, 2000: received issue
February 27, 2001: closed issue

Discussion:


Issue 3994: Valuetype unmarshalling (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
The rules for valuetype unmarshalling in section 1.13.8 of the IDL to  Java mapping spec need to be expanded.  There are two issues with the  algorithm currently described:     1. The algorithm described is based purely on the repository ID,       which may either be read off the wire or passed as an argument on      the read_value() call.  However, if the expected type is passed      as an argument on the read_value() call, then this should be taken      into account in the unmarshalling algorithm.   2. In some cases, the unmarshaller does not have enough information      to distinguish between a boxed valuetype (which is unmarshalled      using a helper object) and a regular valuetype (which is unmarshalled      using a value factory).  An additional step in the unmarshalling      algorithm is needed to cover these cases.    Proposed resolution:    In section 1.13.8, add a new bullet before the existing second bullet  as follows:  � If this is not successful and an expected type clz was passed on the  read_value call, and if clz implements IDLEntity but not ValueBase, then  unmarshal the valuetype as a boxed IDL type by calling the read method  of <clz>Helper.    In section 1.13.8, add a new bullet before the existing third bullet  as follows:  � If this is not successful and the RepositoryId is a standard repository id that starts  with �IDL:�, then attempt to generate the boxed value helper class name to use by  stripping off the �IDL:� header and �:<major>.<minor>� version information  trailer, and replacing the �/�s that separate the module names with �.�s and  appending �Helper.�    In section 1.13.8, add a new bullet before the existing fourth bullet  as follows:  � If this is not successful and an expected type clz was passed on the  read_value call, and if clz does not implement IDLEntity, then use the  ValueHandler interface to read in the value (see the Java to IDL Language  Mapping document, Section 1.5.1.3, �ValueHandler,� on page 1-40).  

Resolution: Incorporate the revised text and close the issue
Revised Text: In section 1.13.8, add a new bullet before the existing second bullet as follows: If this is not successful and an expected type clz was passed on the read_value call, and if clz implements IDLEntity but not ValueBase, then unmarshal the valuetype as a boxed IDL type by calling the read method of Helper. In section 1.13.8, add a new bullet before the existing third bullet as follows: If this is not successful and the RepositoryId is a standard repository id that starts with �IDL:�, then attempt to generate the boxed value helper class name to use by stripping off the �IDL:� header and �:<major>.<minor>� version information trailer, and replacing the �/�s that separate the module names with �.�s and appending �Helper.� Add a sub-bullet under the previous new bullet as follows: If this is not successful and the first two components of the Java class name are "omg.org", then reverse the order of these two components to be "org.omg" and repeat the above step. In section 1.13.8, add a new bullet before the existing fourth bullet as follows: If this is not successful and an expected type clz was passed on the read_value call, and if clz does not implement IDLEntity, then use the ValueHandler interface to read in the value (see the Java to IDL Language Mapping document, Section 1.5.1.3, �ValueHandler,� on page 1-40).
Actions taken:
October 25, 2000: received issue
May 13, 2002: closed issue

Discussion:


Issue 3995: Copying boxed valuetypes on local calls (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
n section 1.12.2 of the IDL to Java mapping spec, the second bullet  should be clarified to state that the copying it describes applies  only to non-boxed valuetypes and not to boxed valuetypes.    Valuetypes need to be copied (unlike structs, which aren't copied)  because the methods of a valuetype can modify its state and it is  not reasonable to require the callee to know whether or not calling  a valuetype method has resulted in a change to the valuetype's state.    This does not apply to boxed valuetypes, which cannot have methods.  Therefore, with respect to this copying, they should be treated like  IDL constructed types, which are not copied.    Proposed resolution:    In section 1.12.2, second bullet, change "For IDL in parameters that  are valuetypes" to "For IDL in parameters that are non-boxed valuetypes:"    In section 1.12.2, second bullet, change "With the exception of value  types" to "With the exception of non-boxed value types".    In section 1.12.2, add new third bullet:  � For IDL in paramet