Весьма существенная проблема, с которой, вероятно, сталкивался не один разработчик подключаемых решений на Java.
Для тех, кто не знаком с такой проблемой краткое введение.
Допустим у вас есть некая jar библиотека, для которой существует необходимость ее динамически загрузить, а затем выгрузить данную библиотеку и удалить jar файл библиотеки. Случаи, для чего это необходимо – за рамками данной статьи, в качестве иллюстрации: имеется 2 версии jdbc драйвера, при определенных условиях вторая версия существенно повышает производительность при работе с БД, первая версия general case решение и используется по умолчанию. Нам нужно использовать general case версию драйвера (driver1.jar) и если мы определили соответствующие условия, то следует воспользоваться (driver2.jar). driver1.jar – следует стереть с диска.
Данная задача не стоит под Linux, там файлы легко удаляются. Под Windows — это существенная проблема, поскольку открытый файл лочится системой (вероятно, в jdk не указан флаг FILE_SHARE_DELETE при открытии файла) и их нельзя удалить, до тех пор пока файл не будет закрыт, т.е. пока не будет вызван метод close для открытого jar файла. Вероятно, данная проблема будет решена в jdk 7-й версии. Для более ранних версий проблема актуальна.
Проблема возникает из-за того, что есть несколько мест-пулов, где ссылки на открытые jar файлы jvm хранит на протяжении всей своей жизни и не существует открытого интерфейса для закрытия файлов, удаления ссылок. Где хранятся данные ссылки – то же большой вопрос и задача обнаружения месторасположения их нетривиальна.
Пришлось повозиться прежде чем мне удалось найти решение… Ключевые классы sun.net.www.protocol.jar.JarURLConnection и sun.misc.URLClassPath.
По ссылке http://snipplr.com/view/24224/class-loader-which-close-opened-jar-files/ переопределенный URLClassLoader который решает данную задачу. Данный кусок кода, часть Hibernate Tools – проекта с открытым исходным кодом, часть Jboss студии, которая существенно упрощает ряд задач с которыми приходится сталкиваться Java разработчикам использующим Hibernate и использующи Eclipse в качестве IDE.
Для тех, кто не знаком с такой проблемой краткое введение.
Допустим у вас есть некая jar библиотека, для которой существует необходимость ее динамически загрузить, а затем выгрузить данную библиотеку и удалить jar файл библиотеки. Случаи, для чего это необходимо – за рамками данной статьи, в качестве иллюстрации: имеется 2 версии jdbc драйвера, при определенных условиях вторая версия существенно повышает производительность при работе с БД, первая версия general case решение и используется по умолчанию. Нам нужно использовать general case версию драйвера (driver1.jar) и если мы определили соответствующие условия, то следует воспользоваться (driver2.jar). driver1.jar – следует стереть с диска.
Данная задача не стоит под Linux, там файлы легко удаляются. Под Windows — это существенная проблема, поскольку открытый файл лочится системой (вероятно, в jdk не указан флаг FILE_SHARE_DELETE при открытии файла) и их нельзя удалить, до тех пор пока файл не будет закрыт, т.е. пока не будет вызван метод close для открытого jar файла. Вероятно, данная проблема будет решена в jdk 7-й версии. Для более ранних версий проблема актуальна.
Проблема возникает из-за того, что есть несколько мест-пулов, где ссылки на открытые jar файлы jvm хранит на протяжении всей своей жизни и не существует открытого интерфейса для закрытия файлов, удаления ссылок. Где хранятся данные ссылки – то же большой вопрос и задача обнаружения месторасположения их нетривиальна.
Пришлось повозиться прежде чем мне удалось найти решение… Ключевые классы sun.net.www.protocol.jar.JarURLConnection и sun.misc.URLClassPath.
По ссылке http://snipplr.com/view/24224/class-loader-which-close-opened-jar-files/ переопределенный URLClassLoader который решает данную задачу. Данный кусок кода, часть Hibernate Tools – проекта с открытым исходным кодом, часть Jboss студии, которая существенно упрощает ряд задач с которыми приходится сталкиваться Java разработчикам использующим Hibernate и использующи Eclipse в качестве IDE.