I2JAV11 — Valuetype unmarshalling

The rules for valuetype unmarshalling in section 1.13.8 of the IDL to
Java mapping spec need to be expanded. There are two issues with the
algorithm currently described:

1. The algorithm described is based purely on the repository ID,
which may either be read off the wire or passed as an argument on
the read_value() call. However, if the expected type is passed
as an argument on the read_value() call, then this should be taken
into account in the unmarshalling algorithm.
2. In some cases, the unmarshaller does not have enough information
to distinguish between a boxed valuetype (which is unmarshalled
using a helper object) and a regular valuetype (which is unmarshalled
using a value factory). An additional step in the unmarshalling
algorithm is needed to cover these cases.

Proposed resolution:

In section 1.13.8, add a new bullet before the existing second bullet
as follows:
• If this is not successful and an expected type clz was passed on the
read_value call, and if clz implements IDLEntity but not ValueBase, then
unmarshal the valuetype as a boxed IDL type by calling the read method
of <clz>Helper.

In section 1.13.8, add a new bullet before the existing third bullet
as follows:
• If this is not successful and the RepositoryId is a standard repository id that starts
with “IDL:”, then attempt to generate the boxed value helper class name to use by
stripping off the “IDL:” header and “:<major>.<minor>” version information
trailer, and replacing the “/”s that separate the module names with “.”s and
appending “Helper.”

In section 1.13.8, add a new bullet before the existing fourth bullet
as follows:
• If this is not successful and an expected type clz was passed on the
read_value call, and if clz does not implement IDLEntity, then use the
ValueHandler interface to read in the value (see the Java to IDL Language
Mapping document, Section 1.5.1.3, “ValueHandler,” on page 1-40).

Incorporate the revised text and close the issue