## Metagnostic home
| # JNIPort for Dolphin Smalltalk
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.

Copyright © Chris Uppal, 2003-2005

Java, JNI (probably), JVM (possibly), and God knows what else, are trademarks of Sun Microsystems, Inc.