Object to Jar

[Chetan Parekh]

I want to know given object is loaded from which Jar file. How do I achieve this?

[Peter Chase]

Objects aren't loaded from Jars, classes are.

Assuming you meant classes, there is no general API for this. The system ClassLoader does not retain this information.

You could write a custom ClassLoader to retain the information. Or maybe you could get the system property "java.class.path" and search the Jars with your own code (Jars are Zip archives).

[Ryan Muster]

Check out the getResource function in the Classloader.
From that URL you can determine which Jar is coming from.

[Peter Chase]

Originally posted by Ryan Muster:
Check out the getResource function in the Classloader.
From that URL you can determine which Jar is coming from.

I don't understand what you're suggesting here. Can you give some example code of how this solves the original poster's problem?

[Rob Spoor]

Originally posted by Peter Chase:


I don't understand what you're suggesting here. Can you give some example code of how this solves the original poster's problem?

URL url = String.class.getResource("String.class");
System.out.println(url);

On my machine, that prints "jar:file:/C:/Program%20Files/Java/jre1.6.0_03/lib/rt.jar!/java/lang/String.class", which tells me that the String class is loaded from C:\Program Files\Java\jre1.6.0_03\lib\rt.jar.

[Peter Chase]

OK, I understand what you are saying now. I didn't know one could do that. I suspect that it solves the original poster's problem.

However, your solution is not generally applicable to all ClassLoaders. It only works for ClassLoaders that load classes from a resource whose name is the class name plus ".class". Further, it only works for situations where there is an appropriate type of URL to represent the resource; for Jars, there is one (jar:), but there wouldn't be for all ClassLoaders.

There is no requirement at all for all ClassLoaders to load classes via a resource and a URL. A legal and functional ClassLoader can just override findClass(String). There are perfectly good reasons to do so, and I have written ClassLoaders like this. Your suggestion would not work for such ClassLoaders.

P.S. Does the exact code you posted really work? I would have expected the argument to be "java/lang/String.class", not "String.class".
[ November 16, 2007: Message edited by: Peter Chase ]

[Rob Spoor]

Originally posted by Peter Chase:
OK, I understand what you are saying now. I didn't know one could do that.

...

P.S. Does the exact code you posted really work? I would have expected the argument to be "java/lang/String.class", not "String.class".

Since I'm not using the ClassLoader's getResource method but that of the class itself, I can use a path relative to where the class file itself is located. Therefore, it finds the class file itself.
Neat huh, using a class file to find itself?

However, your solution is not generally applicable to all ClassLoaders. It only works for ClassLoaders that load classes from a resource whose name is the class name plus ".class". Further, it only works for situations where there is an appropriate type of URL to represent the resource; for Jars, there is one (jar , but there wouldn't be for all ClassLoaders.

There is no requirement at all for all ClassLoaders to load classes via a resource and a URL. A legal and functional ClassLoader can just override findClass(String). There are perfectly good reasons to do so, and I have written ClassLoaders like this. Your suggestion would not work for such ClassLoaders.

I am well aware of that, I have only tested this with the default class loader and URLClassLoader (and only after I made my original post here).