Tuesday, February 08, 2005

Another way to look up the location of a class file

I wrote in looking up the location of a class file with this suggestion:

new File(clazz.getProtectionDomain().getCodeSource()
        .getLocation().toURI().normalize())

But this failed for me while looking up SignatureFile: the protection domain for this class turned up with no associated code source. I'm not sure if it is related, but the class appears in rt.jar and tools.jar and as a package-scope inner class in JarSigner.

In particular, I'm unable to compile the constructor call, new SignatureFile(Manifest, String) (I'm rolling my own programmatic jar signer).

As is often the case, it turns out there's another way:

new File(clazz.getResource(
        "/" + clazz.getName().replace(".", "/") + ".class").toURI());

With interesting results:

jar:file:/C:/jdk1.5.0_01/jre/lib/rt.jar!/sun/tools/jar/SignatureFile.class

Now I can see which class definition is pulled in. On to figure out why my constructor call does not compile.

UPDATE: Talk about bit in the ass. Here is the full signature with packages for the constructor I am interested in according to SignatureFile.class.getDeclaredConstructors():

public sun.tools.jar.SignatureFile(sun.tools.jar.Manifest,
        java.lang.String) throws sun.tools.jar.JarException

Am I using sun.tools.jar.Manifest? No! I am using the more sane java.util.jar.Manifest class. Oops. And they are not replaceable for each other. Time to rethink.

No comments: