Category: Java/.NET Runtime
I have to use a module that wants to load the JVM itself. Can I still use your product?
Possibly. We have done everything we could to make sure that our runtime can coexist peacefully with other modules, but that's not necessarily also true for the other modules. It definitely depends on whether you have some degree of influence over the JVM configuration because you'll be very unhappy if you can't add your own classes to the configured classpath. The following scenario is very common:
Before you discovered Codemesh integration products, your infrastructure group wrote a lof of JNI integration code by hand. Eventually, you want to retire all of it and replace it with code using generated proxy classes, but right now you still have to use the old module and you're just adding new functionality based on Codemesh products.
In such a scenario, you can hopefully influence the classpath and other JVM initialization arguments in the legacy module. As Codemesh is not in charge of JVM loading, all JVM-related configuration settings of the Codemesh runtime will be discarded (after all the JVM has already been initialized when the Codemesh runtime initializes).
If you can adjust the JVM initialization arguments of the other module, in all likelihood the Codemesh runtime can coexist peacefully with the module. We can't guarantee it though: the other module might be doing things that make it impossible for the runtime framework to initialize properly. Problematic legacy module activities include:
- installation of a security manager that does not grant privileges required by the Codemesh runtime framework.
- installation of a context classloader that clashes with Codemesh's requirements.
On the Codemesh side, the IJvmLoader::Load() method has an optional bool argument that signals whether an already loaded JVM is acceptable to your application (the default value is true). You might want to explicitly pass true to this call to make the intent totally clear.
There is one more thing to be aware of: most JVMs we have tested with have a problem with detecting preloaded JVMs of a different manufacturer or even of a different version. Please configure the Codemesh JvmPath to be identical to the JVM path used by the other module.