Как загрузить модифицированный суперкласс в Java?

Question

• У меня есть класс А продолжается Б.
• Я создал CustomClassLoader расширяет ClassLoader использовать defineClass(className, byte[], offset, length).
• Я инстанцировал new CustomClassLoader(Thread.currentThread().getContextClassLoader()). Итак, родительский элемент моего CustomClassLoader является ClassLoader из текущего потока.
• Я модифицировал класс B с использованием рамки ASM. Я написал свой модифицированный класс в файле .class и использую декомпилятор, чтобы убедиться, что он работает. И это работает.
• Я добавил измененный класс B в свой CustomClassLoader
• Я установил Thread.currentThread().setContextClassLoader() с помощью своего CustomClassLoader.
• Я загружаю A, используя Class.forName(String, true, the CustomClassLoader).
• Но загруженный класс B, кажется, является оригинальным классом.

Что я не так понял? Если вам нужна дополнительная информация, подробная тема на моем GitHub.

Answer 1

Java classloaders Первый ищет родительский загрузчик классов перед тем, как смотреть в дочерний объект.

Метод loadClass в ClassLoader выполняет эти задачи, в порядке, при вызове загрузить класс:

1. Если уже загружен класс, он возвращает его.
2. В противном случае он делегирует поиск нового класса загрузчику родительского класса.
3. Если загрузчик родительского класса не находит класс, loadClass вызывает метод findClass для поиска и загрузки класса.

(Understanding Extension Class Loading - Oracle)

Если вы хотите изменить этот порядок, необходимо переопределить метод loadClass как хорошо, но есть много предостережений, и это не рекомендуется, если вы не понимаете загрузки классов очень хорошо.

• Более простой вариант - убедиться, что загрузчик родительского класса не может найти исходный класс B.

Answer 2

Есть несколько вещей, чтобы знать:

• Для большинства вещей, занимающейся контекстом загрузчика класса Нити является устаревшим, так как она не имеет никакого влияния. Это больше похоже на конвенцию; установка его оказывает влияние, если есть некоторые другие запросы кода и их использование. Для процесса загрузки стандартного класса он не имеет никакого значения. К сожалению, документация не упоминает об этом и делает его похожим на релевантную вещь. Возможно, он был предназначен иметь больше смысла, когда он был добавлен.
• В качестве pointed out by Erwin Bolwidt при загрузке A через ваш пользовательский загрузчик он делегирует его родительскому загрузчику, возвращая класс A, загруженный родителем.
• Когда разрешает ссылки на класс, JVM всегда будет использовать , определяющий загрузчик реферера. Поэтому, когда ссылка из A на B решена, виртуальная машина будет всегда использовать родительский загрузчик, который определен класс A

Последний пункт означает, что даже если вы измените свой пользовательский загрузчик классов, чтобы искать свои собственные классы первой вместо того, чтобы сначала следовать стандартной модели запроса родителя, она не решает проблему, если у нее нет собственного A, так как тогда она все равно возвращает родительский A, ссылки на которые будут разрешены с использованием родителя. Так как вы призываете defineClass, прежде чем просить A, порядок поиска не имеет значения, так как пользовательский загрузчик имеет уже определенный B, что он возвращается, если кто-нибудь спросил его B ...

Так что вы можете позволить своему обычаю погрузчик также загружает и определяет A. Или вы используете Reflection с переопределением доступа к defineClass в системе ClassLoader перед этим загружает B. Самое чистое решение - реализовать логику модификации класса в качестве Java-агента, который может использовать API-интерфейс Instrumentation для перехвата и изменения определения B сразу после его загрузки.