Известно что в java.lang.ClassLoader захардкожена проверка на классы, чьё полное имя начинается на "java." Эта проверка похоже призвана запретить загрузку классов из пакаджа java. любым загрузчиком, кроме bootstrap загрузчика (т.к. все остальные загрузчики наследуются от lava.lang.ClassLoader).
У меня возник вопрос, действительно ли никаким честным способом нельзя загрузить классы java.* ещё раз из своего загрузчика? Под честным я понимаю отсутствие предварительных хаков в коде java-core класссов (а то можно и оригинальный java.lang.ClassLoader заменить, и с изменённым запустить JVM).

Так вот, например если поступить таким образом:
- пишем свой класслоадер, который конечно унаследован от от java.lang.ClassLoader. Неважно какой родительский класслоадер укажем при создании инстанса своего загрузчика, ну пусть для определённости это будет bootstrap загрузчик (т.е. укажем null-парента);
- наш класслоадер не будет делегировать загрузку классов родительскому класслоадеру. В действительности механизма, который бы заставил нас делегировать, не существует, есть только рекомендации такого поведения;
- если не использовать нативный код, то мы в любом случае будем вынуждены воспользоваться одним из файнал методов java.lang.ClassLoader.defineClass(...) для того, чтобы создать инстанс типа java.lang.Class из массива байт, полученного из файла .class Любой из доступных нам методов ClassLoader.defineClass(...) приведёт к вызову прайват метода ClassLoader.preDefineClass(...), в котором вставлена проверка на классы java.*, запрещающая их грузить. Но, что мешает написать свой собственный нативный метод defineClass, который будет создавать инстанс java.lang.Class из массива байт аналогично тому, как это делает нативный код, вызывающийся из java.lang.ClassLoader.defineClass(...)?

Сам я ответить на этот вопрос не могу, т.к. не знаю какие именно действия производятся оригинальным нативным кодом для создания класса. Могу предположить две задачи: непосредственное создание инстанса класса из массива байт и "регистрация" этого инстанса в VM. Под "регистрацией" я имею в виду, что может быть о загруженном классе должен знать не только загрузивший его класслоадер, но и ещё какие-то части VM.

Ну вот, я задал вопрос и написал почему я сам не могу ответить на него. Возможно на форуме есть те, кто смогут помочь разобраться:)
Вопрос в любом случае едва ли может принести какую-то практическую пользу, но мне просто интересно выяснить ответ.

>>И основной вопрос - а зачем все это? Может, сформулируете саму проблему и мы попытаемся пойти другим путем?
сформулирую причину подробнее: вопрос возник пока я аккумулировал свои знания о класслоадерах в письменной форме:) Вопрос носит исключительно академический характер и хакать я ничего не собираюсь, т.к. " a true Programmer uses the
Source only for knowledge and defense, never for attack ".

>>В любом случае это получается в хотите хакнуть JVM
Меня как раз интересует, действительно ли указанная проверка в java.lang.ClassLoader.preDefineClass достаточна для того, чтобы исключить возможность повторной загрузки java.* классов, или теоретически возможно загрузить их в своём класслоадере используя доступные в JVM механизмы. Способ, который видится мне, я написал. Но сказать возможен ли он теоритически, или нет - я не могу (тем более я не могу его осуществить, и не спрашиваю как. меня интересует лишь теоритическая возможность).

>>Валя это тебе для чего понадобилось ?
Для интереса, бывает и такое:) Ты меня вероятно знаешь, раз "валя" пишешь. Открой тоже личико, Фатима:ъ

>>соответственно если он не наследует стандартный ClassLoader
написал же что в указанном мысленном эксперименте - наследует

Повторно нельзя загрузить классы из bootstrap. Остальные загружаются сколько угодно раз
если это действительно так, то зачем тогда было вставлять дополнительную проверку на java.* в java.lang.ClassLoader? Эти классы и так заведомо грузятся бутстрапом, и значит если ваше утверждение истинно, дополнительная проверка специально для классов java.* не нужна, но она есть

Коваленко Валентин Повторно нельзя загрузить классы из bootstrap. Остальные загружаются сколько угодно раз
если это действительно так, то зачем тогда было вставлять дополнительную проверку на java.* в java.lang.ClassLoader? Эти классы и так заведомо грузятся бутстрапом, и значит если ваше утверждение истинно, дополнительная проверка специально для классов java.* не нужна, но она есть
хотя нет, этот мой аргумент явно ошибочен. В JVM же ленивая загрузка классов, а потому вполне возможно что какие-то java.* классы окажутся незагруженными после старта JVM, и будуз грузиться позже, при необходимости. Вот на этот случай похоже проверка и вставлена.

Однако почему этой проверки достаточно, я как и прежде пока не понимаю.

justforsqlruотнаследуйся от ClassLoader и перепиши там defineClass
тот который

protected final Class<?> defineClass(String name, byte[] b, int off, int len,
ProtectionDomain protectionDomain)


preDefineClass возвращает protectionDomain возвращай там new ProtectionDomain()

как я уже писал, чтобы повторить его поведение, придётся повторить поведение нативных прайват методов defineClass0(...),defineClass1(...),defineClass2(...)
И снова, как я уже писал - мне неизвестно что именно они делают. Свои предположения я написал в стартовом посте темы (прошу его прочитать внимательно:)) Однако то, что я не знаю что они делают и не могу их посторить, ещё не значит что это принципиально невозможно

>>> Однако почему этой проверки достаточно, я как и прежде пока не понимаю.
>>>>>>а почему нет ?
"вот вам лук, повесьте на дверь и никто не сможет зайти" - но почему никто не сможет?, я хочу именно понять в таком случае принципиальные причины, которые обеспечат невозможность зайти (загрузить класс).