From ed5640d8b587fbcfed7dd7967f3de04b37a76f26 Mon Sep 17 00:00:00 2001
From: Daniel Baumann This library can operate in two modes, application mode and direct mode.Application Mode
+ In application mode the Java related settings are stored in files.
+ There are currently three files which need to be accessed. They are determined
+ by bootstrap parameters:
The values for these parameters must be file URLs and include the file name, for
+ example:
+ file:///d:/MyApp/javavendors.xml
+ All files are XML files and must have the extension .xml.
+ Modifying the shared settings is currently not supported by the framework. To provide + Java settings for all users one can run OOo and change the settings in the + options dialog. These settings are made persistent in the UNO_JAVA_JFW_USER_DATA. + The file can then be copied into the base installation. + Other users will use automatically these data but can override the settings in + the options dialog. This mechanism may change in the future. +
+If shared Java settings are not supported by an application then it is not
+ necessary to specify the bootstrap parameter UNO_JAVA_JFW_SHARED_DATA
.
+
Setting the class path used by a Java VM should not be necessary. The locations + of Jar files should be known by a class loader. If a jar file depends on another + jar file then it can be referenced in the manifest file of the first jar. However, + a user may add jars to the class path by using this API. If it becomes necessary + to add files to the class path which is to be used by all users then one can use + the bootstrap parameter UNO_JAVA_JFW_CLASSPATH_URLS. The value contains of file URLs + which must be separated by spaces.
+ + +The direct mode is intended for a scenario where no configuration files + are available and a Java VM shall be run. That is, + the files containing the user and shared settings are not specified by the + bootstrap parameters UNO_JAVA_JFW_SHARED_DATA and UNO_JAVA_JFW_USER_DATA. + For example, tools, such as regcomp, may use this framework in a build + environment. Then one would want to use settings which have been specified + by the build environment. The framework would automatically use the + current settings when they change in the environment. +
+ +Here are examples how regcomp could be invoked using bootstrap parameters: +
++ regcomp -env:UNO_JAVA_JFW_JREHOME=file:///d:/j2re1.4.2 + -env:"UNO_JAVA_JFW_CLASSPATH=d:\\solver\\bin\\classes.jar;d:\\solver\\bin\\libreoffice.jar" + -register... +
+If UNO_JAVA_JFW_VENDOR_SETTINGS is not set then a plugin library must be specified. For example:
++ regcomp -env:UNO_JAVA_JFW_JREHOME=file:///d:/j2re1.4.2 + -env:"UNO_JAVA_JFW_CLASSPATH=d:\\solver\\bin\\classes.jar;d:\\solver\\bin\\libreoffice.jar" + -register... +
+Additional parameters for the Java VM can be provided. For every parameter
+ a separate bootstrap parameter must be specified. The names are
+ UNO_JAVA_JFW_PARAMETER_X
, where X is 1,2, .. n. For example:
+ regcomp -env:UNO_JAVA_JFW_PARAMETER_1=-Xdebug + -env:UNO_JAVA_JFW_PARAMETER_2=-Xrunjdwp:transport=dt_socket,server=y,address=8100 + -env:UNO_JAVA_JFW_JREHOME=file:///d:/j2re1.4.2 + -env:"UNO_JAVA_JFW_CLASSPATH=d:\\solver\\bin\\classes.jar;d:\\solver\\bin\\libreoffice.jar" + -register...
++ Here is a complete list of the bootstrap parameter for the direct mode: +
+A note about bootstrap parameters. The implementation of the bootstrap + parameter mechanism interprets the characters '\', '$', '{', '}' as + escape characters. That's why the Windows path contain double back-slashes. + One should also take into account that a console may have also special + escape characters.
+ ++ The default mode is application mode. If at least one bootstrap parameter + for the direct mode is provided then direct mode is used.
+ ++ All settings made by this API are done for the current user if not + mentioned differently.
+*/ + +/** indicates that there must be an environment set up before the Java process + runs. +Therefore, when a Java is selected in OO then the office must be + restarted, so that the changes can take effect.
+ */ +#define JFW_REQUIRE_NEEDRESTART 0x1l + +/** error codes which are returned by functions of this API. + */ +enum javaFrameworkError +{ + JFW_E_NONE, + JFW_E_ERROR, + JFW_E_NO_SELECT, + JFW_E_INVALID_SETTINGS, + JFW_E_NEED_RESTART, + JFW_E_RUNNING_JVM, + JFW_E_JAVA_DISABLED, + JFW_E_NOT_RECOGNIZED, + JFW_E_FAILED_VERSION, + JFW_E_NO_JAVA_FOUND, + JFW_E_VM_CREATION_FAILED, + JFW_E_CONFIGURATION, + JFW_E_DIRECT_MODE +}; + +/** an instance of this struct represents an installation of a Java + Runtime Environment (JRE). + ++ Instances of this struct are created by the plug-in libraries which are used by + this framework (jvmfwk/vendorplugin.h).
+ */ +struct JavaInfo +{ + /** contains the vendor. + +string must be the same as the one obtained from the
+ Java system property java.vendor
.
+
The version string must adhere to the rules
+ about how a version string has to be formed. These rules may
+ be vendor-dependent. Essentially the strings must syntactically
+ equal the Java system property java.version
.
+
For example, it may be necessary to prepare the environment before
+ the runtime is created. That could mean, setting the
+ LD_LIBRARY_PATH
+ when nRequirements
contains the flag
+ JFW_REQUIRE_NEEDRESTART
There is no rule about the format and content of the sequence's + values. The plug-in libraries can put all data, necessary for + starting the java runtime into this sequence.
+ */ + rtl::ByteSequence arVendorData; +}; + +/** compares twoJavaInfo
objects for equality.
+
+ Two JavaInfo
objects are said to be equal if the contained
+ members of the first JavaInfo
are equal to their counterparts
+ in the second JavaInfo
object. The equality of the
+ OUString
members is determined
+ by operator ==
.
+ Similarly the equality of the rtl::ByteSequence
is
+ also determined by a comparison
+ function (see rtl::ByteSequence::operator ==
).
+ Both argument pointers must be valid.
+ @param pInfoA + the first argument. + @param pInfoB + the second argument which is compared with the first. + @return + true - both object represent the same JRE. + false - the objects represent different JREs + */ +JVMFWK_DLLPUBLIC bool jfw_areEqualJavaInfo(JavaInfo const* pInfoA, JavaInfo const* pInfoB); + +/** determines if a Java Virtual Machine is already running. + +As long as the office and the JREs only support one + Virtual Machine per process the Java settings, particularly the + selected Java, are not effective immediately after changing when + a VM has already been running. That is, if a JRE A was used to start + a VM and then a JRE B is selected, then JRE B will only be used + after a restart of the office.
++ By determining if a VM is running, the user can be presented a message, + that the changed setting may not be effective immediately.
+ + @return + true iff a VM is running. +*/ +JVMFWK_DLLPUBLIC bool jfw_isVMRunning(); + +/** detects a suitable JRE and configures the framework to use it. + +Which JREs can be used is determined by the file javavendors.xml, + which contains version requirements.
+
+ JREs can be provided by different vendors.
+ The function obtains information about JRE installations. If none was
+ found then it also uses a list of paths, which have been registered
+ by jfw_addJRELocation
+ to find JREs. Found JREs are examined in the same way.
+ A JRE installation is only selected if it meets the version requirements.
+ Information about the selected JRE are made persistent so that
+ subsequent calls to jfw_getSelectedJRE
returns this
+ information.
+ While determining a proper JRE this function takes into account if a + user requires support for assistive technology tools. If user + need that support they have to set up their system accordingly.
++ If the JAVA_HOME environment variable is set, this function prefers + the JRE which the variable refers to over other JREs. + If JAVA_HOME is not set or does not refer to a suitable JRE, + the PATH environment variable is inspected and the respective JREs + are checked for their suitability next.
+
+ The first JavaInfo
object that is detected by the algorithm
+ as described above is used.
JavaInfo
pointer, representing the selected JRE.
+ The JavaInfo
is for informational purposes only. It is not
+ necessary to call jfw_setSelectedJRE
afterwards.pInfo
can be NULL.
+
+ @return
+ JFW_E_NONE function ran successfully.The function determines dynamically what JREs are available. It uses
+ the plug-in libraries to provide lists of available JavaInfo
+ objects where each object represents a JRE (see vendorplugin.h,
+ getAllJavaInfos). It also uses a list of paths, which have been registered
+ by jfw_addJRELocation
.
+ It is checked if the path still contains a valid JRE and if so the respective
+ JavaInfo
object will be appended to the array unless there is
+ already an equal object.
JavaInfo
pointers.
+
+ @return
+ JFW_E_NONE function ran successfully.If the path belongs to a JRE installation then it returns the
+ respective JavaInfo
object. The function uses the
+ getJavaInfoByPath
function of the plug-ins to obtain the
+ JavaInfo
object. Only if the JRE found at the specified location
+ meets the version requirements as specified in the javavendors.xml file a
+ JavaInfo
object is returned.
+
+ The functions only checks if a JRE exists but does not modify any settings.
+ To make the found JRE the "selected JRE" one has
+ to call jfw_setSelectedJRE
.
JavaInfo
object which represents a JRE found at the
+ location specified by pPath
+
+ @return
+ JFW_E_NONE function ran successfully.The function uses the current settings to start a JVM. The actual + start-up code, however, is provided by the plug-in libraries. The setting + of the "selected Java" contains the information as to what vendor + the respective JRE comes from. In the javavendors.xml there is a mapping of + vendor names to the respective plug-in libraries.
+
+ The function ultimately calls startJavaVirtualMachine
from
+ the plug-in library.
+ The arOptions
+ argument contains start arguments which are passed in JavaVMOption structures
+ to the VM during its creation. These
+ could be things, such as language settings, proxy settings or any other
+ properties which shall be obtainable by
+ java.lang.System.getProperties
. One can also pass options which
+ have a certain meaning to the runtime behaviour such as -ea or -X... However,
+ one must be sure that these options can be interpreted by the VM.
+ The class path cannot be set this way. The class path is internally composed by
+ the paths to archives in a certain directory, which is preconfigured in
+ the internal data store and the respective user setting (see
+ jfw_setUserClassPath
.
+ If a JRE was selected at runtime which was different from the previous
+ setting and that JRE needs a prepared environment, for example an adapted
+ LD_LIBRARY_PATH
environment variable, then the VM will not be
+ created and JFW_E_NEED_RESTART error is returned. If a VM is already running
+ then a JFW_E_RUNNING_JVM is returned.
JavaVM
pointer.
+ @param ppEnv
+ [out] the JNIenv
pointer.
+
+ @return
+ JFW_E_NONE function ran successfully.JAVA_HOME
does not meet the version requirements.
+ */
+JVMFWK_DLLPUBLIC javaFrameworkError jfw_startVM(JavaInfo const* pInfo,
+ std::vectorWhen calling jfw_startVM
then a VM is started from
+ the JRE that is determined by this function.
+ It is not verified if the JRE represented by the JavaInfo
+ argument meets the requirements as specified by the javavendors.xml file.
+ However, usually one obtains the JavaInfo
object from the
+ functions jfw_findAllJREs
or jfw_getJavaInfoByPath
,
+ which do verify the JREs and pass out only JavaInfo
objects
+ which comply with the version requirements.
+ If pInfo
is NULL then the meaning is that no JRE will be
+ selected. jfw_startVM
will then return
+ JFW_E_NO_SELECT
.
JavaInfo
structure, containing data about a
+ JRE. The caller must still free pInfo
.
+
+ @return
+ JFW_E_NONE function ran successfully.If no JRE is currently selected then ppInfo
will contain
+ NULL on return.
+ If the value of the element JFW_E_INVALID_SETTINGS
. This could happen during
+ a product patch. Then new version requirements may be introduced, so that
+ the currently selected JRE may not meet these requirements anymore.
+
In direct mode the function returns information about a JRE that was + set by the bootstrap parameter UNO_JAVA_JFW_JREHOME. +
+ @param ppInfo + [out] on return it contains a pointer to aJavaInfo
object
+ that represents the currently selected JRE. When *ppInfo
is not
+ NULL then the function sets the pointer.
+
+ @return
+ JFW_E_NONE function ran successfully.If bEnabled
is false
then a call
+ to jfw_startVM will result in an error with the errorcode
+ JFW_E_JAVA_DISABLED
That is if the user enabled or disabled the use of Java. +
+ + @return + JFW_E_NONE function ran successfully.The strings must be exactly as they are passed on the command line.
+ For example, one could pass
+ -Xdebug
+ -Xrunjdw:transport=dt_socket,server=y,address=8000
+ in order to enable debugging support.
+
When the VM is started then it is passed the class path. The
+ class path also contains the user class path set by this function.
+ The paths contained in pCP
must be separated with a
+ system dependent path separator.
The function returns an empty string if no user class path is set. +
+ + @param ppCP + [out] contains the user class path on return. + + @return + JFW_E_NONE function ran successfully.When jfw_findAllJREs
is called then the paths added by this
+ function are evaluated. If the location still represents a
+ JRE then a JavaInfo
object is created which is returned along
+ with all other JavaInfo
objects by
+ jfw_findAllJREs
. If the location
+ cannot be recognized then the location string is ignored.
+ A validation if sLocation
points to a JRE is not
+ performed. To do that one has to use jfw_getJavaInfoByPath
.
+
+ Adding a path that is already stored causes no error.
+ + @param sLocation + [in] file URL to a directory which contains a JRE. + + @return + JFW_E_NONE function ran successfully.If a different thread called this function before then the
+ current call is blocked until the other thread has called
+ jfw_unlock()
. The function should be called if one
+ needs an exact snapshot of the current settings. Then the settings
+ are retrieved one by one without risk that the settings may be changed
+ by a different thread. Similarity if one needs to make settings which
+ should become effective at the same time then jfw_lock
+ should be called. That is, jfw_startVM
which uses the
+ settings cannot be called before all settings have be made.
+ The only functions which is not effected by jfw_lock
is
+ jfw_areEqualJavaInfo
.
+ */
+JVMFWK_DLLPUBLIC void jfw_lock();
+
+/** unlocks this API.
+
+
This function is called after jfw_lock
. It allows other
+ threads to use this API concurrently.