Java Classloader/DLL Hell

[wgilreath]

Hi all,

A paper "Scalable Programming Languages" by Mike Vanier at
http://www.cs.caltech.edu/~mvanier/hacking/rants/scalable_computer_programming_languages.html

makes an assertion about the Java Classloader mechanism as "On the
other hand, my colleague Donnie Pinkston, who has forgotten more about
Java than I'll ever know, has pointed out that it's very easy to get
into classloader hell for projects that define their own classloaders
(which apparently is often necessary), so it's not all a bed of roses."

I've seen custom classloaders (but never created one...so I find fault
with the "often necessary"), and in fact I e-mailed the author, yet
Vanier seems to think you might use a library with a custom classloader
(but I'd think you'd know if you're using a classloader to load classes
from a URL or ZIP file) and get caught in "DLL Hell" but that seems a
weak rationalization. I just haven't seen Java "DLL hell" like I did
with C++.

I'm puzzled, I've not heard much antipathy or hostility about the Java
class loading mechanism creating a Java "DLL Hell" like C++. I think
the author is taking some second-hand mis-information, but in a
discussion with a colleague, I couldn't convince otherwise. I find
dis-information a travesty, so trying to clear this point. Any
thoughts, experiences?

Thanks for your thoughts!

Will Gilreath

 

[Mike Schilling]

Hi all,

A paper "Scalable Programming Languages" by Mike Vanier at
http://www.cs.caltech.edu/~mvanier/hacking/rants/scalable_computer_programming_languages.html

makes an assertion about the Java Classloader mechanism as "On the
other hand, my colleague Donnie Pinkston, who has forgotten more about
Java than I'll ever know, has pointed out that it's very easy to get
into classloader hell for projects that define their own classloaders
(which apparently is often necessary), so it's not all a bed of roses."

I've seen custom classloaders (but never created one...so I find fault
with the "often necessary"), and in fact I e-mailed the author, yet
Vanier seems to think you might use a library with a custom classloader
(but I'd think you'd know if you're using a classloader to load classes
from a URL or ZIP file) and get caught in "DLL Hell" but that seems a
weak rationalization. I just haven't seen Java "DLL hell" like I did
with C++.

I'm puzzled, I've not heard much antipathy or hostility about the Java
class loading mechanism creating a Java "DLL Hell" like C++. I think
the author is taking some second-hand mis-information, but in a
discussion with a colleague, I couldn't convince otherwise. I find
dis-information a travesty, so trying to clear this point. Any
thoughts, experiences?

Even write Java code that runs inside a container like Tomcat? The
container of necessity creates a tree of classloaders to isolate the
different applications' code from each other, while allowing them to share
basic infrastructure. A more complex container like WebSphere makes this
more complicated, since an enterprise archive (.ear file) has a more complex
structure than a simple web archive (.war file), so there you have a tree of
classloaders *within* each application. These aren't cutom classloaders in
the sense that an application optionally creates them; they're part of the
container.

And this does lead to DLL hell, when, for instance, one version of Xalan
comes with the container, but your application bundles a different version
of Xalan, or, worse still, a different version of the org.w3c DOM
interfaces. Likewise for Java mail, Java activation, etc etc. You can't
assume the right versions come with the container, but if you bundle them
you can get conflicts.

 

[wgilreath]

Hello Mike:

Very interesting...as Johnny Carson might have said "I did not know
that!" I can see how different varieties of a class loader could create
DLL Hell in Java.

Thanks for your input!

Will Gilreath