questioner,

Это нужно для изоляции, приоритета и безопасности. Да, на десктопном приложении это не так очевидно. Но вот для апплетов и JEE - очень важно.

Хотя даже для десктопа - bootstrap загрузчик особенный. Там доступны всяческие оптимизации, такие как CDS

questionerдля расширений отдельный лоадер зачем?
А как тогда? Это же барахолка, а не обязательные классы.

questionerну и приоритеты
Класслоадеры по-умолчанию делегируют загрузку родителям.

vimba,

Термин "по-умолчанию" вам не знаком? Объяснить что он обозначает?

questioner А почему именно такая концепция?

Ну, приоритет загрузки же. Мы же хотим Java классы грузить из bootstrap загрузчика, а не загрузчика приложения.

vimbaНет, это очень сильно зависит от целей, которые пытается достичь создатель класслоадера, тут вообще не применимо никакое умолчание, как напишешь так и будет.

Бред сивой кобылы. Есть базовая реализация java.lang.ClassLoader - в которой это поведение уже реализовано. Чтобы его переопределить нужно приложит дополнительные усилия.

vimbaЕсть лишь общие рекомендации еще со времён SUN писать класслоадеры в описанной Вами манере

Что наводит нас на мысль что исходый код java.lang.ClassLoader вы отродясь не видели.

vimba, но цели натаптывания собственного класслоадера могут и расходится с рекомендациями как например в spring-jar-helsing

Какая-то поделка на гитхабе, это, конечно, весомый аргумент.

vimbaили OSGI.

А в OSGi (а не OSGI, как некоторым могло показаться) вообще всё через >|<опу. Особенно весело когда там из-за этой фишки перестаёт работать половина библиотек, использующих, Class.forName().

vimbaДа даже в банальных JEE/WAR большинсво в адекватных сервлет-контейнерах в имплементациях загрузчика классов для веб приложения сначала пытаются резолвить классы из WEB-IN/classes, WEB-INF/lib и только в случае неудачи делигировать загрузку класслоадеру сервлет контейнера, чтобы случайно не подраться с сервером в случае когда серверу и приложению нужны разные версии одной и той же библиотеки.
Мне можно не рассказывать. Я ещё в JBoss 3.x с вопросом разобрался досконально, когда мне пришлось там дружить десяток проектов написанных разными командами. Так вот, в те годы, как вы выражаетесь "адекватных сервлет-контейнеров" не было в принципе. На этот косяк наступили вообще все. Это раз.
JBoss даже добавили флаг, который отключал делегирование родителям, но лучше от этого не становилось, это два.
Ну, и три, что контейнеру всего лишь нужно было держать свои классы в отдельной ветке иерархии, а не в общей для всех модулей. Делегирование поиска родителям никуда не делось.

questionerбуквально сегодня спросили зачем фреимворки используют разные класслоадеры
Это вопрос с подвохом. Фреймверки не используют разные класслоадеры. Контейнеры используют. JEE контейнеры, OSGi контейнеры, самописные контейнеры плагинов. "фреймверки" - это вообще про другое. Почитайте определение и проихождение этого термина.

questionerВот например spring
Spring Framework не использует класслоадеры. Разве что их реализация OSGi.
Только в данном случае Spring Framework это не "какой-то фреймверк", а нарицательное имя для семейства проектов.

questionerСудя по написанному выше - для изоляции. а что от чего изолировать нужно?
Модули нужно изолировать друг от друга, потому что модули могут использовать разные версии одинаковых библиотек.

questionerВопрос звучал так:
Одно и то же, да. Как буд-то без getBean() не обойтись.
Ну, и причина ClassCastException и "зачем фреимворки используют разные класслоадеры", совсем чуточку разные вещи.
Жаль что только про ClassCastException спросили. Там их ещё несколько более экзотических есть, по точно такой же причине.

questionerПроясните, пожалуйста.
Прояснить что?

questioner,

Так на много понятнее.

