我正在研究类路径的动态修改.我找到了一个可以正常工作的解决方案,但它使用显式调用addURL()来实现.(大概是在启动时)
但是,如果默认的类加载器似乎无法找到它,我想在运行时拦截类加载过程以找到类.我试图将ClassLoader子类化,因此它只是委托findClass()和loadClass()默认,并打印出一个调试行告诉我这些方法已被调用,但是当我的类通过隐式类加载使用依赖类时,它们似乎永远不会被调用,例如
// regular object instantiation with 'new'
BrowserLauncher launcher;
launcher = new BrowserLauncher();
// static methods
Foobar.doSomethingOrOther();
// Class.forName()
Class cl = Class.forName("foo.bar.baz");
// reflection on a Class object obtained statically
Class<Foobar> cl = Foobar.class;
// do something with cl, like call static methods or newInstance()
在这些情况下,类加载如何工作？(相对于显式调用Classloader.loadClass()的简单情况)
这是我在下面的自定义类加载器的尝试.如果我使用带有参数列表的DynClassLoader0.main(){"some.package.SomeClass", "foo", "bar", "baz"},并且some.package.SomeClass引用外部.jar文件中的其他类,使用上面列出的方法之一,为什么我的DynClassLoader0的findClass()和loadClass不是( )被叫？loadClass被调用的唯一时间是在下面的main()函数中对loadClass的显式调用.
package com.example.test.classloader;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
public class DynClassLoader0 extends ClassLoader {
public DynClassLoader0()
{
super();
}
public DynClassLoader0(ClassLoader parent)
{
super(parent);
}
public void runMain(String classname, String[] args) throws ClassNotFoundException, SecurityException, NoSuchMethodException, IllegalArgumentException, IllegalAccessException, InvocationTargetException
{
// [***] here we explicitly use our classloader.
Class<?> cl = loadClass(classname);
Method main = cl.getMethod("main", String[].class);
main.invoke(null, new Object[] {args});
}
@Override protected Class<?> findClass(String name) throws ClassNotFoundException
{
System.out.println("findClass("+name+")");
return super.findClass(name);
}
@Override public Class<?> loadClass(String name) throws ClassNotFoundException
{
System.out.println("loadClass("+name+")");
return super.loadClass(name);
}
static public void main(String[] args)
{
// classname, then args
if (args.length >= 1)
{
String[] classArgs = new String[args.length-1];
System.arraycopy(args, 1, classArgs, 0, args.length-1);
ClassLoader currentThreadClassLoader
= Thread.currentThread().getContextClassLoader();
DynClassLoader0 classLoader = new DynClassLoader0(currentThreadClassLoader);
// Replace the thread classloader - assumes
// you have permissions to do so
Thread.currentThread().setContextClassLoader(classLoader);
try {
classLoader.runMain(args[0], classArgs);
}
catch (Exception e) {
e.printStackTrace();
}
}
else
{
System.out.println("usage: DynClassLoader {classname} [arg0] [arg1] ...");
}
}
}
编辑:我已经查看了这些问题:
编辑:我认为kdgregory在下面说的是正确的,一旦我明确地使用我的类加载器(参见代码中的行[***]作为注释),从该类执行的所有代码将导致来自同一类加载器的隐式类加载.然而,除了在最外层的显式调用期间,我的DynClassLoader0.loadClass()永远不会被调用.
类加载器创建的对象的方法和构造函数可以引用其他类。为了确定引用的类，Java 虚拟机调用最初创建该类的类加载器的 loadClass 方法。
换句话说，一旦加载一个类，该类就会尝试通过加载它的类加载器加载其他类。在普通的 Java 应用程序中，这是系统类加载器，它代表传递给 JVM 的类路径，或者是引导类加载器，用于加载 JVM 运行时。
根据您的需要，有一个Class.forName()的变体，它将类加载器作为参数。如果您使用它来加载特定的类，那么该类中的引用应该使用指定的类加载器。
编辑：我开始追踪你的例子，但决定给出我自己的例子会更容易。如果您要编写自己的类加载器，我建议从现有的URLClassLoader开始，因为它处理很多幕后的事情。
因此，MyClassLoader采用单个 JAR 文件/目录并单独加载该目录的类。我重写了加载类时调用的三个方法，并简单地记录它们的调用（使用 System.err，因为它不缓冲输出，与 System.out 不同）。
我的示例使用了我当前正在开发的一个库；这很方便，但是您可以选择任何您想要的库，只要它不在您的 classpath 中即可。
main() 方法通过 MyLoader 加载一个类。然后我调用该类上的一个方法，以一种我知道会抛出异常的方式，该异常也是库的一部分。请注意，我通过反射调用该方法：由于该库不在我的 Eclipse 类路径上，因此我无法使用显式引用来编译它。
当我运行这个程序时（在适用于 Linux 的 Sun JDK 1.5 下），我看到有很多对 loadClass() 的调用，无论是对于我的库中的类还是对于类路径上的类。这是预期的：ParseUtil 类引用了许多其他类，并将使用 MyLoader（即它的类加载器）来加载它们。对于那些 MyLoader 在本地找不到的类，它会向上委托加载器树。
抛出异常，当我打印出它的类加载器时，我发现它与我创建的 MyLoader 实例相同。我还打印出了 Exception.class 的加载器，它是 null —— Class.getClassLoader()的 JavaDoc说它指示引导类加载器。
import java.io.File;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.net.URL;
import java.net.URLClassLoader;
public class ClassLoaderExample
{
private static class MyClassLoader
extends URLClassLoader
{
public MyClassLoader(String path)
throws Exception
{
super(new URL[] { new File(path).toURL() });
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException
{
System.err.println("findClass(" + name + ")");
return super.findClass(name);
}
@Override
protected synchronized Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
System.err.println("loadClass(" + name + "," + resolve + ")");
return super.loadClass(name, resolve);
}
@Override
public Class<?> loadClass(String name) throws ClassNotFoundException
{
System.err.println("loadClass(" + name + ")");
return super.loadClass(name);
}
}
public static void main(String[] argv)
throws Exception
{
ClassLoader myLoader = new MyClassLoader("/home/kgregory/Workspace/PracticalXml-1.1/target/classes/");
System.out.println("myLoader = " + myLoader);
Class<?> parseUtilKlass = myLoader.loadClass("net.sf.practicalxml.ParseUtil");
Method parseMethod = parseUtilKlass.getDeclaredMethod("parse", String.class);
try
{
parseMethod.invoke(null, "not at all valid XML");
}
catch (InvocationTargetException e)
{
Throwable ee = e.getCause();
System.out.println("exception:" + ee);
System.out.println("exception loader = " + ee.getClass().getClassLoader());
System.out.println("Exception.class loader = " + Exception.class.getClassLoader());
}
}
}
根据今天的评论编辑#2。
类加载器应该在尝试自己完成请求之前将请求委托给其父级（这在 ClassLoader JavaDoc 中）。这种做法有几个好处，最重要的是您不会无意中加载同一类的不兼容实例。
J2EE 类加载器修改了此模型：用于加载 WAR 的类加载器将尝试在包含 EAR 的加载器之前解析类，而 EAR 又尝试在容器的类加载器之前解析类。这里的目标是隔离：如果 WAR 及其 EAR 都包含相同的库，则可能是因为两者需要不同的版本（或者它们的构建过程很草率）。即使在 J2EE 情况下，我也相信容器类加载器以标准方式进行委托。
| 归档时间： |
|
| 查看次数： |
3132 次 |
| 最近记录： |