Когда установлены обе 64/32-битные версии JVM, как приложение JNLP выбирает (правильную битовую) версию JVM? - PullRequest
Новая
       37

Когда установлены обе 64/32-битные версии JVM, как приложение JNLP выбирает (правильную битовую) версию JVM?

0 голосов
/ 28 апреля 2018

Поскольку я разрабатываю приложения Java как в 64-разрядных, так и в 32-разрядных средах, я поддерживаю обе виртуальные машины Java в своей среде разработки. Приложение JNLP, которое я разработал, должно работать в 32-битной среде, потому что оно вызывает dll, для которого требуется 32-битная среда.

В большинстве случаев JNLP, похоже, "знает", что он должен работать в 32-битной среде, но я подозреваю, что мне просто повезло. Когда я обновил свою 64-битную Java до версии 10, это привело к сбою JNLP, потому что JNLP пытался работать в 64-битной среде. Когда я восстановил 64-разрядную среду до версии 1.8 (той же версии, что и 32-разрядная среда, приложение снова запустилось в 32-разрядной среде.

Но откуда он это знает? Есть ли какое-либо свойство приложений JNLP, которое приводит к тому, что оно по умолчанию устанавливается в 32-битной среде, если версии Java совпадают?

Есть ли способ гарантировать, что JNLP будет работать в 32-битной среде, установив что-либо в этой среде или указав определенную библиотеку JRE, когда я сделаю свою сборку?

Ответы [ 2 ]

0 голосов
/ 29 апреля 2018

После долгих экспериментов я обнаружил следующее.

Во-первых, изменение элемента Resources в XML установки JNLP для принятия конкретной архитектуры (например, x86), похоже, не работает и фактически выдает ошибку.

Во-вторых, установка любого jvm больше 1.8 приведет к тому, что JNLP будет использовать эту JVM. Поскольку Oracle не поддерживает 32-битную JVM выше 1.8, это означает, что приложение JNLP будет работать в 64-битной среде. Очевидно, JNLP будет работать в последней доступной версии. По крайней мере, поведение Java на моей машине, кажется, предполагает это.

В-третьих, как описано здесь, bugs.openjdk.java.net/browse/JDK-8029922, если вы используете 32-битную и 64-битную jvm на одной машине, то порядок, в котором вы устанавливаете эти jvms вопросы. Чтобы убедиться, что приложение JNLP принимает 32-битную версию jvm, вам необходимо установить эту версию java second. Другими словами, JNLP, по-видимому, запускает последнюю версию установленной Java, независимо от разрядности jvm, если только JVM, установленная первой, не является более поздней версией Java. Затем более поздняя версия - та, в которой работает JNLP.

Поскольку Oracle больше не поддерживает 32-битные версии java после версии 1.8, это означает, что если вам нужно, чтобы JNLP работал в 32-битной среде, вы должны установить java версии 1.8 ИЛИ РАНЬШЕ, чтобы это произошло.

Поскольку Webstart и JNLP устарели, как предполагает ответивший выше вопрос, пришло время рассмотреть другую технологию для развертывания Java-приложений, отличных от Webstart.

0 голосов
/ 28 апреля 2018

Есть ли способ гарантировать, что JNLP будет работать в 32-битной среде, установив что-либо в этой среде или указав определенную библиотеку JRE, когда я буду делать сборку?

Короткий ответ, по-видимому: Нет.

Ниже объясняется, как вы указываете версию, которая будет использоваться в файле спецификации JNLP:

Вы должны иметь возможность принудительного выбора 32-битной JVM только с помощью , указав ресурсы для 32-битной архитектуры; например, * 1 020 * 

  <resources os="Linux" arch="x86">
    <nativelib href="lwjgl-x86-linux.jar"/>
  </resources>
  <resources os="Linux" arch="i386">
    <nativelib href="lwjgl-x86-linux.jar"/>
  </resources>

(В целях разработки / тестирования вы можете использовать файл JNLP для разработки, в котором отсутствуют 64-битные ресурсы ...)

Однако, как вы обнаружили, это не поможет, если клиент JNLP будет использовать 64-битную JVM, если она доступна ... а затем пожалуется, что 64-битные ресурсы отсутствуют.

Может быть возможно изменить способ, которым клиент / программа запуска JNLP делает свой выбор. Однако это будет зависеть от используемой вами программы запуска; например это может зависеть от используемого вами подключаемого модуля Java и от того, можете ли вы настроить его для использования определенного JRE.

И оказывается, что существуют известные ошибки / несоответствия в том, как некоторые клиенты JNLP решают, использовать ли 32- или 64-битные JRE.

Однако, JNLP и JavaWebstart устарели в Java 9 и выше , поэтому вам, вероятно, следует искать альтернативу. Особенно, если вы / ваши клиенты не собираетесь платить за коммерческую поддержку Oracle Java.

...