<The previous article in this series | The table of contents of this series | The next article in this series>
To Know How to Handle (Read or Write) LibreOffice or Apache OpenOffice Writer or Calc Documents via Extensions from Java or Macro Programs
We have already discussed what, basically, is UNO.
Yes. UNO (Universal Network Objects) is the technology in which LibreOffice is built up, and is the whole of specifications about what UNO objects are like, how UNO objects can be handled, and other related issues. The UNO object is a kind of class instance in the meaning of object-oriented language.
Here, we will learn some more characteristic features of UNO.
OK.
UNO is a system of 'programming language'-independent abstract specifications, and those specifications are mapped to specifications in a specific programming language, for example, C++ or Java.
I don't understand well. I think that all specifications are abstract: Java specifications are abstract; Oracle JDK and OpenJDK are their implementations.
. . . Yes, 'abstract' was a redundant adjective. Just forget it.
So, what does 'programming language'-independent exactly mean?
Well, for example, in UNO, a data type, string, is defined, but that data type isn't a data type of a specific programming language. UNO specifications are mapped to specifications in Java, but there is no data type called string in Java.
Isn't the data type, string, provided as a class in a library?
No. The data type, string, is mapped to java.lang.String in Java.
Oh, that's what you mean by 'mapped'. . . . I presume that a UNO object that lives in a programming language can be handled from another programming language?
Yes. UNO objects that live in a programming language in a process can be handled from another programming language in the process or from a programming language in another process including processes in different machines, if there are mappings to those programming languages.
For UNO objects that live in a programming language to be able to be successfully handled from a different programming language, the string data that are passed between two programming languages must be passed as a mutually agreed binary sequence.
Yes, there must be such mutually agreed formats although documents I know don't describe what exactly those formats are. A so-called bridge is established between two UNO programming language environments; when a string datum is passed from a Java environment to a C++ environment, the Java side of the bridge converts the java.lang.String instance to the mutually agreed binary sequence, and send the mutually agreed binary sequence to the other side of the bridge; the other side of the bridge converts the mutually agreed binary sequence to a C++ specific string instance. . . . At least, that's what I speculate. A bridge, specifically, a so-called interprocess bridge, is established between two UNO programming language environments in different processes.
Are UNO objects in a programming language handled from the same UNO programming language environment through a kind of bridge?
Probably not, but I'm not sure: documents I know of don't describe such particulars. There is a reason why I guess so, but I won't delve into it here.
I wonder whether the whole of UNO specifications can be so smoothly mapped to a programming language.
In fact, it can't. As far as I see, there are some bizarre points. For example, the 'long' type in UNO is mapped to the 'int' type in Java; the 'any' type in UNO is mapped to the 'java.lang.Object' type; the 'any' type in UNO can hold 'long' type data in UNO, but the 'java.lang.Object' type can't hold 'int' type data in Java because java.lang.Object can't hold any primitive datum. In such a case, java.lang.Integer is used, . . . but I don't say that's a smooth mapping.
I see. I guess, such twists would be inevitable if you try to map a 'programming language'-independent specifications to a specific programming language.
Theoretically, UNO could be mapped to various programming languages if you allow such twists. In fact, main programming languages to which UNO is mapped are C++ and Java. LibreOffice is, mostly, implemented in C++, and we are going to implement UNO extensions in Java. Part of UNO is mapped to LibreOffice Basic, but what we can do in LibreOffice Basic seems to be limited. For example, UNO extensions can't be developed in LibreOffice Basic, as far as I know. There are also other programming language mappings, but I don't know what can be done in those programming languages.
Ah-ha.
- Apache OpenOffice Wiki. (2014/01/02). Apache OpenOffice Developer's Guide. Retrieved from https://wiki.openoffice.org/wiki/Documentation/DevGuide/OpenOffice.org_Developers_Guide
<The previous article in this series | The table of contents of this series | The next article in this series>