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.