I2JAV13 — Description of ORB.init parameters insufficient

I have a number of questions/concerns about the description/usage of
ORB.init arguments/properties.

1. There are only two properties described in the Java mapping spec:
org.omg.CORBA.ORBClass and org.omg.CORBA.ORBSingletonClass. Setting these
via property are described, but not setting these via application string
array (ie., args in main). Yet the spec says these values can be obtained
via the args array. I believe most folks assume "-ORBClass xxx" is the
convention, since that's what the JDK's ORB uses, but it's not documented.

2. Ditto for applet parameters. It's assumed that they are of the form

<param name = "org.omg.CORBA.ORBClass" value = "xxx">

but it is not documented.

3. Can this convention be generalized to accommodate the argument naming
convention in the core spec? If we follow the convention that says
org.omg.CORBA.ORBClass becomes -ORBClass; then can we say that a parameter
-ORBXXX may also be specified by the property or applet parameter
org.omg.CORBA.ORBXXX?

4. The text around the ORB arguments is tightly coupled to only ORBClass
and ORBSingletonClass. It does not seem to expect other args/properties.
For example: "...when creating an ORB instance, the class names of the ORB
implementation are located using the following search order: ...". I
assume the following search order also applies to any args/props.

5. The spec doesn't allow for extensions.

"See Table 1-3 for a list of the property names and values that are
recognized by
ORB.init. Any property names not in this list shall be ignored by
ORB.init()."

Has the INS spec updated this table with -ORBInitRef and
-ORBDefaultInitRef, for example? And the interceptor spec assumes that
services are allowed to have their own arguments. And what about
proprietary extensions? Given the word "shall", any extensions are
non-CORBA-compliant.

6. Repeated arguments fall apart when presented as Properties. For
example, the INS spec allows for the following invocation:

java myapp -ORBInitRef XX=xx -ORBInitRef YY=yy -ORBInitRef ZZ=zz

Since Properties entries are <key, value> pairs, and only one pair for a
given key can exist, then if we tried entering the above as Properties we'd
only get on of them, not all. I'm not sure how to fix this. Dictate that
XX, YY, ZZ be the end of the ORBInitRef string rather than the start of a
new string, perhaps? So then, specifying these as system properties for
example, we'd have:

java myapp -Dorg.omg.CORBA.ORBInitRefXX xx -Dorg.omg.CORBA.ORBInitRefYY yy
-Dorg.omg.CORBA.ORBInitRefZZ zz

That causes ugly parsing problems. We'd have to search the whole list of
properties that contained a key that merely BEGAN with
"org.omg.CORBA.ORBInitRef". And this falls apart in applets; we can get a
list of all Properties, but we cannot get a list of all applet parameters.
Personally I think this is a failing in the applet class, but that's life
as we know it.

I'm sorry to raise this as one issue instead of six, but most of these
points are tightly coupled, so I didn't want to distance them from each
other. And I'd like them all to be answered together anyway.