Overview
Contents
Players
Layers
Examples
Configuration
InFAQ
Changes
Licence
Back to Goodies
|
Configuring JNIPort
JNIPort is controlled by settings objects. Each JVM object, and the Java runtime that
it manages, is configured from an instance of class JVMSettings .
Each settings object is made up of a number (up to six in the current version of JNIPort) of
subsettings objects, each configuring one aspect of the system.
Settings objects are just normal, albeit rather dumb, Smalltalk objects. You can create them
programmatically if you wish. However they also know how to save/restore themselves in the Windows
registry.
The JVMSettings class itself maintains a special instance, the
template that is cloned whenever a new instance is created. The template is a
“published aspect” of the class. The point is that most settings objects you use
will be very similar, but will also be specific to your installation. Using a template means
that you can change the defaults for new settings objects to suit yourself without
having to modify JNIPort code, or use subclassing.
The class also contains a list of pre-defined settings. Each has a name, and one way of
starting a new JVM is to ask for one that has been configured from a named pre-defined
settings object. That is how the Status Monitor does it.
The list is also a “published aspect” of the class.
You can edit both the template and the pre-defined list from the Status Monitor. Currently
it just uses a Published Aspect Inspector'; though I plan to add a custom editor in some
later version. You can also save/restore the pre-defined settings in the registry from the
Status Monitor.
The walkthrough section gives a couple of simple examples of
configuring JNIPort.
The rest of this section gives a quick overview of each of the subsettings. More information
can be gleaned from the code for the corresponding subclasses of
JVMSubSettings .
Of the six sub-settings, two are fundamental to JNIPort, two are optional, one is trivial,
and one is still experimental.
They are:
#runtimeSettings
These hold the settings that are passed to the Java runtime. It mostly is just a
list of Strings. Each string corresponding to the parameters that you would pass
on the command line to the java.exe program. See the documentation
for your Java runtime for what parameters it understands. Two special cases are
also exposed as editable aspects, the #classpath
and #libpath .
#jniPortSettings
These configure the basics of JNIPort.
The choice of which JVM.DLL to use is set by #jniLibraryClass ,
with possible tweaking from #jniLibraryJVMType and
#jniLibraryVersion . For instance, setting these to
(respectively) JNILibraryForSunJ2SDK ,
'server' , and
'1.4.0' will force JNIPort to try to use the server
JVM from the 1.4.0 release of Sun's J2SDK. Leaving the version or JVMtype nil
allows JNIPort to pick up the defaults for that vendor.
You can also set the JVM.DLL explicitly by giving the filename, in which case all the
above settings are ignored.
The #jvmClass sets the class used for the JVM object
itself. You can choose between one that supports callbacks
and one that does not. If the 'CU Java Callbacks' package is not installed then you
will not be given a choice.
The #watcherClasses configures a possible list of
watchers. These are objects that “watch” the JVM object and
take certain actions in response to specific events. Currently the only use of this
is that if you have a JVMGhostClassMaker or a
JVMLazyGhostClassMaker on the list, then it will
make ghost classes for each new Java class that JNIPort discovers. (NB: it is
likely that this setting will go away in the future to be replaced with a simpler
choice between different ghost class implementations or none.)
The remaining settings configure whether JNIPort will use the JVM's debugging hooks
to monitor what it's doing. Normally it is unsafe to use these unless you are also
using the JNI Helper library.
#wrapperGenerationSettings
This sub-setting is optional and will only be present if the 'CU Java Wrapper Generation'
package is installed. It sets what members of a Java class will have wrapper methods
generated for them by default. The most important effect of this is that it sets the
defaults for the Wrapper Wizard.
#ghostClassSettings
This sub-setting is optional and will only be present if the 'CU Java Ghost Classes'
package is installed. It is similar to (though not the same as) the
#wrapperGenerationSettings . Since ghost class generation
is automatic, these settings will affect all classes that do not have code to override
the defaults (there are no such classes in this version of JNIPort).
Note that these settings only control how ghost classes are used, not whether
they are used at all. That is set as part of the #jniPortSettings
settings, above. (Which is not, in fact, at all logical, so I may change it in a future
version.)
You probably won't need to change any of these settings from their defaults, though you
are welcome to do so should you wish.
#statusMonitorSettings
This sub-setting is pretty trivial, and will only be present if the JVM Status Monitor
tool is installed. The settings are only used by that tool, not by JNIPort itself.
The #javadocPath can be set to a ;-separated list of
directories that are the roots of JavaDoc file hierarchies. The browse JavaDoc option of
the classes page uses this (plus its own global 'JavaDoc path' setting) to look for
JavaDocs when you use the F12/browse-definition option.
The #defaultSampleSize and
#defaultUpdateInterval set the inital values for the corresponding
options when a new JVM instance is started.
#supplementaryClassloaders
This sub-setting is used to configure the initial set of supplementary classloaders,
if any, which will be created when a JVM is started. The feature is still experimental;
I'll document it better once I'm sure it is stable, until then see the class comment on
SupplementaryClassloader for some explanation.
|