questionerКакие это конкретно причины?

Вопрос. Причина ClassCast.
Ответ. Разные класслоадеры.
Где тут про фреймверки?

questionerПочему для загрузки бина из контекста может использоваться другой класслоадер в spring?
getBean() это не "загрузка бина из контекста", а получение ссылки на него. А как он туда попал это уже дело десятое.

questionerА как он мог туда попасть загруженный другим класслоадером?
Ну, например, из другого JEE модуля. Например у вас два модуля обмениваются данными. И вот вы нашли что этот обмен, достаточно узкое место. Как его ускорить?
Поместить модули на один сервер. А можно быстрее? Конечно! Убрать сериализацию и заменить прямыми вызовами.
Ну, либо ранее упомянутый OSGi.

questionerобщающиеся через rest или просто сидящие на одной базе
Ну, это как два разрабочика, которые сидят за соседними столами, но общаются исключительно по email.
Если они пересекаются раз в месяц - это нормально. А если плотно работают над общей задачей и общим кодом, то наверное такое общение может стать и узким местом.

questionerКак два варника, живушие в одном контейнере смогут делать прямые вызовы друг друга?
Как из одного метода можно вызвать другой метод внутри одной JVM?

Leonid KudryavtsevБыло нужно, но я не разобрался, как нормальным образом получить ссылку на объект в другом приложение (Tomcat). Методы которые нашел, в одних версиях появлялись, в других исчезали.... В общем, кривость сплошная (((
Так как ClassCastException не является "нормальной" ситуацией, то чего мы вдруг в этой теме озадачились "нормальным" способом передачи ссылки? В EJB есть локальные интерфейсы, которые являются то о чем я писал выше - оптимизацией вызовов между модулями. Через JNDI, я подозреваю, тоже можно получить ссылку на элементы другого модуля при особом желании. На сервлетах - не скажу. А вот EJB сплошь и рядом себя публикуют в JNDI.

scf- загрузки классов из нестандартных источников: динамический classpath, сеть, шифрованные джарники и т.п.

Да, но при этом можно эту проблему решить через URLClassLoader и свой провайдер для URL через SPI для своего протокола.

scf- горячей рекомпиляции классов - когда интерфейс и оригинальный класс находятся в базовом класслоадере, а новый экземпляр класса - в новом

Ну, во-первых не "в базовом". Чтобы не было казусов, нужно чтобы старый и новый загрузчики жили в разных ветках иерархии.
Во-вторых это не "рекомпиляция", а замена на лету.
В-третьих если этот процесс нужен в разработке, то JRebel-у нет равных. А если в продакшне, то ещё попробуй напиши такой код, чтобы утечек в Metaspace не было.

scf- изоляции библиотек и приложений - если нужно загрузить в одну JVM две версии одной и той же библиотеки, без разных класслоадеров не обойтись

Вот это верно.

scf- выгрузки загруженных классов - т.к. класслоадер держит ссылку на экземпляр класса, класс можно выгрузить только вместе с его класслоадером
А это сложно назвать причиной для которой "свои класслоадеры нужны". Это просто уже нюанс в реализации.

questionerscf- горячей рекомпиляции классов - когда интерфейс и оригинальный класс находятся в базовом класслоадере, а новый экземпляр класса - в новом
Этот пункт не понятен.
Смотри Tomcat Parallel Deployment
Тебе нужно обновить приложение. Но у тебя куча клиентов пользуются единственным сервером и выкидывать ты их не хочешь.
Ты деплоишь новую версию war модуля в Tomcat. Она работает в отдельном ClassLoader-е. Все новые сессии Томкат создаёт на новом модуле. Ждешь пока старые сессии заэкспайрятся или разлогинятся, и можешь смело удалять старую версию.

В результате ты на горячую заменил своё приложение.

UsmanHot Swap
Я не использую термин hot swap потому что под ним, в Java, подразумевается исключительно замена тела метода через JPDA.