View source for Documentation/DevGuide/ProUNO/Java/Inexact approximation of UNO Value Semantics

From Apache OpenOffice Wiki

← Documentation/DevGuide/ProUNO/Java/Inexact approximation of UNO Value Semantics

You do not have permission to edit this page, for the following reasons:

• The action you have requested is limited to users in the group: Users.
• You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

---

You can view and copy the source of this page.

{{Documentation/DevGuide/ProUNOTOC |ProUNO2c=block |ProUNO2cJava=block |ProUNO2cJavaTM=block |ShowPrevNext=block |PrevPage=Documentation/DevGuide/ProUNO/Java/Mapping of Singletons |NextPage=Documentation/DevGuide/ProUNO/C++/C++ Language Binding }} {{Documentation/DevGuideLanguages|Documentation/DevGuide/ProUNO/Java/{{SUBPAGENAME}}}} {{DISPLAYTITLE: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 <code>com.sun.star.Type</code> 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 <code>com.sun.star.uno.Any</code> (which should really be immutable), or to an unwrapped object that represents a UNO value of type <code>string</code> or type, or of a sequence, enum, struct or exception type. Note that the types <code>java.lang.Boolean</code>, <code>java.lang.Byte</code>, <code>java.lang.Short</code>, <code>java.lang.Integer</code>, <code>java.lang.Long</code>, <code>java.lang.Float</code>, <code>java.lang.Double</code>, and <code>java.lang.Character</code>, 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. {{PDL1}} [[Category:Documentation/Developer's Guide/Professional UNO]]

Return to Documentation/DevGuide/ProUNO/Java/Inexact approximation of UNO Value Semantics.