-
Key: I2JAV11-23
-
Legacy Issue Number: 3995
-
Status: closed
-
Source: hursley.ibm.com ( Simon Nash)
-
Summary:
n 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.Proposed resolution:
In section 1.12.2, second bullet, change "For IDL in parameters that
are valuetypes" to "For IDL in parameters that are non-boxed valuetypes:"In section 1.12.2, second bullet, change "With the exception of value
types" to "With the exception of non-boxed value types".In section 1.12.2, add new third bullet:
For IDL in parameters that are boxed valuetypes:
Java objects passed for boxed valuetype IDL in parameters are created and owned
by the caller. The callee must not modify boxed valuetype in parameters or retain
a reference to the in parameter beyond the duration of the call. Violation of
these rules can result in unpredictable behavior.In section 1.21.5.1, second paragraph, change "the stub copies all
valuetypes" to "the stub copies all non-boxed valuetypes". -
Reported: I2JAV 1.0 — Wed, 25 Oct 2000 04:00 GMT
-
Disposition: Resolved — I2JAV 1.1
-
Disposition Summary:
close no change
-
Updated: Fri, 6 Mar 2015 20:58 GMT
I2JAV11 — Copying boxed valuetypes on local calls
- Key: I2JAV11-23
- OMG Task Force: IDL to Java December 2000 RTF