Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 21

А-а-а! Зачем модифицировать приватные поля через Reflection?
С выходом Java 9 — сразу до свидания!

Не надо модифицировать java.library.path. Про System.load() слышали?
Всего голосов 5: ↑5 и ↓0 +5
Дергать через reflection внутренние поля мне не доставляет никакого удовольствия. Поэтому я по максимуму стараюсь их обойти. Использую только когда не нашел другого способа.

Про System.load() хорошая идея. Это как раз то, что можно было бы сделать в JDBCDriverProxyImpl. Я пробовал экспериментировать с System.load(), но ничего не получилось, из-за того, что библиотеку грузил в разных класслоадерах, а добавить JDBCDriverProxyImpl, придумал уже позже, когда уперся в DriverManager.

Надо к этой функции вернуться.

Тут есть еще такой момент, сторонняя библиотека подгружает dll не всегда, а только при определенных параметрах, я проконтролировать это не могу. Но тут можно сделать превентивную загрузку, даже если на самом деле библиотека не понадобится.
Всего голосов 1: ↑1 и ↓0 +1
Ну просто не вы же первый такое придумали с загрузкой. Обычно распаковывают молча куда-нибудь внутрь условного home нужную dll/so и делают System.load. Для выгрузки всегда считалось, что если загрузивший classloader не используется и собран сборщиком, то библиотека должна отгрузиться. Но как на самом деле — я лично не проверял) Так что в целом инфа интересная.
Всего голосов 3: ↑3 и ↓0 +3
С выходом Java 9 — сразу до свидания!

Насколько мне известно, в Java 9 ломается доступ к классам в недоступных пакетах. Если пакет доступен, то setAccessible работает как раньше. Во-всяком случае, этот тест прекрасно работает в 9-ea+138:


import java.lang.reflect.*;
import java.util.*;

public class Test {
  public static void main(String[] args) throws Exception {
    Field usrPathsField = ClassLoader.class.getDeclaredField("usr_paths");
    usrPathsField.setAccessible(true);
    String[] paths = (String[]) usrPathsField.get(null);
    System.out.println(Arrays.toString(paths));
  }
}
Всего голосов 1: ↑1 и ↓0 +1
Всё верно. Со страшилками про Java 9 я переборщил :) В данном конкретном случае будет работать. ПОКА будет. Детали реализации, такие как приватные поля, могут измениться в любой момент, даже с минорным апдейтом.

Кое-что в класслоадерах уже изменили в Java 9. Например, системный ClassLoader больше не наследник URLClassLoader. Но я встречал проекты, где просто кастовали системный ClassLoader, чтобы взять у него URLClassPath. И фокус с usr_paths из той же серии.
Всего голосов 2: ↑2 и ↓0 +2

С этим не поспоришь. Закладываясь на недокументированные детали реализации, мы подписываемся на постоянную их поддержку. Либо надо мониторить все изменения в этом классе и вовремя добавлять новые ветки, либо быть готовым, что всё сломается и виноват будешь только сам. Скользкая дорожка, в общем.

Всего голосов 1: ↑1 и ↓0 +1
А чем не подошёл стандартный в таких случаях подход, когда есть маленький лаунчер, который всё копирует, куда надо, потом запускает в отдельном процессе основную программу с нужными параметрами, дожидается её завершения, после чего всё подчищает?
Всего голосов 4: ↑4 и ↓0 +4
Это решение я тоже рассматривал. Как более быстрый workaround я выбрал Windows Task Scheduler, а когда уже появилось время на эксперименты, очень хотелось увидеть именно как то, как библиотека выгружается.
Всего голосов 2: ↑2 и ↓0 +2
Понятно. Что касается экспериментов, любопытно поисследовать, почему gc() + runFinalization() работал в Java 7, но перестал в Java 8. Как я уже писал в другой теме, сборки, вызванные System.gc() и дампом хипа, на уровне JVM принципиально не отличаются. Скорее всего, дамп помогал по другой причине, например, из-за таймингов. Не знаю, мне самому не удалось воспроизвести проблему: в JDK 8 System.gc() стабильно работал, и финализаторы вызывались. Вот, если бы в статье было про это — было бы интересно!
Комментарий пока не оценивали 0
НЛО прилетело и опубликовало эту надпись здесь
А то, что предлагается, не костыли? Да и сколько надо было писать и эксперементировать :)

