Issues for IDL/Java Revision Task Force mailing list

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
Issue 799: Problems with IDL unions mapped to Java
Issue 888: Section 5.14 and 6.11 IDL/Java Language mapping
Issue 890: Add missing UnknownUserException
Issue 891: ImplementationDef should be an abstarct class
Issue 892: create_list semantics not well defined
Issue 893: delegate field in ObjectImpl should be transient
Issue 894: input/output streams should extend java.io.streams
Issue 895: _orb() is missing from ObjectImpl
Issue 896: Make all basic Holders implement Streamable
Issue 897: Fix any"s to have implement copy semantics
Issue 898: Clarify the use of return_value() before invoke() in DII
Issue 899: Clarify exact list of methods available on singleton orb
Issue 907: Current mapped incorrectly in Java language mapping
Issue 908: CORBA::DATA::CONVERSION exception for IDL types wchar/wstring
Issue 909: IDL/Java language mapping, section 5.14, 6.11
Issue 919: Problem with IDL --> Java mapping for Unions ServantBase mappings
Issue 1090: Reserved names
Issue 1142: POA_Interface bug
Issue 1143: Chapter 9.8.1 Local stubs-bug
Issue 1167: Any.insert_Object()
Issue 1242: Any"s and Exceptions
Issue 1381: No INV_NO_RESPONSE possible in Java DII
Issue 1385: Discriminated Union value issue
Issue 1536: Helper classes are only for user defined IDL types
Issue 1577: Section 7.1.3 of Java to IDL mapping
Issue 1583: org.omg.CORBA.UserException class not specified
Issue 1586: Callback issue
Issue 1672: Does object reference == ObjectImpl?
Issue 1696: Proposed change to orb.init
Issue 1701: Mapping of IDL constants to Java
Issue 1703: orb.properties file issue
Issue 1704: Proposed change sto IDL/Java mapping
Issue 1705: Add Any.extract_Streamable()
Issue 1722: New stream based stubs and location forward
Issue 1724: OutputStream semantics question
Issue 1730: Changes to Java fixed type mapping
Issue 1731: Java mapping"s use of _this()
Issue 1732: Changes to Java interface mapping
Issue 1734: Mapping of IDL names that clash with java.lang.Object methods
Issue 1737: Compiler-readable code
Issue 1738: Object._request variants are unspecified
Issue 1739: Local stubs
Issue 1741: Java RTF issue
Issue 1746: Conext support in Java
Issue 1750: 2 IDL->Java issues on the singleton ORB (02) mapping of IDL enumerations to java
Issue 1752: mapping of IDL enumerations to java
Issue 1754: Proposal to change get_value_def in Java mapping
Issue 1795: final methods on ObjectImpl
Issue 1897: Evolving the org.omg.* APIs
Issue 1941: Problem mapping "global" types in Java mapping
Issue 1942: Need overloaded write_Value method on OutputStream
Issue 1961: Java Mapping for interfaces -- Proposal
Issue 1964: Creating TypeCodes safely in java
Issue 1980: Updated proposal for the OBV Java mapping
Issue 1993: create_lname & create_lname_context Local stubs proposal
Issue 1994: Local stubs proposal
Issue 2079: Potential problem with Java Mapping ORB init for Applet
Issue 2096: Issue with Mapping for Constants within an interface
Issue 2228: typedefs in IDl when generating Java code
Issue 2233: Helper "narrow" exception clarification
Issue 2251: Java LocalStub
Issue 2255: Proposal for persistent valuetypes
Issue 2256: PSS requiremnets for the ObV/Java mapping
Issue 2462: BAD_PARAM issue
Issue 2514: PortableServer Servant issue
Issue 2517: orb.properties search should include home directory
Issue 2518: Incorrect search order for ORB implementation class name
Issue 2519: Need SerializableHolder class
Issue 2520: Standard properties should include initial host and port
Issue 2528: Mapping Messaging sendc_ (and sendp_) methods to Java
Issue 2531: Serializable objects in Anys need reference semantics
Issue 2532: Mapping of AbstractBase and abstract interfaces
Issue 2540: _servant_postinvoke
Issue 2550: Dealing with reserved suffixes (e.g. POA)
Issue 2608: Java - Mapping for Struct issue
Issue 2609: Issues with ObjectImpl implementations
Issue 2647: Modification of Constant Mapping
Issue 2661: Valuetype packages
Issue 2721: DII and SystemException semantics
Issue 2770: Java substitutability issue: value instance -> interface type
Issue 2823: Java mapping for PolicyType...
Issue 2889: Should Any.extract_string work for bounded strings?
Issue 2979: Java SystemException should contain nested exception field
Issue 3068: Messaging sendc and sendp missing from portability interfaces
Issue 3204: ORB Init problems
Issue 3209: Illegal return statement
Issue 3267: How to create marshalel data of java.lang.Throwable instance?
Issue 3320: Java language mapping: Tie classes for local interfaces.
Issue 3323: Need clarification on custructor(s) for stream-based stubs/skeletons
Issue 3410: IDL/Java: methods marked final in PortableServer.Servant
Issue 3570: org.omg.CORBA.portable.UnknownException does not have all constructors
Issue 3575: Custom marshal does not work for certain valuetypes
Issue 3633: Request clarification for use of alias typecodes in typedef helper classes
Issue 3643: Description of ORB.init parameters insufficient
Issue 3654: OMG ZIP FILE ISSUES for IDL to Java RTF (01)
Issue 3655: OMG ZIP FILE ISSUES for IDL to Java RTF (02)
Issue 3656: OMG ZIP FILE ISSUES for IDL to Java RTF (03)
Issue 3657: OMG ZIP FILE ISSUES for IDL to Java RTF (04)
Issue 3658: OMG ZIP FILE ISSUES for IDL to Java RTF (05)
Issue 3659: OMG ZIP FILE ISSUES for IDL to Java RTF (06)
Issue 3665: Java ORB Id
Issue 3668: Possible problem with IDL to Java mapping of fixed-point decimal types
Issue 3669: Enum mapping issue
Issue 3686: How can org.omg.CORBA.portable.InputStream.read_fixed possibly work?
Issue 3707: Need clarification on custructor(s) for stream-based
Issue 3750: SystemExceptionHelper missing
Issue 3794: IDLEntity interface has to be public.
Issue 3795: Incorrect method declaration in CORBA_2_3/portable/InputStream.java and Out
Issue 3801: policy_type should map to a Java int.
Issue 3818: Operations signatures include throws clauses on system exceptions.
Issue 3819: Issues with Java mapping of Typecode
Issue 3903: mapping for Request.target will not compile
Issue 3904: ptc/00-01-08: Conflict 1.15.1 paragraph 2 - 1.19.2 paragraph 2
Issue 3911: Incomplete union mapping
Issue 3912: How is an ORB to determine whether or not it is in an applet context?
Issue 3913: Vendor-specific ORB_init methods
Issue 3923: #pragma prefix issue
Issue 3946: CompletionStatus needs to implement org.omg.CORBA.portable.IDLEntity
Issue 3979: IDL to Java Spec Issue : need to add SystemExceptions introduced in CORBA 2
Issue 3994: Valuetype unmarshalling
Issue 3995: Copying boxed valuetypes on local calls
Issue 4009: Union exceptions
Issue 4010: Should valuetype helper insert/extract make copies?
Issue 4013: Usage of ExceptionDetailMessage service context
Issue 4057: Displaying SystemExceptions
Issue 4059: When to honor the servant delegate in POA?
Issue 4064: Any extract operations for tk_abstract_interface
Issue 4076: System Exceptions REBIND, TIMEOUT, BAD_QOS
Issue 4158: publication of messaging / unchecked_narrow
Issue 4271: IDL/Java issue, Mapping for IDL enum
Issue 4286: Clarification of serialization of Anys and Typecodes
Issue 4323: local interface mapping underspecified
Issue 4549: Missing elements of the local mapping
Issue 4624: support for local objects
Issue 4699: is_a support in Java for local interfaces
Issue 4701: Colocated calls in Java
Issue 4710: Mapping for Character and String Types
Issue 4741: New issue on register_initial_reference
Issue 4748: Naming issues for new ORB methods
Issue 4749: New issue: Error in resolution of issue 4699
Issue 4750: Make CORBA_2_3.ORB methods available in CORBA.ORB
Issue 4792: exceptions on valuetype initializers
Issue 4793: attribute exceptions
Issue 4794: OMG Java Language Mapping and the use of Java null
Issue 4802: Should a holder class for ProtectingEntity get generated
Issue 4804: section 1.18.2 of the OMG IDL mapping document ptc/00-01-08
Issue 4805: Java mapping changes for core issue 4337
Issue 5108: J2EE ORB Socket Factory API
Issue 5465: Default UnknownException behavior
Issue 5468: Anys obtained using the singleton ORB
Issue 5586: interfaces that do not extend org.omg.CORBA.portable.ValueBase
Issue 5595: Should javadoc statement be removed or should method be removed?
Issue 5615: Streaming Interfaces
Issue 5638: Typo on getRaises and setRaises in formal/2002-08-05
Issue 5646: Java source code for org.omg.PortableServer.POAOperations
Issue 5693: POA changes missing in Java source archive
Issue 5694: What is the IDL for ServiceInformation and/or what is correct Java mapping?
Issue 5696: Package name issue
Issue 5728: How does a Java ORB implement a write_fixed/read_fixed?
Issue 5782: Missing operations on org.omg.CORBA.Object
Issue 5783: Stub handling of UnknownException
Issue 5806: response_expected value for colocated invocations
Issue 5893: definition of FixedHolder should have been removed
Issue 7846: wrong enumeration value for SetOverrideType
Issue 9795: section 1.21.3 IDLEntity

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

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

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.
 
 

