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.
Если они пересекаются раз в месяц - это нормально. А если плотно работают над общей задачей и общим кодом, то наверное такое общение может стать и узким местом.