Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / July 2006

Tip: Looking for answers? Try searching our database.

Java Classloader/DLL Hell

Thread view: 
wgilreath@gmail.com - 18 Jul 2006 12:46 GMT
Hi all,

A paper "Scalable Programming Languages" by Mike Vanier at
http://www.cs.caltech.edu/~mvanier/hacking/rants/scalable_computer_programming_l
anguages.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 - 18 Jul 2006 17:26 GMT
> Hi all,
>
[quoted text clipped - 21 lines]
> 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@gmail.com - 19 Jul 2006 04:44 GMT
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

> > Hi all,
> >
[quoted text clipped - 38 lines]
> assume the right versions come with the container, but if you bundle them
> you can get conflicts.


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.