What does this snippet do?

Thread view:

Ramon F Herrera - 04 Dec 2007 05:15 GMT

This question would be best answered by somebody with a knowledge of
component based programming methodologies, such as COM, CORBA or the
UNO newcomer; as implemented in Java, of course.

This comes from one of the tutorial examples contained in the
OpenOffice SDK.

I discovered that if I remove the code below, the sample program still
works properly, while being run from inside Eclise or NetBeans. I
removed the code and forgot all about it.

Some time later, I realized that the program didn't run standalone,
from the Unix or Windows shell/CLI, or by double click. So, I put the
chunk of code back, and voila! the program works fine now.

I could try reading the OO developer manual and following the code,
but I am sure some expert out there can give a better explanation.

This whole component based approach looks very intriguing, but somehow
counterintuitive, at least to me.

Thanks for sharing your insight...

-Ramon

-----------------------------------------

ClassLoader loader = ClassLoader.getSystemClassLoader();
if (loader instanceof URLClassLoader) {
URLClassLoader cl = (URLClassLoader)loader;
Class sysclass = URLClassLoader.class;
try {
Method method = sysclass.getDeclaredMethod("addURL", new
Class[]{URL.class});
method.setAccessible(true);
method.invoke(cl, new Object[]{new
File(ooBaseDirectory).toURL()});
} catch (Throwable t) {
t.printStackTrace();
throw new IOException("Error, could not add URL to
system classloader");
}
} else {
System.out.println("Error occured, URLClassLoader expected
but " +
loader.getClass() + " received. Could not continue.");
}

Reply to this Message

Owen Jacobson - 04 Dec 2007 05:30 GMT

> This question would be best answered by somebody with a knowledge of
> component based programming methodologies, such as COM, CORBA or the
[quoted text clipped - 43 lines]
> loader.getClass() + " received. Could not continue.");
> }

It adds an extra path to the system classloader's search path in a
particularly heinous way: it reaches into an internal method,
bypassing the "protected" access modifier on URLClassLoader.addURL via
reflection.

I shudder to read such code. Eegh. It betrays a weak understanding
of Java's classloading model; the desired effect would be better
achieved by creating a new URLClassLoader as a child of the system
classloader with the OO path in the new loader's search path.
However, other parts of the application might need to be adjusted to
be "aware" of the custom classloader.

More simply, you should add the OpenOffice java path to the Class-Path
or -classpath as appropriate. Unfortunately, since the OpenOffice
java path is highly system-dependent that's hard to do.

See the documentation of ClassLoader:
<http://java.sun.com/javase/6/docs/api/java/lang/ClassLoader.html>
and URLClassLoader:
<http://java.sun.com/javase/6/docs/api/java/net/URLClassLoader.html>
for details.

-o

Reply to this Message

Ramon F Herrera - 04 Dec 2007 06:13 GMT

Owen:

I looked into that code's origins, and now I realize that I found that
tutorial in the NetBeans site. It seems that it has been pulled off,
as the link is dead now. However, the page is still cached here:

http://tinyurl.com/38ne7e

In the author's discharge, he made an effort to explain his reasoning,
and he concludes: "it's a dirty hack", as you did.

Thanks!

-Ramon

---------
Working with bootstraps.

The OpenOffice.org Java API has its own methods for bootstrapping
OpenOffice.org. By "bootstrapping" OpenOffice.org, we simply mean
"starting up" or "launching" the OpenOffice.org application launcher.
This is done by finding the location of the juh.jar library and
looking for the soffice(.exe) executable in that location, or in one
directory above that location. This requires the juh.jar library to be
put on the CLASSPATH, enabling the application that you create in this
tutorial to find it. However, here we want to ship our own juh.jar
file (and others) with the application. In this case, this approach to
the bootstrapping mechanism doesn't work.

In order to solve this issue, there are two possibilities. First, it
is possible to make sure that Java can find the soffice(.exe)
executable every time. This can be done by putting the directory
containing the executable on the PATH in Windows, or on
LD_LIBRARY_PATH in Mac, Unix, and Linux. This requires action from
potential users and we want to prevent that.

So we choose the second possibility, which involves working with
access modifiers. In the Sun JDK, the system ClassLoader is an
instance of the class URLClassLoader. This class has a private method
called addURL, which is called when Java starts and which will add all
JARs and other resources needed. Using Reflection, we request an
instance of the URLClassLoader, make the addURL method accessible to
us, and add the directory containing the soffice(.exe) executable to
the stack of URLs in the URLClassLoader. It is a dirty hack, but it
works.

But, does it? Messing around with access modifiers of system classes
always is a risky business. The addURL method is declared protected
and there is a reason for this. Besides that, what if someone does not
use the Sun JDK? Or what if Sun decides to deprecate the addURL
method? Well, the Java specification is unclear about all of this, so
other JDKs may not use the URLClassLoader class as system ClassLoader.
For this reason, we have wrapped our code in a "loader instanceof
URLClassLoader" check to make sure nothing will break. This is the
price we have to pay for making our application work without the users
having to do anything for it, except use the Sun JDK.

Reply to this Message

What does this snippet do?

Free Magazines