Почему установщик Java SDK не устанавливает JAVA_HOME?

Question

Мне всегда было интересно, почему я должен вручную устанавливать переменную среды JAVA_HOME после установки Java SDK.

JAVA_HOME = c: \ Program Files \ Java \ jdk1.6.0_12

Visual Studio, по крайней мере, предоставляет пакетный файл для установки таких переменных среды:

вызов "c: \ Program Files \ Microsoft Visual Studio 9.0 \ VC \ vcvarsall.bat "

Есть ли в Java что-то похожее? Я пытаюсь сделать скрипт сборки, который должен просто работать после установки Java SDK. Я не хочу, чтобы люди связывались с переменными среды на своем ПК.

Answer 1

Вы можете установить столько версий Java, сколько пожелаете.

Для установки было бы опасно изменить локальную переменную среды, например JAVA_HOME, поскольку она может ссылаться на существующую установку Java.

Это не имеет ничего общего с предполагаемой "зависимой от платформы проблемой". ;)

Поскольку сценарии могут зависеть от JAVA_HOME при запуске самих себя, опять же, для новой установки Java будет иметь катастрофические последствия для изменения JAVA_HOME: все эти сценарии внезапно придется запускать с новой потенциально несовместимой JVM.

Кроме того, установив $JAVA_HOME/bin или %JAVA_HOME%/bin на своем пути, вы можете динамически изменить JAVA_HOME на любую версию Java, которую вы хотите использовать, не слишком сильно используя переменную PATH.

---

Майкл Боргвардт задал в комментариях интересный вопрос для продолжения

Тем не менее, это не объясняет, почему установщик не устанавливает JAVA_HOME, если он вообще не был установлен ранее.

Ответ прост:

Настройка не может знать, зависит ли сценарий от JAVA_HOME или нет .

Значение: некоторые сценарии могут проверять значение JAVA_HOME, и если оно не установлено, ссылаться на другую JVM, установленную в другом месте (и не забывать, что под словом "установка" можно ссылаться только на "скопированный": JDK / JRE не всегда устанавливается при установке)

Если вы установите JAVA_HOME, это может нарушить поведение по умолчанию некоторых ваших сценариев.

Не желая мешать гипотетическим сценариям, которые зависят от того, что env var не звучит для меня бессмысленно параноидально - если сценарий делает это, то он явно ХОЧЕТ использовать другую JVM, когда она установлена, - нет причин избегать этого.

Ммм ... Сладкий. Я могу заверить вас, что для решения огромных проблем развертывания ежедневно (для внутреннего применения в моем магазине) это очень вменяемый "параноик" угощение, чтобы иметь.
При развертывании (очень) большого набора пользователей вы не хотите делать какие-либо предположения об их платформе и конфигурации. «ЯВНО ХОЧУ» - это предположение, которое я бы не осмелился сделать (или я перенаправляю свой телефон на ваш;), и вы обрабатываете злые звонки).

Например, у нас есть много сценариев, которые запускаются с JVM 1.4.2 от sun (JAVA_HOME не задан на платформе разработки, путь по умолчанию задан непосредственно в сценарии) или с 1.4.2 из JRockit (установлено JAVA_HOME, так как это намеченная цель для платформ интеграции, предпроизводства и производства).

Но мы регулярно устанавливаем новый JDK1.6.x, поскольку мы используем его для запуска затмения.

Предположим, что эти сценарии хотят установить JAVA_HOME ... и больше ничего не работает.

... На что Роберт Грант делает этого критика на месте:

Вы описываете сценарии, для которых требуется одна конкретная версия, но все же смотрите на глобальный JAVA_HOME. Это просто плохо продуманные сценарии.

Хотя это может или не может быть правдой, это также иллюстрирует мою точку зрения:
«Вы не хотите делать какие-либо предположения»: никаких предположений об их платформе / настройках и никаких предположений об их «лучших методах».
Первое может показаться параноидальным, последнее - здравый смысл: думать, что ваш продукт (здесь настройка JDK) ничего не нарушит в среде пользователя, потому что пользователь «правильно» продумал свои сценарии ... было бы безумием.

---

GvS предлагает:

Или это может быть просто опция, отключенная по умолчанию

Это означало бы еще одну опцию для включения в экраны настройки, опцию, которая должна быть тщательно рассмотрена пользователем и которая может иметь непредвиденные последствия, даже если пользователь выбирает ее, думая, что знает, что делает ...

Это просто не стоит.

Answer 2

Я не думаю, что JAVA_HOME - это соглашение, изобретенное или поддерживаемое Sun.

Они, вероятно, помнят фиаско, которое было переменной среды CLASSPATH ** слишком хорошо, и предпочитают держаться подальше от переменных среды.

** Это было рекомендовано в качестве основного способа установки пути к классам JVM в более ранних версиях Java SDK и литературе, в результате чего пользователь и различные приложения связывались с переменной среды, перезаписывали изменения друг друга и зависели от взаимно противоречивого содержимого.

Answer 3

Механизм vcvarsall.bat - это удобный способ для Visual C ++ обеспечить консоль правильными переменными без вмешательства в переменные окружения пользователя / системы. Тем не менее, предполагается, что Installshield - единственный способ получить код в систему. JDK должен терпеть нарезку и вставку из одного места в другое.

Если вы ищете java.exe , установщик Installshield должен поместить его в % windir% \ system32 , чтобы он был доступен в PATH.

Вы можете получить некоторые подсказки о местонахождении установленных приложений, запросив реестр:

C:>REG QUERY "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit\1.6" /v JavaHome

! REG.EXE VERSION 3.0

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit\1.6
    JavaHome    REG_SZ  C:\dev\Java\jdk1.6.0_05

Тем не менее, вы не можете полагаться на это абсолютно, потому что это делает некоторые предположения относительно поставщика, версии и механизма установки.

Answer 4

Это может помочь кому-то еще, кто окажется здесь, как я. Я просто хочу использовать Java как инструмент, а не принимать его как образ жизни, поэтому мне нужно было только знать, как настраивался JAVA_HOME и почему он не был правильным. Ответ оказался, что установка WinAnt устанавливает JAVA_HOME (вместе с ANT_HOME), но только на основе установленной в данный момент Java. Поэтому, если вам нужно изменить версию Java и вы используете Ant, правильный способ сделать это - удалить WinAnt, удалить Java, установить новую Java, а затем переустановить WinAnt.

Answer 5

Я не уверен, почему это так, потому что установщики четко решают проблемы, зависящие от платформы (что, разумеется, и составляет смысл JVM). Вы уверены, что не смешиваете JRE с JSDK?

Возможно, у вашей программы есть способ найти, где установлена ​​java (я думаю, это будет скрипт), а затем установить JAVA_HOME и, возможно, добавить его в путь.

IBM, похоже, уже делает этот трюк: http://www -01.ibm.com / поддержка / docview.wss? Rs = 180 & UID = swg21199220

Другой интересный пост, намекающий на разницу между установками JRE и JSDK: http://confluence.atlassian.com/display/CONF26/Set+JAVA_HOME+variable+in+Windows

Надеюсь, это поможет.

Answer 6

Я полагаю, что Java не хочет делать ничего, что зависит от платформы. В Windows пути к классам устанавливаются не так, как в LINUX / UNIX.