Альтернатива sun.misc.Signal

Я начал исследование, чтобы найти альтернативу классу sun.misc.Signal, потому что он может быть неподдерживаемым в предстоящих JDK (в настоящее время мы работаем над 1.6). Когда я создаю проект, я получаю:

предупреждение: sun.misc.SignalHandler - это собственный API Sun и может быть удалено в будущей версии

Я столкнулся с несколькими решениями, но они не соответствуют моему проекту, например. в этот вопрос.

Это неприемлемо в моей ситуации, потому что:

Сигналы используются не только для уничтожения приложения
Приложение огромно - каждое концептуальное изменение связи между модулями /JVM может занять годы для реализации

Таким образом, желательным решением является найти что-то вроде новой версии Oracle этого класса или что-то, что работает одинаково. Существует ли такое решение?

Ответ 1

Поскольку вы найдете многократное повторение до бесконечности при изучении обработки сигналов в Java, вам рекомендуется избегать написания кода Java, который напрямую зависит от сигналов. Общая лучшая практика - разрешить JVM нормально выходить на ctrl + c и других сигналах, зарегистрировав вместо этого ловушку отключения. Обработка сигналов напрямую делает вашу программу Java зависимой от ОС.

Но иногда это нормально, и вы действительно, действительно, хотите обрабатывать сигналы самостоятельно.

Даже при том, что это не выставлено как часть официального API JDK, некоторая часть JVM должна обработать сигналы (для того, чтобы вызвать перехватчики завершения работы и выйти), и этот компонент - sun.misc.Signal. Хотя это деталь реализации и поэтому может измениться, на практике это маловероятно. Если это изменится, его необходимо будет заменить эквивалентным механизмом, и, вероятно, это будет документировано в Руководстве по устранению неполадок платформы Java.

Класс родного брата sun.misc.Unsafe широко используется и аналогично недокументирован. В настоящее время ведется активная работа по удалению этого класса, поскольку он " становится" свалкой "для нестандартных, но необходимых методов ", но текущее предложение, хотя и ограничивает некоторые нестандартные API, сохраняет оба sun.misc.Unsafe и sun.misc.Signal доступен по умолчанию. Более ранний план по предотвращению доступа к этим классам все равно включал бы флаг командной строки, чтобы разрешить доступ к ним для обратной совместимости.

Вкратце, хотя вы не можете полагаться на sun.misc.Signal и должны планировать на sun.misc.Signal что это поведение изменится, маловероятно, что это поведение изменится до JDK 10, и если это произойдет, то, возможно, будет введен новый, более совершенный механизм. или будет разумный способ повторно включить его в случае необходимости.

Однако было бы разумно разделить код, основанный на любых классах sun.misc на как можно sun.misc область видимости - создать API-интерфейс для обработки сигналов, чтобы вызывающим пользователям не sun.misc напрямую взаимодействовать с sun.misc. Таким образом, если API меняется, вам нужно всего лишь изменить реализацию вашей обертки, а не весь код обработки сигналов.

Ответ 2

Если вы не можете принять какую-либо вероятность того, что sun.misc.Signal может измениться в недавнем будущем, просто реализуйте обработку сигналов самостоятельно, с помощью интерфейса JNI, на языке, который компилируется в машинный код (например, C), и импортируйте библиотеку с помощью System.load. Используя JNI, java может использовать C, а C может использовать java. Когда я впервые использовал JNI, мне показалось забавным иметь возможность использовать весь Java-API из моей C-программы.

Теперь единственное, о чем вам нужно беспокоиться - это изменится ли интерфейс ОС или, что более вероятно, изменится выбор используемой ОС.

Ответ 3

Лучше всего переходить от сигналов, поскольку они плохо поддерживаются.

Альтернативы IPC:

Сокеты (включая веб-службы, JMS и т.д.)
Блокировка файлов
Файл с отображением памяти