Type recommended
Title Java UNO Class Loader
Posted by [EMAIL PROTECTED]
Affected ,.
Effective from SRC680m111


Summary

+ unoloader.jar:
+ class com.sun.star.lib.unoloader.UnoLoader (external)
+ class com.sun.star.lib.unoloader.UnoClassLoader (internal)

+ jvmaccess/unovirtualmachine.hxx:
+ class jvmaccess::UnoVirtualMachine

UNOIDL com.sun.star.java.XJavaVM:
~ getJavaVM

unorc/uno.ini:
+ URE_INTERNAL_JAVA_PATH

JAR manifest:
+ UNO-Type-Path


Description
To make the Java UNO runtime more robust and efficient, the UNO
component class loading has been redesigned in a compatible way:
Instead of loading all Java UNO components into one class loader, each
component is now loaded with its own class loader, with one
UnoClassLoader at the root that takes care of loading all Java classes
representing UNO types in such a way that they are available across
the whole Java UNO runtime environment. These changes take effect in
the stand-alone URE, but not yet in OOo (i.e., OOo continues to put
all Java UNO components on the JVM's CLASSPATH).

A number of changes were necessary:

- There is a new unoloader.jar (from CVS module ridljar) that contains
the new UnoClassLoader (which is private) and a helper class UnoLoader
(which is public). To make the changes to the Java UNO runtime class
loading effective, this JAR must be loaded first, and everything else
must be loaded through the UnoClassLoader. This has not yet been
incorporated into the "Transparent Use of Office UNO Components"
<http://udk.openoffice.org/common/man/spec/transparentofficecomponents.html>
(which also is not yet necessary, as OOo has not yet been adapted to
those changes, see above). The Makefile in the new uretest.zip
contains an example of how to set up a Java application that
bootstraps through unoloader.jar.

- com.sun.star.java.XJavaVM.getJavaVM has an additional third mode (17
byte processID, last byte 0x01) to group together a JVM pointer and a
UnoClassLoader instance, represented with the new C++ class
jvmaccess::UnoVirtualMachine.

- To function properly, the com.sun.star.java.JavaVM service
(javavm.uno dynamic library) expects a new variable
URE_INTERNAL_JAVA_PATH to be set in unorc/uno.ini. See comment in
stoc/source/javavm/javavm.cxx 1.67.6.4, lines 184--192.

- There is support for a new JAR manifest entry "UNO-Type-Path". If a
Java UNO component requires additional UNO types, use the
UNO-Type-Path manifest entry to specify the location of the UNO types.
The UNO-Type-Path is similar to the Class-Path manifest entry and can
contain URLs of JARs and directories that contain the Java classes
that represent additional UNO types. The UnoClassLoader evaluates the
UNO-Type-Path manifest entry to ensure that the additional UNO types
are available to the Java UNO environment. The UNO-Type-Path can have
the following entries:
UNO-Type-Path:
Current JAR does not contain UNO types.
UNO-Type-Path: <>
Current JAR contains UNO types.
UNO-Type-Path: any/other/jar.jar yet/another/jar.jar
Current JAR brings other JARs that contain UNO types.
UNO-Type-Path: any/other/jar.jar <> yet/another/jar.jar
Current JAR and other JARs that the current JARs uses contain UNO
types.
NOTE: If you do not include the UNO-Type-Path manifest entry, the URE
assumes that the current JAR contains UNO types.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to