Difference between revisions of "Documentation/DevGuide/ProUNO/Differences Between the Lifetime of C++ and Java Objects"

Revision as of 21:01, 3 July 2018

Read C++ Language Binding and Java Language Binding for information on language bindings, and C++ Component and Storing the Service Manager for Further Use about component implementation before beginning this section.

The implementation of the reference count specification is different in Java UNO and C++ UNO. In C++ UNO, every object maintains its own reference counter. When you implement a C++ UNO object, instantiate it, acquire it and afterwards release it, the destructor of the object is called immediately. The following example uses the standard helper class ::cppu::OWeakObject and prints a message when the destructor is called.

  class MyOWeakObject : public ::cppu::OWeakObject
  {
  public:
      MyOWeakObject() { printf( "constructed\n" ); }
      ~MyOWeakObject() { printf( "destroyed\n" ); }
  };

The following method creates a new MyOWeakObject, acquires it and releases it for demonstration purposes. The call to release() immediately leads to the destruction of MyOWeakObject. If the Reference<> template is used, you do not need to care about acquire() and release().

  void simple_object_creation_and_destruction()
  {
      // create the UNO object
      com::sun::star::uno::XInterface * p = new MyOWeakObject();
 
      // acquire it 
      p->acquire();
 
      // release it
      printf( "before release\n" );
      p->release();
      printf( "after release\n" );
  }

This piece of code produces the following output:

 constructed
 before release
 destroyed
 after release

Java UNO objects behave differently, because they are finalized by the garbage collector at a time of its choosing. com.sun.star.uno.XInterface has no methods in the Java UNO language binding, therefore no methods need to be implemented, although MyUnoObject implements XInterface:

  class MyUnoObject implements com.sun.star.uno.XInterface {
 
      public MyUnoObject() {
      }
 
      void finalize() {
          System.out.println("finalizer called");
      }
 
      static void main(String args[]) throws java.lang.InterruptedException {
          com.sun.star.uno.XInterface a = new MyUnoObject();
          a = null;
 
          // ask the garbage collector politely 
          System.gc();
          System.runFinalization();
 
          System.out.println("leaving");
 
          // It is java VM dependent, whether or not the finalizer was called
      }
  }

The output of this code depends on the Java VM implementation. The output "finalizer called" is not a usual result. Be aware of the side effects when UNO brings Java and C++ together.

When a UNO C++ object is mapped to Java, a Java proxy object is created that keeps a hard UNO reference to the C++ object. The UNO core takes care of this. The Java proxy only clears the reference when it enters the finalize() method, thus the destruction of the C++ object is delayed until the Java VM collects some garbage.

When a UNO Java object is mapped to C++, a C++ proxy object is created that keeps a hard UNO reference to the Java object. Internally, the Java UNO bridge keeps a Java reference to the original Java object. When the C++ proxy is no longer used, it is destroyed immediately. The Java UNO bridge is notified and immediately frees the Java reference to the original Java object. When the Java object is finalized is dependent on the garbage collector.

When a Java program is connected to a running OpenOffice.org, the UNO objects in the office process are not destroyed until the garbage collector finalizes the Java proxies or until the interprocess connection is closed (see UNO Interprocess Connections).