Что причинам люди для записи их собственного [закрытого] classloader

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

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

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

Для разъяснения этого немного (см. беспорядок в комментариях): При высказывании "classloader" я ment "реализация java.lang.ClassLoader" не экземпляр такого класса. На самом деле это - Ваш classloader s в обоих значениях: люди Tomcat реализовали отличающийся ClassLoader - классы, и имейте еще больше экземпляров во времени выполнения... для получения дополнительной информации посмотрите соответствующие документы .

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

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

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

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

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

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

У нас была среда разработки приложения, которая имела приложения на основе его, которые были 'статически связаны'. Это означало, что у Вас должен был быть jvm экземпляр на приложение, которое Вы хотели запустить, который не был только плох для использования памяти, но и означал, что у Вас не могло быть супер приложения, из которого можно запустить различные приложения или любую легкую (немежпроцессную) коммуникацию между запущенными приложениями.

Начиная со всего этого был выполнен от webstart (т.е. с набором банок как путь к классу), решение предотвращения системы classloader от нахождения, что классы должны были сместить пакеты. Для expample, если бы у Вас было класс a.b.X в нечто приложения тогда, это было бы в файле банки как foo/a/b/X.class.

В моем последнем задании мы реализовали сервер, который мог иметь "сменные логические определения запроса". (Клиент мог позвать запросы по имени, сервер искал зарегистрированный запрос для того имени и выполнил его).

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

банка была загружена на сервер хотя наше консольное приложение.

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

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