Запуск JVM из другой JVM - плохая идея, чтобы избежать дублирования кода? - PullRequest
0 голосов
/ 18 сентября 2010

У меня есть консольное приложение Java, которое запускается из пакетного скрипта в Windows и скрипта оболочки в Linux.В обоих случаях любые аргументы командной строки (которые являются сложными) просто передаются в приложение java, которое интерпретирует их с помощью Apache Commons CLI.

Теперь я хочу разрешить пользователям выделять дополнительную память для программы.Самым простым подходом может быть наличие дополнительного аргумента для этого (например, -m 1000), но есть недостатки.Теперь и пакетные, и командные сценарии должны будут интерпретировать командную строку, чтобы они могли извлечь аргумент из памяти и использовать его в качестве параметра -Xmx для JVM.Это фактически означает удовлетворение всей сложности разбора аргументов в 3 местах (batch / shell / java).

Единственный другой подход, который приходит на ум, - это заставить скрипты вызывать фиктивное приложение Java, которое используетсуществующую логику синтаксического анализа, чтобы найти новый аргумент, затем разветвите другую JVM для запуска основного приложения, используя правильный потолок памяти (используя Runtime.exec ()).Это могло бы обойти проблему дублирования кода.

Мой вопрос - это кажется кому-то плохой идеей?Возможно, есть вопросы, которые я не рассматриваю.

1 Ответ

1 голос
/ 18 сентября 2010

Если вам не нужна очень высокая производительность, я думаю, что все в порядке.На работе мы используем тот же подход для аналогичной проблемы: пользователь дважды щелкает файл приложения jar;этот jar-файл затем запускает другой процесс с нужным объемом памяти (обычно -Xmx512m).

Что следует учесть: может ли пользователь добавить дополнительные jar-файлы в classpath?Может ли пользователь установить другую JVM для использования?Если да, это может быть сложно.Вы также должны убедиться, что процесс заканчивается.Возможно, вам придется перенаправить входной поток, выходной поток и поток ошибок, возможно, используя отдельные потоки.

...