Java versus C++ API

The Java language implies several differences between the C++ and the Java API. This section may be skipped by Java-only developers.

Classes and extensions not available in Open Inventor Java

  • The DialogViz classes provided with Open Inventor C++ are not available because you will use the standard AWT or Swing Java package instead.
  • The GDI output available with HardCopy C++ is not available in the HardCopy package of Open Inventor Java.
  • The TerrainViz extension is not available in Java.

C++ features not available in Open Inventor Java

The following is not possible with Open Inventor Java:

  • Creating new nodes without writing native C++ code and thus breaking the portability of the application code.
  • Calling OpenGL directly from Java.

C++ features available in Java but with a different interface

The following features cannot be implemented as they are in C++.

Callback mechanism

The callback mechanism is used very often by Open inventor C++. Callback functions are defined as follows:

typedef <return_type> functionCB(void * userData, type1 arg1,..., typen argn);
static <return_type> myFunctionCB(void * userData, type1 arg1,..., typen argn)

The callback is registered by calling an addCallback method:

 addCallback((functionCB*) myFunctionCB, this);

The Java implementation is very similar: Each type of callback is implemented by a specific class. To create a new callback, the user must extend this class and overwrite the default invoke method of the class. Then the callback is registered by the addCallback method and the invoke method is called by Open Inventor. The user's data defined in C++ as the first argument of functionCB should be defined as a member of your own extended class.

The following example from the program shows how to set a callback on a keyboard event.

The ProcessKeyEventsextends the SoEventCallbackCB to add its own invoke method. A specific constructor is defined to save the user's data:

class ProcessKeyEvents extends SoEventCallbackCB
  // "user's data"
  private SwSimpleViewer m_viewer;
  private String m_filename;
  private int m_type;

  public ProcessKeyEvents(SwSimpleViewer viewer, String filename, int type)
    m_viewer = viewer;
    m_filename = filename;
    m_type = type;

   public void invoke(SoEventCallback cb)
    if (SoKeyboardEvent.isKeyPressEvent(cb.getEvent(), SoKeyboardEvent.P))

The callback is registered as follows:

// Setup t he event callback data and routine for performing the print
eventCB.addEventCallback(SoKeyboardEvent.class, new ProcessKeyEvents(viewer, argv[2], type), null);

Pointers, values

All objects are handled through references. No pointers or values, but only references.

Operator redefinition

Several C++ classes redefine standard operators. This is not possible in Java. Alternate methods are provided to allow this kind of operation. For example, the SbVec3f operator = method is replaced by SbVec3f.setValue().

Methods with parameters given as references on basic types

When a C++ method takes a reference on a basic type as an argument, the Java prototype differs from the C++. This difference does not exist for Inventor types (So or Sb). The Java binding uses a reference on a basic type array to get the new value.
An example of this difference is shown with the Render Area getAntialiasing method.
In C++:

void g etAntialiasing(SbBool &smoothing, int &numPasses) const

In Java:

public v oid getAntialiasing(boolean [] smoothing, int [] numPasses)

To call this method with Java, the user must define an array of 1 element for each parameter:

boolean [] smoothing = new boolean [1];
int [] numpasse s = new int [1];
area.getAntialiasing(smoothing, numpasses);


C++ features that are not necessary in Java

  • The C++ methods SoBase::ref(), SoBase::unref(), and SoBase::unrefNoDelete() are not needed because reference counting is a feature of the Java language.
  • Class SoType is not needed because java.lang.Class is equivalent.
  • Class SbString is not needed because java.lang.String is equivalent.
  • SoDB.init, PoBase.init, SoInteraction, and SoNodeKit are not needed because these classes are automatically initialized when loading the first class that extends com.openinventor.inventor.