Inexact approximation of UNO Value Semantics
Some UNO types that are generally considered to be value types are mapped to reference types in Java. Namely, these are the UNO types string, type, any, and the UNO sequence, enum, struct, and exception types. The problem is that when a value of such a type (a Java object) is used:
- As the value stored in an any
- As the value of a sequence component
- As the value of a struct or exception member
- As the value of an interface attribute
- As an argument or return value in an interface method invocation
- As an argument in a service constructor invocation
- As a raised exception
then Java does not create a clone of that object, but instead shares the object via multiple references to it. If the object is now modified through any one of its references, all other references observe the modification, too. This violates the intended value semantics.
The solution chosen in the Java language binding is to forbid modification of any Java objects that are used to represent UNO values in any of the situations listed above. Note that for Java objects that represent values of the UNO type string, or a UNO enum type, this is trivially warranted, as the corresponding Java types are immutable. This would also hold for the UNO type type, if the Java class
com.sun.star.Type were final.
In the sense used here, modifying a Java object A includes modifying any other Java object B that is both (1) reachable from A by following one or more references, and (2) used to represent a UNO value in any of the situations listed above. For a Java object that represents a UNO any value, the restriction to not modify it only applies to a wrapping object of type
com.sun.star.uno.Any (which should really be immutable), or to an unwrapped object that represents a UNO value of type
string or type, or of a sequence, enum, struct or exception type.
Note that the types
java.lang.Character, used to represent certain UNO values as any values or as parametric members of instantiated polymorphic struct types, are immutable, anyway, and so need not be considered specially here.
|Content on this page is licensed under the Public Documentation License (PDL).|