If the VM is not already instantiated, it will be now.
If the processID is a normal 16-byte ID, the returned
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, 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
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, an empty
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
java.lang.Thread.getContextClassLoader ) will automatically
be set to a meaningful value.
If the instantiation of the Java Virtual Machine was successfull then
the returned any contains a long value on a 32 bit platform and a hyper
value on a 64 bit platform. The values can be cast to a JavaVM pointer.
If the JVM could not be created for whatever reason then a void any
will be returned.