Summary: In the class definition for Any there is only 
 insert_Streamable(...), but no 
 extract_Streamable(...).  How do you extract 
 streamables?
 

Summary: 

Summary: 

Summary: create_list semantics are not well-defined in CORE and hence Java
        Language Mapping
 

 received issue

Summary: 

Summary: 

Summary: 

Summary: 

Summary: Issue: Fix any"s to have implement copy semantics, similar to C++
 

 closed issue

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. 
 

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
 

 closed issue

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.
 

Summary: In the class definition for Any there is only 
 insert_Streamable(...), but no 
 extract_Streamable(...).  How do you extract 
 streamables?
 

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. 
 

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
 

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.
 
 

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) 
 

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.
 

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() ?.
 

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).
 

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.
 
 

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.
 

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.
 

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);
   }
 }
 
 

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?
 

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.
 
 
 
 
 
 
 
 

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.
 

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.
 

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".

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. 
 

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. 
 
 
 

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.
 

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.
 

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.
 
 

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 is to fix the behavior of servant_to_reference by revising text as shown below

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.
 
 
 
 

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.
 
 

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.
 

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
 
 
 

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.
 

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?
 

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.
 
 

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.
 
 

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.
 

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

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.
 
 

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.
 

Summary: The current IDL/Java mapping cannot correctly map IDL "global" types
 correctly in all cases.

 closed issue

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.
 

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.
 

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.
 

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.