From e12c0178012d5b7f094460cf8a9965fc9763f1f1 Mon Sep 17 00:00:00 2001 From: Oliver Bolte Date: Fri, 17 Jun 2005 09:09:50 +0000 Subject: INTEGRATION: CWS sb31 (1.16.14); FILE MERGED 2005/04/07 12:32:51 sb 1.16.14.1: #120220# Added functionality to com.sun.star.java.XJavaVM.getJavaVM to additionally return a jvmaccess::UnoVirtualMachine. --- udkapi/com/sun/star/java/XJavaVM.idl | 64 ++++++++++++++++++++++-------------- 1 file changed, 40 insertions(+), 24 deletions(-) (limited to 'udkapi/com/sun/star/java') diff --git a/udkapi/com/sun/star/java/XJavaVM.idl b/udkapi/com/sun/star/java/XJavaVM.idl index df6f6a0e4b76..7b0b64b53158 100644 --- a/udkapi/com/sun/star/java/XJavaVM.idl +++ b/udkapi/com/sun/star/java/XJavaVM.idl @@ -2,9 +2,9 @@ * * $RCSfile: XJavaVM.idl,v $ * - * $Revision: 1.16 $ + * $Revision: 1.17 $ * - * last change: $Author: obo $ $Date: 2004-06-03 15:54:38 $ + * last change: $Author: obo $ $Date: 2005-06-17 10:09:50 $ * * The Contents of this file are made available subject to the terms of * either of the following licenses @@ -76,10 +76,11 @@ module com { module sun { module star { module java { @deprecated A UNO interface seems to be at the wrong abstraction level for this - functionality (also, the C++ class jvmaccess::VirtualMachine - used by XJavaVM::getJavaVM is - not part of the public C++ UNO runtime API). This should probably be - replaced by an appropriate C/C++ API. + functionality (also, the C++ classes jvmaccess::VirtualMachine + and jvmaccess::UnoVirtualMachine used by + XJavaVM::getJavaVM are not + part of the public C++ UNO runtime API). This should probably be replaced + by an appropriate C/C++ API. */ published interface XJavaVM: com::sun::star::uno::XInterface { @@ -94,35 +95,50 @@ published interface XJavaVM: com::sun::star::uno::XInterface any contains a JNI JavaVM pointer as a long or hyper integer (depending on the platform). If the processID does not match the current - process, or if the VM cannot be instantiated for whatever reason, an - empty any is returned.

- -

If the processID has an additional 17th byte of value - zero, the returned any contains a non-reference-counted - pointer to a (reference-counted) instance of the C++ - jvmaccess::VirtualMachine class, always represented as a - hyper integer. The pointer is guaranteed to be valid as - long as the reference to this + process, or if the VM cannot be instantiated for whatever reason, a + any is returned.

+ +

If the processID has an additional 17th byte of + value 0, the returned any contains a + non–reference-counted pointer to a (reference-counted) instance of + the C++ jvmaccess::VirtualMachine class, always represented + as a hyper integer. The pointer is guaranteed to be valid + as long as the reference to this XJavaVM is valid (but the pointer should be converted into a reference-counted reference as soon as possible). Again, if the first 16 bytes of the processID do not match the current process, or if the VM - cannot be instantiated for whatever reason, an empty any is - returned.

+ cannot be instantiated for whatever reason, a any + is returned.

+ +

If the processID has an additional 17th byte of + value 1, the returned any contains a + non–reference-counted pointer to a (reference-counted) instance of + the C++ jvmaccess::UnoVirtualMachine class, always + represented as a hyper integer. The pointer is guaranteed + to be valid as long as the reference to this + XJavaVM is valid. Again, if + the first 16 bytes of the processID do not match the + current process, or if the VM cannot be instantiated for whatever + reason, a any is returned.

The first form (returning a JNI JavaVM pointer) is mainly for backwards compatibility, new code should use the second form - (returning a pointer to a jvmaccess::VirtualMachine). For - example, one advantage of using jvmaccess::VirtualMachine - instead of the raw JavaVM pointer is that whenever you - attach a native thread to the Java virtual machine, that thread's - context ClassLoader (see + (returning a pointer to a jvmaccess::VirtualMachine) if it + does not want to use the Java UNO environment, and it should use the + third form (returning a pointer to a + jvmaccess::UnoVirtualMachine) if it wants to use the Java + UNO environment. For example, one advantage of using + jvmaccess::VirtualMachine instead of the raw + JavaVM pointer is that whenever you attach a native thread + to the Java virtual machine, that thread's context + ClassLoader (see java.lang.Thread.getContextClassLoader) will automatically be set to a meaningful value.

@param processID - The process ID of the caller's process, probably extended by a 17th byte - of value zero. + The process ID of the caller's process, possibly extended by a 17th byte + of value 0 or 1. @return On success, the any contains a pointer represented as -- cgit