Есть ли перечисление, в котором перечислены все параметры JVM?
Я пытался найти, есть ли перечисление (или любая другая структура), перечисляющее все параметры JVM, например javax.net.ssl.keyStore или jdk.tls.server.protocols, что-то похожее на перечисление HttpStatus из Spring Boot.
Кто-нибудь знает о таком перечислении?
Обновлено: Чтобы прояснить ситуацию, я ищу перечисление, в котором перечислены только возможные имена свойств JVM, а не их значения. Я знаю, как читать значения, но я просто не хочу постоянно повторять одну и ту же строку при вызове System.getProperty().
Спасибо @Rogue. Да, мое приложение настраивает множество других компонентов и имеет несколько классов, добавляющих параметры JVM во внешние файлы. Я могу написать собственное перечисление для свойств, которые использую, но хочу быть уверенным, что не буду снова изобретать велосипед :-)
Не совсем перечисление, но в основном это поможет?
Такого не существует.
Системное свойство не является «опцией JVM». Как сказал @Rogue, эти свойства приобретают смысл благодаря вызову кода Java System.getProperty(…), который может выполнять любой код Java, например. когда мой код вызывает System.getProperty("foo.bar.baz") и что-то делает с результатом, у нас появляется новое системное свойство «foo.bar.baz», значение которого зависит от того, что делает мой код. Итак, 1) JVM вообще не задействована и 2) число потенциально существующих свойств системы бесконечно. Более того, даже для кода JDK существуют системные свойства, которые имели значение в прошлом, но не имеют значения сегодня.
Ответы 1
Есть ли перечисление, в котором перечислены все параметры JVM?
Такого не существует.
Почему?
(Я предполагаю, что «параметры JVM» относятся к параметрам JVM командной строки или свойствам системы JVM... или к тому и другому.)
Фундаментальная проблема заключается в том, что существуют правила двоичной совместимости, которые применяются при изменении определения enum. Вы можете добавлять новые константы enum, но если вы удалите существующую константу, это будет несовместимое изменение. Это означает, что код, скомпилированный со старой версией, не может использовать новую версию... без перекомпиляции.
Почему это проблема?
Платформа Java постоянно развивается. Добавляются новые параметры, а существующие параметры устаревают и (в конечном итоге) удаляются. Что касается системных свойств, также существует проблема, заключающаяся в том, что параметр может измениться с параметра JVM на параметр отдельного модуля и наоборот. В результате enum, отражающий текущий набор параметров JVM, может привести к проблемам двоичной совместимости между версиями Java (и даже выпусками).
Вторая проблема заключается в том, что некоторые параметры недокументированы и являются полувнутренними. Другие зависят от того, какие параметры сборки использовались при сборке дистрибутива JVM. Класс enum, который точно отслеживает параметры, доступные в >этой< JVM, будет сложно реализовать.
Что вы должны сделать?
Ну, вы могли бы объявить свой собственный enum ... но вы столкнулись бы с проблемами, описанными выше. Вероятно, вы могли бы игнорировать частные параметры и параметры, зависящие от сборки, но наличие разных версий enum в зависимости от версии JVM все равно приведет к трудностям.
Сам? Я бы смоделировал (текущий) набор параметров системы как HashSet<String> или HashMap<String, Something>; то есть не пытайтесь моделировать параметры в системе типов Java. (Следствием является то, что вам придется иметь дело с некоторыми вещами во время выполнения, а не во время компиляции.)
Обратите внимание, что это отличается от статуса HTTP. Причина, по которой Spring может определять enum для кодов состояния HTTP, заключается в том, что они указаны (спецификациями W3C), и стандартные коды никогда не будут удалены из enum. Но все равно будут проблемы с веб-сервером, использующим нестандартные коды; см. Нестандартные коды ответов http: рекомендуемое поведение клиента.
Потенциально маловероятно, поскольку некоторые из этих параметров извлекаются на месте вызова через
System#getProperty(String)или подобное, оставляя знание ключа для поиска вызывающему абоненту/разработчику. В этом смысле не будет единого централизованного расположения для всех них, но на этот счет есть страницы документации Oracle.