recommended/SRC680m111 : Java UNO Class Loader
[email protected] Wed, 21 Sep 2005 13:06:26 +0200 (CEST)
| Newsgroups | gmane.comp.openoffice.announce.interface |
|---|---|
| Message-ID | <8482264.1127300786455.JavaMail.root@sd-web1> |
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]