У меня уже есть приложение Java Swing, и оно упаковывается с помощью JPackage для Linux, Mac и Windows. Это означает, что у меня есть собственные установщики для приложения.
Теперь есть пользователи, которым необходимо запускать приложение с дополнительными системными свойствами. Например, FlatLAF можно настроить следующим образом — см. https://www.formdev.com/flatlaf/system-properties/
Итак, вопрос: после выполнения установщика, упакованного в jpackage, что может сделать пользователь, чтобы запустить приложение с определенными системными свойствами?
Я нашел решение, которое не требует каких-либо изменений в приложении и, следовательно, может быть выполнено пользователями.
Обратите внимание, что файл свойств также может создаваться пользователями. Он не требует от пользователя изменения самого приложения, однако разработчику потребуется изменить приложение, чтобы добавить функциональные возможности.




Приложение упаковывается с использованием JPackage, который автоматически превращает приложения Java в легко распространяемый исполняемый файл. Таким образом, нет командной строки для установки свойств системы. Вместо этого есть файл конфигурации.
Этот файл конфигурации находится в одном из
$APPLICATION_HOME/app/<APPLICATION>.cfg
$APPLICATION_HOME/lib/app/<APPLICATION>.cfg.
В Linux по умолчанию это
/opt/<APPLICATION>/lib/app/<APPLICATION>.cfg
в Windows найдите
C:\Program Files\<APPLICATION>\app\<APPLICATION>.cfg
Найдя файл, внутри вы увидите раздел JavaOptions. Вы можете добавить дополнительные системные свойства, каждое в виде новой строки, например:
[JavaOptions]
java-options=-Djpackage.app-version=0.1-29
java-options=-Dflatlaf.uiScale=2.5
В примере показано, как масштабировать шрифты, используемые FlatLAF, если у вас экран с высоким разрешением.
При таком подходе следует соблюдать осторожность: файл *.cfg, скорее всего, будет перезаписан, когда пользователь обновит приложение. Или, по крайней мере, я не понимаю, почему его нельзя перезаписать. Это заставит пользователя снова установить все соответствующие свойства системы. Предложенный мной подход к файлу свойств не имеет такой проблемы.
Я, скорее, выберу обновленный JDK, чем внесу конфигурацию в каждое приложение. Более того, такие параметры, как размер кучи, нельзя изменить во время работы JVM.
Поскольку JDK19 jpackage поддерживает переопределение местоположения файлов cfg. Вам не нужно редактировать каталоги установки, которые могут быть перезаписаны при следующей установке. Однако у вас есть проблема: при следующей установке могут быть добавлены изменения, которые вашим пользователям необходимо скопировать в свой файл переопределения cfg.
См. JDK-8287060 Разрешить настройку приложения jpackaged для каждого пользователя и всей системы
Например, в Windows вы должны скопировать и отредактировать конфигурацию здесь:
%LOCALAPPDATA%\YourAppName\LauncherName.cfg
Мне нравится этот подход. В настоящее время мое приложение все еще поставляется в комплекте с JDK 17.
Это должно сработать, если вы создадите среду выполнения JDK17 с JDK17 jlink и используете JDK19 jpackage --runtime-image your-jre17, чтобы jpackage не выполнял неявно свой собственный шаг jlink.
Мне нравится это решение, но оно, похоже, не задокументировано ни в руководстве пользователя , ни в руководстве по инструменту. Либо так, либо я слепой и просто пропустил, где об этом говорилось.
@Slaw Вы правы, я не думаю, что эти руководства сильно обновлялись. Я наткнулся на это изменение только при просмотре недавней регрессии, которая была перенесена в ранние обновления JDK17/21/22 и портит все, если вы запускаете подпроцессы.
Если предположить, что ни одно из настраиваемых системных свойств не требуется указывать при запуске, то, возможно, можно указать файл свойств с аргументом командной строки или переменной среды (и обработать его в начале приложения, например, в
main).