По каким причинам люди должны были писать свой собственный загрузчик классов

Недавно в интервью меня спросили о порядке, в котором загрузчики классов вызываются при загрузке класса.

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

Это заставило меня задуматься, по каким причинам они написали собственный загрузчик классов.

Вот и мой вопрос: с какими сценариями сталкивались люди, которые требовали написания собственных загрузчиков классов?

Ответов (12)

Взгляните на этот вопрос .

Я сделал это один раз. Мы должны использовать API, предоставляемый сторонним поставщиком, и этот API использует странную версию hibernate3.jar. Итак, нам пришлось загрузить этот конкретный jar-файл с помощью специального загрузчика классов, чтобы избежать исключения "serial version UID".

Я видел хороший пост здесь . В нем говорится о различных загрузчиках классов, иерархии загрузчиков классов и пользовательских загрузчиках классов.

Вы можете выпускать выпуски программного обеспечения без простоев, вроде ситуаций в круглосуточно работающих системах.
Вы можете написать собственный вызов загрузчика классов из JMX и заменить файл класса во время выполнения.

Мне однажды пришлось реализовать ClassLoader, когда я хотел загрузить классы в файлы .jar из файла .jar (это было несколько лет назад, я уверен, что сейчас есть инструменты, которые могут сделать это за вас). то есть, вы бы поместили свои файлы зависимостей .jar в один файл .jar.

Но это единственный раз, по моему опыту написание кастомного ClassLoader - довольно редкая вещь.

Типичная причина заключается в том, что ваше приложение размещает другие приложения, которые используют одни и те же библиотеки в разных версиях в одной и той же среде выполнения (например, Tomcat). Таким образом, вы должны убедиться, что ваш загрузчик классов может предоставлять разные версии одного и того же класса для каждого из этих приложений.

РЕДАКТИРОВАТЬ :

Чтобы прояснить это немного (см. Путаницу в комментариях): Когда сказано «ваш загрузчик классов», я имею в виду «реализацию java.lang.ClassLoader », а не экземпляр такого класса. На самом деле это ваш загрузчик классов S в обоих смыслах: люди Tomcat реализованы различные ClassLoader -обучение и еще больше экземпляров во время выполнения ... подробнее см соответствующие документы .

Некоторые места фактически хранят классы в базе данных (ну, раньше были места, не уверен, есть ли они еще) и используют загрузчик классов для получения классов из базы данных во время выполнения.

We had an application framework that had applications based on it which were 'statically tied'. This meant that you needed to have a jvm instance per application you wanted to run, which was not only bad for memory use, but meant that you could not have a super application from which to launch the various apps, or any easy (non-interprocess) communication between the running apps.

Since the whole thing was run from webstart (i.e with a bunch of jars as the classpath), the solution to preventing the system classloader from finding the classes was to offset the packages. For expample if you had a class a.b.X in an application foo then it would be in the jar file as foo/a/b/X.class .

В настоящее время я работаю над чрезвычайно большим приложением с высокой степенью модульности, т.е. оно состоит буквально из сотен файлов JAR. Это означало, что строка пути к классам стала огромной , вызывая всевозможные проблемы в самых разных местах из-за неспособности различных инструментов разработки работать со строкой пути к классам размером 5 КБ. Это было решено путем написания специального загрузчика классов, который считывает свой путь к классам из файла.

Скука и желание мучить моих коллег, когда им приходилось поддерживать мой код. :)

На моей последней работе мы реализовали сервер, который мог иметь «подключаемые логические определения запросов». (Клиент мог вызывать запросы по имени, сервер просматривал зарегистрированный запрос для этого имени и запускал его).

Определения запросов представляли собой код и / или метаданные, содержащиеся в банке.

Банку загрузили на сервер через наше консольное приложение.

При загрузке (и позже при перезапуске сервера) наша структура создаст загрузчик классов для jar-файла, чтобы загрузить его на работающий сервер.

Я наткнулся на статью, в которой рассказывается, почему (очень кратко) OSGI использует собственный загрузчик классов.