1 Project Description |
For each platform (Windows or UNIX) S is composed of two subsets. The first is the set of values that are unique to that platform. The second is the set of values common to both platforms.
Lets call the unique sets Sw and Su, for Windows and UNIX respectivly.
Lets call the common set Sc.
On Windows S is the UNION of Sw and Sc. On UNIX S is the UNION of Su and Sc.
The problem is that at this time the proper contents of set Sc are undefined. Additionally, the proper contents of both Sw and Su are not well defined.
It is a goal of this project to define the current contents of Su, Sw and Sc.
It is a goal of this project to insure that, as new startup options
are needed, it will be simple to add them such that the proper contents
of Sw, Su and Sc are maintanted.
It is a goal of this project that any plugin developer wishing
to aquire the set of startup options for a particular platform be able to
do so with a single, consistent and cross-platform interface.
It is possible that, in the future, the method of staring the
VM on UNIX will change from exec'ing a custom program to exec'ing the "java"
command. Any solution will need to support this possibility.
2 Technical Description |
Some "switches" convey information mearly by their being present. For example: -verbose
Some "switches" constitute a name/value pair. For example: -DtrustProxy=true where "trustProxy" is the name and "true" is the value. Another example of this type: -Xverify:remote where "verify" is the name and "remote" is the value.
A switch shall be considered a member of the set Sc if:
1) It is of the first type and is specified on both Windows and UNIX
2) It is of the second type and differs only in the value, between its Windows and UNIX specification.
Based on above, the members of the set are defined as:
Sc:
-DtrustProxy=true | On UNIX/Windows: The switch is set, as is, unconditionally. |
-Xverify:remote | On UNIX/Windows: The switch is set, as is, unconditionally. |
-Djava.protocol.handler.pkgs=sun.plugin.net.protocol | On UNIX/Windows: The properties file/registry is checked for
user supplied definition of this switch and the supplied value is appened
with "|sun.plugin.net.protocol". If the user does not specifiy the
switch then it is passed as shown. |
-Xbootclasspath/a:VALUE | On UNIX: The value is set to: %1/lib/javaplugin.jar:%1/lib/javaplugin_l10n.jar:%1/libjsse.jar:%1/lib/jce.jar:%1/lib/sunrsasign.jar: where %1 is set to the path where Java is installed. The filename of the first jar file is conditionalized to account for the debug and non-debug builds (ie. an _g is added to the filename: javaplugin_g.jar). On Windows: The value is set to: All the files that end in ".jar" that can be found in the "lib" subdirectory below the directory where Java is installed (as determined by a registery key). |
-Djavaplugin.nodotversion=VALUE | On UNIX/Windows: The value is set to the no-dot representation of
the version number of the JRE. The value is aquired from a header
file as a CPP define. |
-Djavaplugin.version=VALUE | On UNIX/Windows: The value is set to the version number of the JRE.
The value is aquired from a header file as a CPP define. |
-Djavaplugin.user.profile=VALUE | On UNIX/Windows: The value is set only if the environment variable,
USER_JPI_PROFILE is set. The value is then set to same value as the
environment variable. |
-Djava.class.path=VALUE |
On UNIX: The name and value are set only if the
user specifies either the -cp or the -classpath switch via the Control Panel. If either of these switches are present then their value becomes the value for this switch. If no value is given, this switches value is set to ".". On Windows: The same as on UNIX only if not value is given for this switches value is not defaulted to "." |
Sw:
-XmxVALUEm | The algorithm currently implement in the code makes no sense and
does match the comments supplied. At the end the value will either
be 64 or 96. |
-Djavaplugin.maxHeapSize=VALUEm | The value is set using the algorithm for the above switch. |
-Dapplication.home=VALUE | The value is set to the installation path of Java that is stored
in the registry. |
-Xdebug | The switch is set if a value in the registry indicates that the
plugin should be run in debug mode. |
-Xnoagent | The switch is set if a value in the registry indicates that the
plugin should be run in debug mode. |
-Xrunjdwp:transport=dt_shem,address=VALUE1VALUE2,server=y,suspend=n | The switch is set if a value in the registry indicates that the
plugin should be run in debug mode. |
Su:
-Dmozilla.workaround=true | The value is set only if the environment variable MOZILLA_WORKAROUND
is set. Currently, this is only done in the navig5 codebase. |
-Djavaplugin.lib=VALUE |
The value is set to: %1/lib/%2/libjavaplugin_jni.so
where %1 is set to the path where Java is installed and %2 is set to the architecture specific subdirectory. The value is also conditionalized to account for the debug and non-debug builds (ie. an _g is added to the filename: libjavaplugin_jni_g.so). |
The ControlPanel provides the user of the Plugin the ability to specify additional "switches". On Windows, this information gets stored in the Registry. On UNIX it is stored in the properties file in the users home directory. These additional "switches" can alter the contents of set S for each platform.
In general, any "switch" the user specifies via the ControlPanel is added to the Contents of set S verbatium, with the following exceptions:
On Windows:
These "switches" are not added to the set:
-green
-native
-client
-server
-classic
-hotspot
-Xoldjava
These "switches" are replaced by a switch of the same name prepended with
a -X (assuming they have a value, otherwise they are removed):
-ss
-oss
-ms
-mx
These "switches" are passed on only if they have a value:
-Xss
-Xoss
These switches are passed on, but their presents indicates the need for
a console window.
-verbose
-Xprof
On UNIX:
These "switches" are not added to the set:
-help
-h
-?
-checksource
-cs
-noasyncgc
-classic
-client
-server
-native
-hotspot
-green
-Xoldjava
These "switches" are converted into differnt "switches":
-verbosegc -> verbose:gc
-trace -> -Xt
-noclassgc -> -Xnoclassgc
-verify -> -Xverify:all
-verifyremote -> -Xverify:remote
-noverify -> -Xverify:none
-ss -> -Xss
-oss -> -Xoss
-ms -> -Xms
-mx -> -Xmx
All this information and logic will be encapsulated inside a single
class, call "VMOptions". The source code for this class will be located
in the workspace at:
ext/plugin/src/share/VMOptions
ext/plugin/src/win32/VMOptions
ext/plugin/src/solaris/VMOptions
The build system will be responsible for taking the source code
located in these areas and producing a static library (platform specific)
that exports the interfaces (platform independent) needed to aquire the
set of startup options.
Under ".../share/VMOptions" will be the header file that declares
the class as well as the header file that declares the functions exported
from the static library. Also, this directory will contain one or
more cpp files that contain the implementation of members of the class that
are not platform specific. Such as the function which determins the
contents of set Sc.
Under ".../win32/VMOptions" and "../solaris/VMOptions" will be
the cpp files that contain the implementation of member functions that are
platform specific, such as the function which determins the contents of
the sets Sw and Su.
3 Marketing |
4 Management and Planning |
|
Complete | Started | Not Started | Difficulties | Trouble |
Appendices (as needed, suggestions below) |
|
Revision History |
|