2009-03-10 2 views
2

Я хотел бы вставить каталог и подкаталоги из текущего обновления для Java 1.6 в пакет программного обеспечения, который я буду устанавливать на несколько других ПК и хотели бы знать, какие недостатки в этом делают (если они есть). Я хочу сделать это, чтобы моя версия на Java не переопределяла другие версии на ПК.Возникла ли проблема при копировании версии Java с одного ПК на другой вместо установки

ответ

4

В Linux нет проблем. В Windows тоже не должно быть никаких проблем, если вы используете JDK/JRE, установив путь и JAVA_HOME в каталог. Однако вы не сможете использовать плагин для апплетов, не вступая в реестр.

+0

Я полагаю, что могут возникнуть проблемы, если на двух компьютерах используются разные архитектуры чипов (например, x86 или amd64) ... –

+0

+1, но вы также можете запустить javacpl.exe после того, как настроить плагин для ваших браузеров –

+0

@ Давид: Хороший момент - я об этом не думал. – talonx

1

Я видел, как некоторые программы делают это (то есть: упаковывают JRE с программным обеспечением), основным недостатком такого подхода является больший размер вашего пакета, и он побеждает одну из веских причин использовать JRE (факт что он распределен по широте).

Почему вы обеспокоены установкой более новой JRE поверх уже существующих? JRE должна быть обратной совместимости. Если это ваша мотивация, я бы рассмотрел возможность установки новой JRE вместо упаковки так, как вы предлагали, поскольку не должно быть проблем с обратной совместимостью.

+0

Я не согласен. Определенно установите свою собственную JRE с кодом, так же как и версию, на которую вы тестировали. Если вы обновите общую JRE, кто-то еще сможет ее обновить позже и сломать ваш код. JRE «должен» быть обратно совместимым, но не так безопаснее иметь свои собственные. –

+0

, так что если в JRE есть защита vunreability, вы не можете ее исправлять, загружая последнюю JRE? Вместо этого пользователю нужно подождать, пока разработчик отправит новую версию своего пакета ... – hhafez

1

Спасибо за ваши ответы; причина, по которой я хочу использовать этот подход, заключается в том, что одно из моих приложений не работает с версией Java выше 1.6u11; если у пользователя есть автоматические обновления, установленные для Java, или если он решает перейти на более высокую версию, это нарушит мое другое приложение, которое работает только с Java 1.6u11. Встраивая jre файлы/структуру папок с установкой моего приложения и указывая ini-файлы для выполнения приложения с использованием этой версии Java, я буду следить за тем, чтобы версия была использована приложением, а не той, которая определена в JAVA_HOME, в зависимости от того, что выше (выше или ниже 1.6u11).

Любые комментарии более чем приветствуются.

+1

Имеет смысл - я успешно использовал этот подход в одном из моих приложений - как для Linux, так и для Windows - по той же причине. – talonx

+0

Я думаю, вам будет легче исправить любую проблему, которая приведет к несовместимости с версиями 1.6u11 +, а не к постоянному переводу устаревших версий JRE с вашим кодом .... просто полезная идея! – mikera