Document Number ptc/2003-01-01


Final RTF Report of the
December 2003 Java Language Mapping
Revision Task Force
to the
Platform Technical Committee
of the
Object Management Group
January 6, 2003

Document Numbers:

Contents

Summary of Java RTF Activities

Java RTF Formation

Java RTF Membership and Voting Record

The following 2 tables give the detailed results of each of the two votes in this report. The results of the interim report are not included here (see ptc/02-06-12.html). The symbols used are as follows:

Results of Vote 4
Member Organization Status 4710 4945 5465 5468 5586 5595 5638 5693 5694
Andy Piper BEA charter Y Y Y Y Y Y Y Y Y
Cuie Zhao Borland charter Y Y A Y Y Y Y Y Y
Mitchel Sanders 2AB charter Y Y Y Y Y Y Y Y Y
Yoshitaka Honishi Fujitsu charter Y Y Y Y Y Y Y Y Y
Jishnu Mukerji HP charter Y Y Y Y Y Y Y Y Y
Ann Dalton IBM charter Y Y N Y Y Y Y Y Y
Eoghan Glynn Iona charter Y Y Y Y Y Y Y Y Y
Victor Giddings OIS added after interim report Y Y Y Y Y Y Y Y Y
Jeff Mischkinsky Oracle charter A A A A A A A A A
Ken Cavanaugh (chair) Sun Microsystems charter Y Y Y Y Y Y Y Y Y

Results of Vote 5
Member Organization Status 2889 3633 3995 4010 5696 5728 5782 5783
Andy Piper BEA charter Y Y Y Y Y Y Y Y
Cuie Zhao Borland charter A A A A A A A A
Mitchel Sanders 2AB charter Y Y Y Y Y Y Y Y
Yoshitaka Honishi Fujitsu charter Y Y Y Y Y Y Y Y
Jishnu Mukerji HP charter Y Y Y Y Y Y Y Y
Ann Dalton IBM charter Y Y Y N Y Y Y Y
Eoghan Glynn Iona charter Y Y Y Y Y Y Y Y
Victor Giddings OIS added after interim report NV NV NV NV NV NV NV NV
Jeff Mischkinsky Oracle charter A A A A A A A A
Ken Cavanaugh (chair) Sun Microsystems charter Y Y Y Y Y Y Y Y

Disposition of Issues

Disposition Number of Occurrences Meaning of Disposition
Unresolved 2 TF has not resolved issue yet
Transferred 1 Transferred to another TF
Accepted (Changed and Closed) 10 Change made as requested
Rejected (Close, No Change) 6 RTF / FTF agreed NOT to do what was requested, or anything like it
Duplicate 0 Duplicate of another issue

Unresolved

Issue 3068 (archive): Messaging sendc and sendp missing from portability interfaces
Issue 5108 (archive): J2EE ORB Socket Factory API

Transferred

Issue 4945: IOR processing performance

Accepted

Issue 4010: Should valuetype helper insert/extract make copies?
Issue 4710: Mapping for character and string types
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 5638: Typo on getRaises and setRaises
Issue 5693: POA changes missing in Java source archive
Issue 5694: What is the IDL for ServiceInformation and/or what is the correct Java mapping?
Issue 5782: Missing methods on org.omg.CORBA.Object
Issue 5783: Stub handling of UnknownException

Rejected

Issue 2889: Should Any.extract_string work for bounded strings?
Issue 3633: Request clarification for use of alias typecodes in typedef helper classes
Issue 3995: Copying boxed valuetypes on local calls
Issue 5595:Should javadoc statement be removed or should method be removed?
Issue 5696: Name mangling for module names that are not valid Java identifiers
Issue 5728: Missing methods for fixed

Duplicate

Profile of Changes Made in Response to Issues

In the specification:

In the source archive:

Detailed Resolutions

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

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

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 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 typedef 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

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 3995: Copying boxed valuetypes on local calls (java-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Simon C. Nash, nash@hursley.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:Close no change.
Revised Text:
Actions taken:
October 25, 2000: received issue
Discussion:
As was noted in the discussion 2 years ago on this issue, the situation is not quite as simple as the issue originally supposed. For IDL, copying comes done to the following simple idea:

In addition, all aliasing must be preserved, both within a single value, and between different arguments to the same invocation. In situations where a boxed value type can indirectly reference a value that is passed in the same call in a different argument, the boxed value type must be copied so that it refers to the same copy of the value that is used elsewhere in the call.

However, I am not sure that this is the only problem here. Simon makes reference to the idea that any type that refers to a non-boxed valuetype must be copied when passed as an in parameter, so for example a struct S containing a reference to a valuetype V must also be copied. But this directly directly contradicts the first bullet in section 1.12.2, which implies that non-valuetypes (like S) are not copied. Clearly if an instance s1 of S that refers to an instance v1 of V is created, and s1 and v1 are both passed in the same call, we would expect that sharing would be preserved. But that would require copying s1.

Given this problem, which is independent of whether we are considering boxed valuetypes or not, and the fact that no one has worked on this issue for over 2 years, I would like to close this issue in the current RTF. I would rather see an issue created to deal with defects in the copying of parameters than just address the narrow boxed valuetype question.

Issue 4010: Should valuetype helper insert/extract make copies? (java-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Simon C. Nash, nash@hursley.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

The adopted resolution for issue 2531 has clarified that the Any.insert_Value and Any.extract_Value methods don't make copies of the Serializable parameter passed to insert_Value. Should the same be true for the valuetype helper's insert and extract methods? The IDL to Java mapping spec does not say anything about the copying semantics of helper insert and extract methods.

Resolution: Incorporate change and close issue.
Revised Text:
Add the following sentence at the end of the first paragraph of section 1.5.2:

"The Any insert and extract operations for Valuetype helper classes do not copy their arguments: they implement reference semantics just like Any.insert_Value and Any.extract_Value."
Actions taken:
November 1, 2000: received issue

Issue 4710: Mapping for Character and String Types (java-rtf)

Click here for this issue's archive.
Source: International Business Machines (Ms. Anne E. Dalton, ann_dalton@uk.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

Sections 1.4.3 and 1.4.5 of the IDL to Java spec state that character and string range and bounds checking should be performed at marshal time. Since it is possible to receive IDL characters, e.g UTF16 surrogate pairs, that cannot, at present, be mapped to Java characters, could we clarify that this checking should be performed at both marshaling and demarshaling time, per section 4.11.3.25 DATA_CONVERSION of the CORBA 2.5 spec which states:-

This exception is raised if an ORB cannot convert the representation of data as marshaled into its native representation or vice-versa.

Also, could anyone please comment on the meaning of the term "character set" in the sentence beginning "If the char falls outside the range defined by the character set,..." in section 1.4.3. Does this refer to the TCS, NCS or both?

Resolution: Incorporate changes and close issue.
Revised Text:

replace old 1.4.3:

IDL characters are 8-bit quantities representing elements of a character set while Java characters are 16-bit unsigned quantities representing Unicode characters. In order to enforce type-safety, the Java CORBA runtime asserts range validity of all Java chars mapped from IDL chars when parameters are marshaled during method invocation. If the char falls outside the range defined by the character set, a CORBA::DATA_CONVERSION exception shall be thrown.

The IDL wchar maps to the Java primitive type char. If the wchar falls outside the range defined by the character set, a CORBA::DATA_CONVERSION exception shall be thrown.

with new 1.4.3:

IDL characters are 8-bit quantities representing elements of a character set while Java characters are 16-bit unsigned quantities representing Unicode characters. In order to enforce type safety, the Java CORBA runtime asserts range validity of all Java chars mapped to or from IDL chars when parameters are marshaled or unmarshaled during method invocation.

Assume that a Java ORB has a particular native character set (NCS) and some transmission character set (TCS) has been negotiated for a particular object reference. The following rules apply for reporting errors in character encoding during data marshalling and unmarshalling in a method invocation on that object reference:

  1. If an attempt is made to marshal a char represented in the sending ORB's NCS which cannot be represented in the sending ORB's TCS, a CORBA::DATA_CONVERSION exception with a minor code of 1 is thrown.
  2. If an attempt is made to unmarshal a char represent in the receiving ORB's TCS that cannot be represented in the receiving ORB's NCS, a CORBA::DATA_CONVERSION exception with a minor code of TBD is thrown.

Similarly, the following rules apply for reporting errors in wchar encoding during data marshalling and unmarshalling in a method invocation on that object reference:

  1. If an attempt is made to marshal a wchar represented in the sending ORB's NCS which cannot be represented in the sending ORB's TCS, a CORBA::DATA_CONVERSION exception with a minor code of 1 is thrown.
  2. If an attempt is made to unmarshal a wchar represent in the receiving ORB's TCS that cannot be represented in the receiving ORB's NCS, a CORBA::DATA_CONVERSION exception with a minor code of TBD is thrown.

Replace section 1.4.5:

The IDL string, both bounded and unbounded variants, are mapped to java.lang.String. Range checking for characters in the string as well as bounds checking of the string is done at marshal time. Character range violations cause a CORBA::DATA_CONVERSION exception to be raised. Bounds violations cause a CORBA::BAD_PARAM exception to be raised. The IDL wstring, both bounded and unbounded variants, are mapped to java.lang.String. Bounds checking of the string is done at marshal time. Character range violations cause a CORBA::DATA_CONVERSION exception to be raised. Bounds violations cause a CORBA:: BAD_PARAM exception to be raised.

with the new section 1.4.5:

The IDL string type, in both the bounded and unbounded variants, is mapped to java type java.lang.String. Range checking for characters in the string as well as bounds checking of the string is done at marshal time. Character range violations cause a CORBA::DATA_CONVERSION exception to be raised as described in section 1.4.3, "Character Types". Bounds violations cause a CORBA::BAD_PARAM exception to be raised. The IDL wstring type, in both the bounded and unbounded variants, is mapped to java type java.lang.String. Bounds checking of the string is done at marshal time. Character range violations cause a CORBA::DATA_CONVERSION exception to be raised as described in section 1.4.3, "Character Types". Bounds violations cause a CORBA:: BAD_PARAM exception to be raised.


Actions taken:Incorporated revised text and closed issue.
November 21, 2001: received issue

Issue 4945: IOR processing performance (java-rtf)

Click here for this issue's archive.
Source: International Business Machines (Ms. Anne E. Dalton, ann_dalton@uk.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

The overhead of processing TaggedComponents within an IOR becomes significant when done many times, as in the case of J2EE implementations where multiple request interceptors are used. IOR access and creation performance could be improved by making better use of Java facilities to provide access to an IOR's components without the overhead of CDR encoding, and by recognising that many of the constituent parts of an IOR are identical for all objects within an object adapter.

I would like to propose that we introduce a Java API for IOR, along the following lines:-

An abstract model of an IOR could be defined as follows:

It should be possible to manipulate IOR TaggedProfiles and IIOPProfileTemplate TaggedComponents using all of the facilities in the Java collections framework.

Templates can be used to create IIOPProfile and ObjectKey because the basic object adapter model for object creation is to establish all properties of an IOR (except for type and object ID) when the object adapter is created. This has been present for the POA essentially from the beginning, since policies can only be passed to create_POA, and cannot be changed on an existing POA. The Portable Interceptors work has also made this clear, since the IOR interceptor runs only when an object adapter is created, which is the only time that user code can add tagged components to an IOR.

TaggedComponent is a framework that may be extended to support application defined TaggedComponents. It would be necessary to be able to register TaggedComponentFactory instances with an ORB, in which case any IOR unmarshalled by that ORB instance would use the registered TaggedComponentFactory to unmarshal the TaggedComponent.

In order to use the IOR API, a method would be needed, probably on ORB, to obtain an abstract IOR from an object reference.

Resolution:
A long discussion in the RTF concluded that this issue was language indepedent, and so belonged in the core RTF (see core issue 5439). Revised Text:
Actions taken:
March 6, 2002: received issue
Issue transferred to core RTF by the Java RTF

Issue 5465: Default UnknownException behavior (java-rtf)

Click here for this issue's archive.
Source: BEA Systems (Dr. Andrew Piper, andyp@bea.com)
Nature: Uncategorized Issue
Severity:
Summary:

On page 133, bullet 3 reads:

It is unfortunate that there is no recommended default since for RMI-IIOP at least, the second option is by far to be preferred.

I would like to change it therefore to add the text:

"In order to preserve RMI semantics ORBs implementing the RMI-IIOP protocol should always translate it to the nested exception that the UnknownException contains"

Resolution:Incorporate revised text and close issue.
Revised Text:

Add the following paragraph after the third bullet mentioned above in the summary:

In order to preserve RMI semantics ORBs implementing the RMI-IIOP protocol must always translate the UnknownException to the nested exception given by UnknownException.originalEx.
Actions taken:
July 12, 2002: received issue

Issue 5468: Anys obtained using the singleton ORB (java-rtf)

Click here for this issue's archive.
Source: International Business Machines (Ms. Anne E. Dalton, ann_dalton@uk.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

The IDL to Java spec is very clear about what methods can (and by implication what methods can't) be used with the singleton ORB and one of those is create_any(), however it does not mention any restrictions on the use of Anys obtained in this way. I think this leads to some inconsistencies and potential problems, for example:

  1. You cannot use create_output_stream() on the singleton ORB but you can use create_output_stream() on an Any obtained from the singleton. Where has this OutputStream come from? Presumably from the Any's singleton ORB (calling the orb() method on that OutputStream would return the ORB). At best this seems inconsistent.
  2. The problem is worse if you now marshal an object reference into that OutputStream then call create_input_stream() and try to read back the object reference using a read_Object() call. If the read_Object() is to return an object reference it needs to have an ORB to associate it with, but the only ORB available to it is the original Any's singleton ORB, which cannot support object references. Should this read_Object() succeed or fail? If it should succeed what ORB should it be using?

There may be similar problems writing and reading other types to these streams.

I feel the spec should state explicitly that operations on an Any created using the singleton ORB will be limited by the restrictions applicable to the singleton ORB.

I don't think this would affect the intended use of Anys from the singleton, which is stated as being to describe union labels when creating a union TypeCode.

Resolution: Incorporate text and close issue.

Revised Text:

Add the following sentence to the end of the subsection "Default initialization" in section 1.21.9.3 ORB Initialization Methods in the IDL to Java spec:

Operations on an Any created using the singleton ORB will be limited by the restrictions applicable to the singleton ORB; those which require the use of a fully functional ORB will result in a NO_IMPLEMENT system exception.
Actions taken:
July 9, 2002: received issue

Issue 5586: interfaces that do not extend org.omg.CORBA.portable.ValueBase (java-rtf)

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

The two files org/omg/CORBA/DataInputStream.java and org/omg/CORBA/DataOutputStream.java contain interfaces that do not extend org.omg.CORBA.portable.ValueBase.

The CORBA IDL shows: 

abstract valuetype DataInputStream { ... 
abstract valuetype DataOutputStream { ...

and the IDL to Java mapping spec states that abstract value types map to a Java interface that extends ValueBase. Which is correct?

Resolution: Incorporate changes and close issue.
Revised Text:
Modify the two interfaces org.omg.CORBA.DataInputStream and org.omg.CORBA.DataOutputStream so that the extend org.omg.CORBA.portable.ValueBase in the zip archive.
Actions taken:
August 20, 2002: received issue

Issue 5595: Should javadoc statement be removed or should method be removed? (java-rtf)

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

The org/omg/CORBA/Object.java file includes:

/**
*@deprecated Deprecated by CORBA 2.3
*/
org.omg.CORBA.InterfaceDef _get_interface();

Which causes the the application code: 

 
public abstract class x extends org.omg.CORBA.LocalObject implements xl {}
public interface xl extends org.omg.CORBA.LocalInterface, org.omg.CORBA.portable.IDLEntity {}

to compile with a warning:

x.java:1: warning: _get_interface() in org.omg.CORBA.Object has been deprecated

I'm wondering whether the javadoc statement should be removed or whether the method should be removed?

Resolution: Close issue.
Actions taken:
August 26, 2002: received issue

Issue 5638: Typo on getRaises and setRaises in formal/2002-08-05 (java-rtf)

Click here for this issue's archive.
Source: Laboratoire d`Informatique Fondamentale de Lille (Dr. Philippe Merle, merle@lifl.fr)
Nature: Uncategorized Issue
Severity:
Summary:

In the IDL to Java Language Mapping Specification Version 1.2 (formal/2002-08-05), at pages 1-29 and 1-40, all occurrences of getRaises and setRaises must be replaced respectively by getraises and setraises according to the Chapter 3 of the CORBA Specification Version 3.0 (formal/02-06-01).

getRaises and setRaises were replaced by getraises and setraises during the CORBA Components December 2000 FTF (see final report ptc/01-11-02).

Resolution: Incorporate changes and close issue.
Revised Text:
Replace all occurrences of "getRaises" and "setRaises" with "getraises" and "setraises", respectively.
Actions taken:
August 29, 2002: received issue

Issue 5693: POA changes missing in Java source archive (java-rtf)

Click here for this issue's archive.
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings@ois.com)
Nature: Uncategorized Issue
Severity:
Summary:

The following CORBA 2.4 additions to the PortableServer module are missing from the latest Java source archive (http://cgi.omg.org/cgi-bin/doc?ptc/02-06-14):

I believe all changes should be binary compatible with the existing distribution. Therefore, no PortableServer_2_4 package should be necessary. It should be sufficient to apply these patches to the next distribution: 

diff -r1.1 CurrentOperations.java
7a8,9
> import org.omg.CORBA.Object;
>
13a16,20
>
>     public Object get_reference() throws org.omg.PortableServer.CurrentPackage.NoContext;
>
>     public Servant get_servant() throws org.omg.PortableServer.CurrentPackage.NoContext;
>


diff -r1.1 ThreadPolicyValue.java
33a34,37
>     public static final int _MAIN_THREAD_MODEL = 2;
>     public static final ThreadPolicyValue MAIN_THREAD_MODEL =
>         new ThreadPolicyValue(_MAIN_THREAD_MODEL);
>
44a49,50
>     case _MAIN_THREAD_MODEL:
>         return MAIN_THREAD_MODEL;

Resolution: Incorporate changes and close issue.
Revised Text:
Add the following methods to org.omg.PortableServer.CurrentOperations: 

public org.omg.CORBAObject get_reference()
        throws org.omg.PortableServer.CurrentPackage.NoContext;

     public Servant get_servant()
        throws org.omg.PortableServer.CurrentPackage.NoContext;

Add the following static data members to org.omg.PortableServer.ThreadPolicyValue: 

     public static final int _MAIN_THREAD_MODEL = 2;
     public static final ThreadPolicyValue MAIN_THREAD_MODEL =
         new ThreadPolicyValue(_MAIN_THREAD_MODEL);

Add the following to the org.omg.PortableServer.ThreadPolicyValue.from_int(int) method, just before the default label in the switch statement: 

case _MAIN_THREAD_MODEL:
         return MAIN_THREAD_MODEL;

Actions taken:
October 21, 2002: received issue

Issue 5694: What is the IDL for ServiceInformation and/or what is correct Java mapping? (java-rtf)

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

Are both of these correct? [It seems like the Java maps "sequence<int> service_details" instead of "sequence<ServiceDetail> service_details"]

from formal/02-06-33 "CORBA 3.0 full specification ":

typedef unsigned long ServiceOption; 
typedef unsigned long ServiceDetailType; 
struct ServiceDetail { 
  ServiceDetailType service_detail_type; 
  sequence  service_detail; 
}; 
struct ServiceInformation { 
  sequence  service_options; 
  sequence  service_details; 
};

from ptc/02-09-09 "Revision of the interim Java RTF Java .zip archive":

package org.omg.CORBA; 

public final class ServiceInformation implements 
      org.omg.CORBA.portable.IDLEntity { 

    public int[] service_options; 
    public int[] service_details; 

    public ServiceInformation() { 
    } 

    public ServiceInformation (int[] service_options, int[] service_details) { 
        this.service_options = service_options; 
        this.service_details = service_details; 
    } 

}

Resolution: Incorporate changes and close issue.
Revised Text:
In class org.omg.CORBA.ServiceInformation in the zip file, change 

    public int[] server_details

to

    public org.omg.CORBA.ServiceDetail[] service_details

Also, change

    public ServiceInformation (int[] service_options, int[] service_details) {

to

    public ServiceInformation (org.omg.CORBA.ServiceDetail[] service_options, 
        int[] service_details) {

Actions taken:
October 21, 2002: received issue


Issue 5696: Package name issue (java-rtf)

Click here for this issue's archive.
Source: IONA (Mr. Michi Henning, michi@triodia.com michi.henning@iona.com)
Nature: Uncategorized Issue
Severity:
Summary:

This is an issue for the Java RTF. Related issue in Core RTF is Issue 5327.

Originally from Michi Henning:

suppose the following [pseudo-]idl:

#pragma prefix "2abc.def"

module xyz {
    interface q {...};
};

It would generate a Java class 'q' within package 'def.2abc.xyz'. The package name '2abc' is not that popular with the java compiler since it starts with a digit.

Discussion from Jishnu Mukerji:

It seems to me that this is more of a language mapping issue. I don't think that the Repository Ids have any requirement to be of the same shape as a valid IDL identifier. It would be kind of hard to have GUIDs as RepId if that were the case.

But even for IDL type RepIds 12345.com seems to be a perfectly good domain name as is 2ab.com. I don't see why these perfectly valid domain names should be disallowed because the Java language mapping is unable to deal with them.

Further discussion from Michi Henning:

One way to fix it would be to state that:

  1. For the Java mapping, any prefix that starts with a digit gets translated with an underscore prefix, so 2ab would turn into _2ab for the Java mapping.
  2. Characters that can appear in a prefix pragma are limited to some set we'd have to agree on. (Probably the same as for IDL identifiers, plus '.' and possibly hyphen ('-').)

Further discussion from Jishnu Mukerji:

Item 1 in Michi's list needs to be handled by the IDL-Java RTF. This message to issues@omg.org is requesting the creation of an issue covering this item for the Java RTF.

Item 2 can be taken care of in the resolution for Core Issue 5327.

Resolution: Close no change.
Revised Text:
Actions taken:
October 23, 2002: received issue
Discussion:

#pragma prefix affects only the repository ID, not the actual package into which the interface is placed. In fact, there are no #pragmas defined in the IDL to Java mapping. Various IDL to Java compilers include mechanisms to map IDL types into specific Java packages. For example, Sun's idlj supports a flag 

    -pkgPrefix <t> <prefix>

which puts the <prefix> in front of the normal mapping of <t>. Since all such mechanisms are proprietary, no spec change is needed here.

Issue 5728: How does a Java ORB implement a write_fixed/read_fixed? (java-rtf)

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

From the OMG mapping specs:

org.omg.CORBA.portable.OutputStream [as of formal/01-06-06] defines: 

public void write_fixed(java.math.BigDecimal value, short digits, short scale) { 
    throw new org.omg.CORBA.NO_IMPLEMENT(); 
}

org.omg.CORBA.portable.OutputStream [as of formal/01-06-06] defines:

public java.math.BigDecimal read_fixed(short digits, short scale) { 
    throw new org.omg.CORBA.NO_IMPLEMENT(); 
}

JDK 1.4 (and prior versions) do not implement the first two items, so no portable bindings could be used for these.

Should there have been an org.omg.CORBA_2_4.portable.OutputStream and org.omg.CORBA_2_4.portable.InputStream that inherit from org.omg.CORBA_2_3.portable.In/OutStream and add these?

Resolution: Close no change.
Revised Text:
Actions taken:
October 28, 2002: received issue
Discussion:
Both the IDL to Java mapping specification and the .zip archive have the correct methods, so there is no OMG specification change required here. However, the two methods are indeed missing in J2SE 1.4, and so the originator of this issue should file a bug against the J2SE 1.4 CORBA implementation. (Wearing my Sun hat for a minute, I'll tell you that this error cannot be fixed until J2SE 1.5, since it requires adding new methods to a public interface).

Issue 5782: Missing operations on org.omg.CORBA.Object (java-rtf)

Click here for this issue's archive.
Source: Sun Microsystems (Mr. Ken Cavanaugh, kcavanaugh@acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

While reviewing the latest CORBA 3.1 draft, I noticed that a number of methods recently added to CORBA::Object are missing from org.omg.CORBA.Object. The list of missing methods is:

A group of related issues in the core RTF (core issues 3403/3772/3793/3322) are all centered on questions about access to ORB operations. The solution to this problem has converged on making the ORB available on every object reference. I am including this change in this issue as well. It turns out that the Java mapping requires updating 4 separate standard classes for every new method that is added to CORBA::Object. 2 of the 4 classes in the mapping already have an ORB accessor. The main change required to support access to the ORB is in the LocalObject implementation.

Resolution: Incorporate changes and close issue.
Revised Text:
Clearly we need to map these operations into the Object interface. Note that LocalObject, org.omg.CORBA.portable.ObjectImpl, and org.omg.CORBA.portable.Delegate are also affected by these methods.

In the case of get_orb, note that ObjectImpl and Delegate already have an ORB accessor method (_orb() and orb() respectively). For consistency with the rest of the mapping, we will map CORBA::Object.get_orb() to the java method orb.omg.CORBA.Object._get_orb(). This then makes the ORB available to all org.omg.CORBA.Object instances without needing to access the underlying ObjectImpl or LocalObject that implements the interface. We will also need to extend LocalObject with an additional constructor that allows setting of a private transient ORB data member.

Note that all of these changes described for the spec must also be applied to the corresponding classes in the source file archive:

Changes required:

In section 1.19.11, add the following methods at the end of org.omg.CORBA.Object: 

        
        Policy _get_client_policy( int type ) ;

        PolicyList _get_policy_overrides( int[] types ) ;

        boolean _validate_connection( PolicyListHolder inconsistent_policies ) ;

        org.omg.CORBA.Object _get_component() ;

        org.omg.CORBA.ORB _get_orb() ;

In section 1.20.2.1, add the following data member at the start of the class: 

        private transient org.omg.CORBA.ORB orb = null ;

add the following constructor immediately following LocalObject():

        public LocalObject( ORB orb )
        {
            this.orb = orb ;
        }

add the following methods at the end of LocalObject: 

        public Policy _get_client_policy( int type )
        {
            throw new NO_IMPLEMENT() ;
        }

        public PolicyList _get_policy_overrides( int[] types )
        {
            throw new NO_IMPLEMENT() ;
        }

        public boolean _validate_connection( PolicyListHolder inconsistent_policies )
        {
            throw new NO_IMPLEMENT() ;
        }

        public org.omg.CORBA.Object _get_component()
        {
            throw new NO_IMPLEMENT() ;
        }

        public ORB _get_orb()
        {
            if (orb == null)
                throw new OBJECT_NOT_EXIST( TBD, CompletionStatus.COMPLETED_NO ) ;

            return orb ;
        }

where TBD is the standard OMG minor code signifying that no ORB is associated with the local object.

In section 1.21.6.3, add the following methods at the end of org.omg.CORBA.portable.ObjectImpl: 

        Policy _get_client_policy( int type )
        {
            return _get_delegate().get_client_policy( type ) ;
        }

        PolicyList _get_policy_overrides( int[] types )
        {
            return _get_delegate().getPolicy_overrides( types ) ;
        }

        boolean _validate_connection( PolicyListHolder inconsistent_policies )
        {
            return _get_delegate().validate_connection( inconsistent_policies ) ;
        }

        org.omg.CORBA.Object _get_component()
        {
            return _get_delegate().get_component() ;
        }

In section 1.21.7, add the following methods to abstract class Delegate after the set_policy_override method: 

        public Policy _get_client_policy( int type )
        {
            throw new NO_IMPLEMENT() ;
        }

        public PolicyList _get_policy_overrides( int[] types )
        {
            throw new NO_IMPLEMENT() ;
        }

        public boolean _validate_connection( PolicyListHolder inconsistent_policies )
        {
            throw new NO_IMPLEMENT() ;
        }

        public org.omg.CORBA.Object _get_component()
        {
            throw new NO_IMPLEMENT() ;
        }

In the section titled "local interfaces" of section 1.12.1, add the following after item 3. in the numbered list:

4. The _<typename>LocalBase class has 2 public constructors defined as follows:

public _<typename>LocalBase()
{
    super() ;
}

public _<typename>LocalBase( ORB orb ) 
{
    super( orb ) ;
}

In the section titled "local interfaces" of section 1.12.1, replace the phrase "and an instance would be created using the usual Java language construct:" with:

and an instance would be created using the usual Java language construct

<typename>Impl ti = new <typename>Impl( ... ) ;

The constructor(s) defined in <typename>Impl may pass an ORB parameter to the super class constructor using an explicit constructor invocation such as super( orb ). If this is done, the orb passed in the constructor is returned by the _get_orb() method on the local object instance. If the <typename>Impl() constructor is used, a call to _get_orb() will result in an OBJECT_NOT_EXIST exception with a standard minor code of TBD.

Actions taken:
December 2, 2002: received issue

Issue 5783: Stub handling of UnknownException (java-rtf)

Click here for this issue's archive.
Source: International Business Machines (Ms. Anne E. Dalton, ann_dalton@uk.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

Following resolution of issue 5465 in vote 4, Section 1.21.6.3 "Streaming Stub APIs" 3rd main bullet reads as follows:

I think there are problems with the new final paragraph:

  1. It's unclear whether the additional paragraph requires a change to Stub code or to the ORB runtime.
  2. It's undesirable, and unnecessary in this case, to differentiate between ORBs which do and do not implement RMI. The rule can, and should, be the same for all Java ORBs.
  3. It is incorrect to mandate that any ORB must translate the UnknownException to the nested exception because, as the nested exception is defined as a Throwable, this isn't always possible.

Resolution: Incorporate change and close issue.
Revised Text:
Replace Section 1.21.6.3 "Streaming Stub APIs" 3rd main bullet with the following:

If the CORBA system exception org.omg.CORBA.portable.UnknownException is thrown, the stub translates it to the nested exception that the UnknownException contains, if possible. If this is not possible, the stub passes the UnknownException on directly to the user

Actions taken:
December 3, 2002: received issue

Content-Type: APPLICATION/octet-stream; name="03-01-02.zip"; x-unix-mode=0444