Вот это — костыль:
System.gc();
System.runFinalization();

А если JVM оба раза откажется это делать, то что? Уж лучше лаунчер.
Всего голосов 5: ↑5 и ↓0 +5

По факту очень многие Java-приложения делают такой маленький нативный лаунчер (как минимум, все популярные IDE — IDEA, Eclipse, NetBeans). Параметры JVM записываются в какой-нибудь конфиг или передаются как-нибудь вроде -Jblahblah. Как минимум, это надёжнее: не всегда .jar на произвольной системе запутится как запускаемый файл. Сделать такой лаунчер совсем нетрудно, есть даже готовые генераторы этих лаунчеров.

Всего голосов 3: ↑3 и ↓0 +3
Хотя этот подход применяется повсеместно, мне он не нравится тем, что это будет уже не программа на Java, а программа на C++ с примочкой на Java. Если я лаунчер на напишу на C#, то почему бы мне и в базу данных не слазить из C#? И зачем мне тогда JDBC-драйвер? Вот если бы этот лаунчер входил в JDK, тогда другое дело. В Eclipse такой плагин наверняка есть, но, видимо, он не входит в поставку JDT, потому что на глаза ни разу не попадался.
Комментарий пока не оценивали 0
Если дело только в этом, можно и на Java лаунчер сделать. В JAR будет прописан Main-Class лаунчера, который запускает новый Java процесс с тем же JAR в classpath, но с другим Main классом.
Комментарий пока не оценивали 0
Все же аргументы Java придется задавать отдельно, а иначе ни jmxremote, ни отладочный порт поднять не получится.
Комментарий пока не оценивали 0

Вот магия с ThreadLocal-ами — это самый ад здесь. Мало того что суровая завязка на реализацию. Реализация ThreadLocalMap абсолютно не потокобезопасная, потому что предполагается, что в неё никогда не залезает никто из чужого потока. Если во время вашего клинапа в другом потоке записывается какой-нибудь любой другой тредлокал, может в принципе много интересного произойти. Можно ведь и на рехэшинг напороться. Или вы не затрёте все записи, какие хотите затереть, или затрёте лишнюю запись.


Вообще правильно Лёша Шипилёв говорит. Если вы сталкиваетесь с неразрешимой проблемой в Java, правильно — написать в мейлинг-листы OpenJDK, обсудить, предложить JEP, сделать патч, дождаться выхода следующей версии Java и радоваться. А хакать джаву неправильно, работоспособность вашей программы тогда гарантировать будет невозможно. Понятно, что это слишком идеалистическая картина мира, но всё-таки стоит иметь в виду такой вариант.

Всего голосов 3: ↑3 и ↓0 +3
Про общение с командой OpenJDK поделитесь, пожалуйста, как это правильно делать. У меня с ними взаимодействие получается какое-то одностороннее. Послал баг-репорт, а в ответ — тишина. Сейчас смотрю, решили исправить в Java 9, не прошло и года. Наверное, у разработчиков есть какие-то форумы, где с ними можно нормально пообщаться.

Что такое JEP?
Комментарий пока не оценивали 0
Про общение с командой OpenJDK поделитесь, пожалуйста, как это правильно делать

1. Идем и находим нужный mail list
2. Справшиваем там и/или ищем похожие проблемы в трекере

Что такое JEP?

JDK Enhancement-Proposal (JEP-2). Можно все там не читать. Это процесс для внесения новых фич и изменений в JDK.

lany для того, чтобы предложить JEP, необходимо иметь учетную запись в трекере, а значит быть OpenJDK автором.
Всего голосов 1: ↑1 и ↓0 +1

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

Комментарий пока не оценивали 0
прошу прощения за тупой вопрос — но зачем вообще надо было добиваться стопроцентной выгрузки длл-ки? просто чтобы не оставлять следов в temp каталоге?
Комментарий пока не оценивали 0
Да.
Комментарий пока не оценивали 0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Разблокировать темную тему

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr