[OT] Classloader problems

David Leangen dleangen at canada.com
Thu Mar 10 03:22:23 EST 2005

Thank you to all who provided help to me on this off-topic issue.

For the sake of completion, I'd like to follow up on this post[1]. First, a
reply to Broc, who provided me with some useful tips.

> Here's a long shot: Try using a different file separator on the
> mac, i.e. File.separatorChar, which I think was ':' on Mac.
> (unless it now now consider "unix" under OSX...)

I learned that the file separator on the Mac is ":". Strange for thos of us
who are not accustomed to it... On the Mac, making a call to
File.separatorChar returns ":", even though the MacOs uses a *nix-type
shell. Go figure...

In any case, using the file separator is not correct. The Java spec states
that the separator should be '/'. So, a "." does not cut it, either.

As for the leading slash, perhaps is varies according to the Java
implementation. Looking at the Sun code for 1.4.2, if the leading slash is
missing, it simply gets prepended. So, putting it in or leaving it out makes
absolutely no difference.

> Also, remember that the String you pass to a classloader is
> just a "name" of a resource. It is up to the classloader
> implementation to interpret that string as it wishes; it does
> not have to represent a file. So the implementation could be
> doing anything with the sting you give it. The key is to find
> out the actual behavior of the class loader.

Although I searched, I was unable to find the source file for the Mac
implementation. So, all I was able to do was guess at how it was
implemented. This is what I deduced. Corrections welcome where needed. My
terminology may not be quite right, either...

In the Sun implementation (which I used on my Win and Linux machines),
whether a class is loaded using the "new" operator, or loaded dynamically
using reflexion, the class's package is later added to the classloader's
resolver. So, attempting to load a file like I was trying to do, such as
/com/company/SomeClass.xconfig using
Classloader.getResourceAsString(fileName) works without any problems. The
file gets resolved and it is serialized into an input stream.

The Mac does not use the Sun implementation. I have no idea who makes it...
Anyway, it doesn't work the same way. Using the "new" operator does indeed
add the package to the classloader's resolver, but loading it dynamically
through reflexion or Class.forName() does not. Therefore, in order for the
classloader to be able to resolve the xconfig file, SomeClass must have been
loaded with the "new" operator and not with a forName() or other dynamic

So, the only "easy" solution I could find was to always use the "new"
operator. This takes away much of the elegance of what I was trying to do,
so I'm not too pleased... but at least my stuff works on the Mac now.


[1] All too many times, I've come across a post that brings up an issue I'm
dealing with, but don't follow up. To avoid the frustration to those in the
future who may read this post, I'm following up with what I've found.

[2] I didn't try, but perhaps it would also work if
com.company.SomeOtherClass is loaded with the "new" operator...

More information about the support-dpml mailing list