The recent passage of issue 4337 in the core RTF creates a need to update the Java
mapping to include support for the _repository_id operation. Here is the proposed
set of updates to the latest (unofficial) Java mapping specifiction (ptc/02-01-01):

--------------------------------------------------------------

In section 1.19.11, add the following method to Object after _get_interface_def:

string _repository_id() ;

In section 1.20.2.1, add the following method to LocalObject after _get_interface_def
(this is the local interface part, I am assumming here that local interfaces
support repository_id. If not, this should just throw a NO_IMPLEMENT exception):

public String _repository_id()

In section 1.20.2.2, add the following method to Servant after _get_interface_def:

public String _repository_id()

In section 1.21.7, add the following method to Delegate after get_interface_def:

public abstract String repository_id(
org.omg.CORBA.Object self) ;

In section 1.21.8, add the following method to Delegate after get_interface_def:

String repository_id( Servant self ) ;

Incorporate changes and close issue

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

• If the CORBA system exception org.omg.CORBA.portable.UnknownException
  is thrown, the stub does one of the following:
• Translates it to org.omg.CORBA.UNKNOWN
• Translates it to the nested exception taht the UnknownException
  contains.
• Passes it on directly to the user

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.

I think there are problems with the new final paragraph
a. It's unclear whether the additional paragraph requires a change to
Stub code or to the ORB runtime.
b. 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.
c. 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.

Proposal:
I think it would be preferable to simply reword Section 1.21.6.3
"Streaming Stub APIs" 3rd main bullet, as follows:

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

Incorporate change and close issue

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:

get_client_policy
get_policy_overrides
validate_connection
get_component

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.

I plan to include this issue in the next java-rtf vote. Please note the question inline
below, and let me know if you have any strong opinions one way or the other.

Incorporate changes and close issue

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)

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

Should there 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?

Close no change

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.

close no change

Are both of these correct?
[It seems like the Java maps
"sequence <ServiceDetailType> 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

;
struct ServiceInformation

;

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)

}

Incorporate changes and close issue

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

• in enumeration ThreadPolicyValue: the MAIN_THREAD_MODEL value
• in Current: operations get_reference and get_servant

Proposed Resolution:
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;

Incorporate changes and close issue

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

Incorporate changes and close issue

the DataInputStream and
DataOutputStream are specified in IDL as abstract valuetypes in Chapter
5, and they do not follow the standard language mapping for abstract
valuetypes at least in the Java Language Mapping. So does this imply
that we should move the source file from CORBA_IDL directory to
CORBA_PIDL directory? The thing compiles alright as IDL but in case of
Java it does not produce the right Java code

Make the required changes to the standard Java source files as described in the revised text

The org\omg\CORBA\Object.java 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?

close issue

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?

resolved

There is something that is unclear in your CORBA spec that I think is causing incompatibility problems between various IDL compilers.

Given the following IDL:

------------------------------------------------- struct Protection

;

typedef Protection ProtectedEntity;

typedef sequence<ProtectedEntity> ProtectedEntityList;

typedef ProtectedEntityList ProtectingEntity; -------------------------------------------------

Should a holder class for ProtectingEntity get generated? I ask this because some IDL compilers generate it and others do not (very frustrating!).

In section 1.18.2 of the OMG IDL mapping document ptc/00-01-08 spec I found this: "Holder classes are generated for sequence and array typedefs only. The "unwound" type's Holder class is used for the other cases.".

Since this is a typedef of a typedef, but the original item was a sequence, should the ProtectingEntityHolder.java file get generated or not?

duplicate of 4802

The IDL-to-Java ptc/00-11-03 specification says that an implementation
of a local interface would extend org.omg.CORBA.LocalObject instead of
org.omg.CORBA.Object. This is underspecified. It does not say
anything about the generated classes for a local interface, their
relationships, nor which one should be implemented by an
implementation. This MUST be specified for local interface
implementations to be portable.

I suggest for local interface X the following generated classes:

interface X extends XOperations, org.omg.CORBA.Object

This is similar to a non-local mapping except that it does not extend
org.omg.CORBA.portable.IDLEntity. Although that would not hurt
anything it is not necessary since a local interface cannot be
marshaled.

I suggest the following specification for implementations of local interfaces:

class XImpl
extends org.omg.CORBA.LocalObject
implements X

An instance would be create using the usual language construct:

XImpl x = new XImpl(...);

The above must be specified just like the current spec says what to do
with a POA-based implementation of a non-local interface, e.g.,:

class YImpl extends YPOA

see below

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

see below

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 {

closed issue...editorial change

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?

see below

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.

No Data Available

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.

see below

it appears that the Java mapping for unions is incomplete. For example:

enum E

;

union U switch (E)

;

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

;

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.

withdrawn by submitter

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

see below

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.

see below

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.

closed issue, editorial change

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.

closed issue...editorial

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

;

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.

closed issue, editorial change

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.

editorial fix, issue closed

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.

see below

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 _write(
org.omg.CORBA.portable.OutputStream os)

see below

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 {}

editorial fix, issue closed

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.

see below

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?

see below

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.

No Data Available

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.

Close, Duplicate of 3668

(6). The mapping for org.omg.PortableServer.Servant.java specifies the
following signature for _get_interfaces.

final public org.omg.CORBA.InterfaceDef _get_interface()

the new signature according to CORBA 2.3 spec is:

public org.omg.CORBA.Object _get_interface_def()

see below

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

close, no change

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.

No Data Available

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

close, no change

(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

No Data Available

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

Close, duplicate of 3669

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

No Data Available

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.

see below

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.

closed, duplicate of issue 3707

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)

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.

Closed...editorial issue

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

closed, editorial change

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?

No Data Available

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.

No Data Available

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.

Close, no change

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.

No Data Available

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.

Close, no change.

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.

closed, no change

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.

see below

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.

Close, no change.

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

No Data Available

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.

resolved, see revised text

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.

No Data Available

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.

Make it so.

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.

closed, no action

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.

closed, no action

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.

Merge the two stub classes together as one class with as minimal impact on the APIs and performance.

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?

The latter. A different exception shall be raised to indicate other errors.

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.

The helper is generated for all aliases, it can be used if needed.

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

closed, no action

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

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

resolved

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.

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?

These functions (library) has been deprecated by the newly adopted Interoperable Naming Service.

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.

resolved, see revised text

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.

Close, no action

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

Close, no action

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

Close, no action

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.

resolved, see revised text

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.

closed issue

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

closed issue

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.

Close, no action

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.

Close, no action

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.

closed issue

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?

closed issue

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.

closed issue

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.

closed issue

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.

closed issue

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

closed issue

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.

closed issue

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.

closed issue

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.

closed issue

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.

closed issue

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.

closed issue

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.

closed issue

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.

closed issue

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

closed issue

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.

closed issue

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.

closed issue

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.

closed issue

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?

closed issue

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)

}

closed issue

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.

closed issue

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.

closed issue

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.

closed issue

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

duplicate, issue closed

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.

resolved/closed

Summary:

closed issue, resolved

Summary:

closed issue, resolved

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

closed issue

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.

closed issue

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)

closed issue

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.

closed issue

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

Clarify the IDL Name conflict resolution rules to resolve this case. Also change the naming rules

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.