To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=81445
------- Additional comments from [EMAIL PROTECTED] Wed Sep 26 09:55:44 +0000
2007 -------
@sb, re CLASSPATH: following your argument neither CLASSPATH nor JNI is
available for the JVM (e.g. you won't find them in the "Java Language
Specification", Third Edition) and as such OOo is not supposed to apply/use
them.
;)
Seriously, CLASSPATH is a runtime aspect (like JNI), not part of the Java
language definition, which mandates the implementation of the JVM.
Looking at Sun's Java 6 distribution, you will find that all executables
distributed with Java, that deal with resolution of classes honor CLASSPATH and
optionally allow for overriding it! The (Java supplied) system (application)
class loader exploits this important piece of environment information.
C.f.
apt.exe
java-rmi.exe
java.exe
javac.exe
javadoc.exe
javah.exe
javap.exe
jdb.exe
jrunscript.exe
rmic.exe
schemagen.exe
serialver.exe
wsgen.exe
Or with other words: practically all of the Sun supplied Java runtime
executables honor CLASSPATH. CLASSPATH serves the same role for the Java runtime
environment as does PATH for operating systems.
Hence, if CLASSPATH is set, then I would expect any application to honor it
(like it honors the PATH environment variable) unless it was explicitly ruled
out (e.g. for security considerations like with applets or jnlp). Only, if the
user explicitly overrides the CLASSPATH setting via a command line switch, would
that change be honored. (The user would be free, however, to supply the current
CLASSPATH setting in the command line as well.)
Your JNI example demonstrates that it is possible to invoke the JVM and *not*
supplying any CLASSPATH value. As a result no classes could be found by this JVM
instance' system class loader that are referred to by the CLASSPATH environment
variable.
So, the CLASSPATH environment variable's value should be passed on, such that
Java programs dispatched by OOo can depend on finding systemwide deployed Java
classes [because they got explicitly listed in CLASSPATH environment variable].
---
P.S.: One very popular Java textbook (Bruce Eckel's "Thinking in Java", 4th ed.)
states on p. 214: "The Java interpreter proceeds as follows. First, it finds the
evnrionment variable CLASSPATH (set via the operating system, and sometimes by
the installation program that installs Java or a Java-based tool on your
machine). ...cut... That's where it looks for the .class file with the name
corresponding to the class you're trying to create. (It also searches some
standard directories relative to where the Java interpreter resides." He then
goes on and gives some practical example in which CLASSPATH gets changed
pointing out to the effects for java.exe and javac.exe. He also points out that
it is mandatory for his examples to run, that the user sets the CLASSPATH to his
base directory.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
