问题: 当我拥有一个类X的实例,我怎么在运行的时候实时找出它的类的物理所在? 在我给你答案之前,我必须指出,如果你坚持养成一个好习惯--编程序时总是考虑与硬盘位置无关,那么你的java学习将会进展的很顺利.当你要装载资源的时候,比如一些属性和配置文件,尽可能的使用ResourceBundle.getBundle()而不是使用java.util.File,除非真的是必须这样.这样做不仅有利于你的J2EE应用开发,而且越到后来,你就越会发现,我怎么有那么多东西要装载?这个时候,你就会觉得这个方法确实给你带来了方便.
尽管如此,追寻到class的根源有时候在程序测试和debug的时候会很有用,由于这个想法,我给出了一种很有帮助的方法能够替我们完成这个任务,这些所有都是基于j2se的api的.
/**
* Given a Class object, attempts to find its .class location [returns null
* if no such definition can be found]. Use for testing/debugging only.
*
* @return URL that points to the class definition [null if not found].
*/
public static URL getClassLocation (final Class cls)
{
if (cls == null) throw new IllegalArgumentException ("null input: cls");
URL result = null;
final String clsAsResource = cls.getName ().replace ('.', '/').concat (".class");
final ProtectionDomain pd = cls.getProtectionDomain ();
// java.lang.Class contract does not specify if 'pd' can ever be null;
// it is not the case for Sun's implementations, but guard against null
// just in case:
if (pd != null)
{
final CodeSource cs = pd.getCodeSource ();
// 'cs' can be null depending on the classloader behavior:
if (cs != null) result = cs.getLocation ();
if (result != null)
{
// Convert a code source location into a full class file location
// for some common cases:
if ("file".equals (result.getProtocol ()))
{
try
{
if (result.toExternalForm ().endsWith (".jar") ||
result.toExternalForm ().endsWith (".zip"))
result = new URL ("jar:".concat (result.toExternalForm ())
.concat("!/").concat (clsAsResource));
else if (new File (result.getFile ()).isDirectory ())
result = new URL (result, clsAsResource);
}
catch (MalformedURLException ignore) {}
}
}
}
if (result == null)
{
// Try to find 'cls' definition as a resource; this is not
// document．d to be legal, but Sun's implementations seem to //allow this:
final ClassLoader clsLoader = cls.getClassLoader ();
result = clsLoader != null ?
clsLoader.getResource (clsAsResource) :
ClassLoader.getSystemResource (clsAsResource);
}
return result;
}
你最好通过这个类的ProtectionDomain方法来获得这个类的代码文件来源以及url地址.然而,有一个问题就是, Class.getProtectionDomain()似乎并不会返回一个null值-在api里也似乎是这么说的. 但是Class.getProtectionDomain()并不一定就会返回一个有效的url值,所以我们在后面通过判断result来得知是否有效.
所有的细节都是classloader的动作,我们知道,classloader就是装载和定义我们的class的.通过java.lang.ClassLoader.defineClass()—5个参数,而且ProtectionDomain参数不能为空,我们可以建立需要的类以及相关受保护的区域.
一般来讲, java.net.URLClassLoader以及相关的扩展一般都会遵循这个规则,但是并非所有自定义的classloader都会保证自动实现它.
如果第一步失败了,你可以试试通过getResource()来获得.class结尾的文件的位置.Java规范里面并没有详细说明这样作是否允许:因为,任何代码都能通过URLS读取整个类的定义,是一个潜在的安全漏洞.有一些jvm已经禁止通过getResource()来装载.class文件.然而,sun的jdk却是通过这个途径来装载类的,这似乎传递了某些合法的信息.
最后,千万不要忘记,不要去寻找任何不存在的东西,一个java.lang.Class类是不需要真正存在一个.class文件的.一个明显的例子就是动态代理类:它的字节码定义是在运行的时候合成的. 对于它,getClassLocation()将会返回null. 将来,j2ee里面将更多的依靠这种运行时构造的方法.因为这些原因,还有就是虚拟机各自都不同,我提供的这种方法你最好只是用来做测试和debug.
