Advanced UNO

From Apache OpenOffice Wiki
Jump to: navigation, search

PDF Icon.gif Download as a PDF or ODT

Choosing an Implementation Language

The UNO technology provides a framework for cross-platform and language independent programming. All the Apache OpenOffice components can be implemented in any language supported by UNO, as long as they only communicate with other components through their IDL interfaces.

Documentation note.png Note: The condition "as long as they only communicate with other components through their IDL interfaces" is to be strictly taken. In fact, a lot of implementations within Apache OpenOffice export UNO interfaces and still use private C++ interfaces. This is a tribute to older implementations that cannot be rewritten in an acceptable timeframe.

A developer can customize the office to their needs with this flexibility, but they will have to decide which implementation language should be selected for a specific problem.

Supported Programming Environments

The support for programming languages in UNO and Apache OpenOffice is divided into three different categories.

  1. Languages that invoke calls on existing UNO objects are possibly implemented in other programming languages. Additionally, it may be possible to implement certain UNO interfaces, but not UNO components that can be instantiated by the service manager.
  2. Languages that implement UNO components. UNO objects implemented in such a language are accessible from any other language that UNO supports, just by instantiating a service by name at the servicemanager. For instance, the developer can implement a Apache OpenOffice Calc addin (see Spreadsheet Documents).
  3. Languages that are used to write code to be delivered within Apache OpenOffice documents and utilize dialogs designed with the Apache OpenOffice dialog editor.

The following table lists programming languages currently supported by UNO. 'Yes' in the table columns denotes full support, 'no' denotes that there is no support and is not even planned in the future. 'Maybe in future' means there is currently no support, but this may change with future releases.

Language UNO scripting UNO components Deployment with Apache OpenOffice documents
C++ yes yes no
C maybe in future maybe in future no
Java yes yes maybe in future
StarBasic yes no yes
OLE automation (win32 only) yes maybe in future maybe in future
Python maybe in future (under development) maybe in future (under development) maybe in future

Java is a an accepted programming language offering a standard library with a large set of features and available extensions. Additional extensions will be available in the future, such as JAX-RPC for calling webservices. It is a typesafe language with a typesafe UNO binding. Although interfaces have to be queried explicitly, the type safety makes it suitable for larger projects. UNO components can be implemented with Java, that is, the Java VM is started on demand inside the office process when a Java component is instantiated. The OfficeBean allows embedding Apache OpenOffice documents in Java Applets and Applications.

There is a constant runtime overhead of about 1 to 2 ms per call that is caused by the bridge conversion routines when calling UNO objects implemented in other language bindings. Since Apache OpenOffice consists of C++ code, every Java call into the office needs to be bridged. This poses no problems if there are a few calls per user interaction. The runtime overhead will hurt the application when routines produce hundreds or thousands of calls.


C++ is an accepted programming language offering third-party products. In addition to C++ being fast since it is compiled locally, it offers the fastest communication with Apache OpenOffice because most of the essential parts of office have been developed in C++. This advantage becomes less important as you call into the office through the interprocess bridge, because every remote call means a constant loss of 1 to 2 ms. The fastest code to extend the office can be implemented as a C++ UNO component. It is appropriate for larger projects due to its strong type safety at compile time.

C++ is difficult to learn and coding, in general, takes longer, for example, in Java. The components must be built for every platform, that leads to a higher level of complexity during development and deployment.

OpenOffice Basic

Apache OpenOffice Basic is the scripting language developed for and integrated directly into Apache OpenOffice. It currently offers the best integration with Apache OpenOffice, because you can insert code into documents, attach arbitrary office events, such as document loading, keyboard shortcuts or menu entries, to Basic code and use dialogs designed within the Apache OpenOffice IDE. In Basic, calls are invoked on an object rather than on a specific interface. Interfaces, such as are integrated as Basic object properties. Basic always runs in the office process and thus avoids costly interprocess calls.

The language is type unsafe, that is, only a minimal number of errors are found during compilation. Most errors appear at runtime, therefore it is not the best choice for large projects. The language is Apache OpenOffice specific and only offers a small set of runtime functionality with little third-party support. All office functionality is used through UNO. UNO components cannot be implemented with Basic. The only UNO objects that can be implemented are listeners. Finally, Basic does not offer any thread support.

OLE Automation Bridge

The OLE Automation bridge opens the UNO world to programming environments that support OLE automation, such as Visual Basic, JScript, Delphi or C++ Builder. Programmers working on the Windows platform can write programs for Apache OpenOffice without leaving their language by learning a new API. These programmers have access to the libraries provided by their language. It is possible to implement UNO objects, if the programming language supports object implementation.

This bridge is only useful on a Win32 machine, thereby being a disadvantage. Scripts always run in a different process so that every UNO call has at least the usual interprocess overhead of 1 to 2 ms. Currently Automation UNO components cannot be implemented for the service manager, but this may change in the future.


A Python scripting bridge (PyUNO) is currently developed by Ralph Thomas. It is available in an experimental alpha state with known limitations. For details, see PyUNO on

Use Cases

The following list gives typical UNO applications for the various language environments.

  • Servlets creating Office Documents on the fly, Java Server Pages
  • Server-Based Collaboration Platforms, Document Management Systems
  • Calc add-ins
  • Chart add-ins
  • Database Drivers
  • Filters reading document data and generating Office Documents through UNO calls
  • Database Drivers
  • Calc add-ins
  • Chart add-ins
OpenOffice Basic
  • Office Automation
  • Event-driven data-aware forms
OLE Automation
  • Office Automation, creating and controlling Office Documents from other applications and from Active Server Pages
  • Calc add-ins


All languages have their advantages and disadvantages as previously discussed, but there is not one language for all purposes, depending on your use. Consider carefully before starting a new project and evaluate the language to use so that it saves you time.

Sometimes it may be useful to use multiple languages to gain the advantages of both languages. For instance, currently it is not possible to attach a keyboard event to a Java method, therefore, write a small Basic function, which forwards the event to a Java component.

The number of languages supported by UNO may increase and some limitations shown in the table above may disappear.

Content on this page is licensed under the Public Documentation License (PDL).
Personal tools
In other languages