Недавно мне было предложено спросить о порядке, в котором вызываются загрузчики классов при загрузке класса.
К сожалению, мне никогда не приходилось писать свой собственный загрузчик классов, поэтому в то время было незнакомо с тонкостями загрузки классов.
Это заставило меня задаться вопросом, зачем им писать свой собственный загрузчик классов.
Итак, мой вопрос: С какими сценариями сталкиваются люди, которым требуется писать собственные загрузчики классов?
В настоящее время я работаю над чрезвычайно большим приложением, которое очень модульно, т.е. состоит из буквально сотен JAR файлов. Это означало, что строка classpath стала огромной, вызвав всевозможные проблемы во всех местах, из-за неспособности различных средств разработки справиться с строкой класса 5KB. Это было решено путем написания пользовательского загрузчика классов, который читает свой путь класса из файла.
Типичная причина заключается в том, что ваше приложение размещает другие приложения, которые используют одни и те же библиотеки в разных версиях в той же среде выполнения (например, Tomcat). Поэтому вы должны убедиться, что ваш загрузчик классов может предоставлять разные версии одного и того же класса для каждого из этих приложений.
ИЗМЕНИТЬ
Чтобы прояснить это немного (см. путаницу в комментариях): Когда сказано "ваш загрузчик классов", я упоминаю "реализацию java.lang.ClassLoader", а не экземпляр такого класса. На самом деле это ваш classloader s в обоих значениях: люди Tomcat реализовали разные классы ClassLoader и имеют еще больше экземпляров во время выполнения... подробности см. В соответствующие документы.
Скука и желание мучить моих коллег, когда они должны были поддерживать мой код.:)
В некоторых местах на самом деле хранятся классы в базе данных (ну, как правило, там были места, не уверены, что их больше нет) и используйте загрузчик классов, чтобы получить классы из базы данных во время выполнения.
Мне пришлось реализовать ClassLoader один раз, когда я хотел загрузить классы в .jar файлы из файла .jar(это было несколько лет назад, я уверен, что теперь есть инструменты, которые могут это сделать для вас), т.е. вы будете помещать файлы зависимостей .jar в один .jar файл.
Но, что единственный раз, когда я пишу собственный ClassLoader, это довольно редкая вещь.
Посмотрите на question.
Я столкнулся с article, в котором говорится о том, почему (очень кратко) OSGI использует пользовательский загрузчик классов.
У нас была структура приложения, на которой были основаны приложения, которые были "статически связаны". Это означало, что вам нужно было иметь экземпляр jvm для каждого приложения, которое вы хотели запустить, что было не только плохо для использования в памяти, но и означало, что у вас не может быть супер-приложение, из которого можно запускать различные приложения или любые простые (не- interprocess) между работающими приложениями.
Так как все это было запущено из webstart (т.е. с кучей банок как путь к классам), решение предотвратить загрузку системного загрузчика классов должно было компенсировать пакеты. Для примера, если у вас был класс a.b.X в приложении foo, то он был бы в файле jar как foo/a/b/X.class.
На моем последнем задании мы реализовали сервер, который мог бы иметь "логические определения логических запросов". (Клиент мог вызывать запросы по имени, сервер искал зарегистрированный запрос для этого имени и запускал его).
Определениями запроса были код и/или метаданные, содержащиеся в банке.
Ящик был загружен на сервер, хотя наше консольное приложение.
При загрузке (и позже при перезапуске сервера) наша инфраструктура создаст загрузчик классов для jar, чтобы загрузить его на работающий сервер.
Я делаю это один раз. Мы должны использовать API, предоставляемый сторонним поставщиком, и этот API использует странную версию hibernate3.jar. Таким образом, нам пришлось загрузить эту конкретную банку с помощью специального загрузчика классов для исключения avoir "serial version UID".
Я видел хороший пост здесь. В нем рассказывается о различных загрузчиках классов, иерархии загрузчика классов и пользовательских загрузчиках классов.
Вы можете создавать версии программного обеспечения без простоя, в зависимости от ситуации в 24x7 работающих системах.
Вы можете написать свой собственный вызов загрузчика класса из JMX и заменить файл класса во время выполнения.