Для этого приложения требуется среда выполнения Java 11 что делать

Обновлено: 04.07.2024

Ваша заявка успешно отправлена! Закрыть

1. Обзор

Для запуска программ Java требуется среда выполнения Java (JRE). В настоящее время существует множество пакетов JRE, доступных в различных проектах и ​​компаниях, но два самых популярных в Ubuntu — это OpenJDK и Oracle HotSpot. Использование одного пакета вместо другого не должно создавать каких-либо функциональных различий в большинстве приложений; однако некоторые предпочитают OpenJDK Oracle HotSpot, поскольку первый не содержит компонентов с закрытым исходным кодом, имеет гораздо более четкую политику лицензирования и поддержки и поддерживается как часть архива Ubuntu, что упрощает установку и обновление.

В этом руководстве мы рассмотрим установку обоих пакетов JRE. Конечно, обычно вам нужно только выбрать тот, который лучше всего соответствует вашим потребностям и предпочтениям.

Что вы узнаете

  • Как установить OpenJDK JRE
  • Как установить Oracle HotSpot JRE

Что вам понадобится

Это все, что вам нужно. Если у вас есть это, давайте перейдем к следующему шагу!

2. Установка OpenJDK JRE

Поскольку каждые 6 месяцев выпускаются новые версии Java, для использования доступно несколько версий. В настоящее время Java 11 является текущей версией с долгосрочной поддержкой (LTS), но Java 8 по-прежнему широко используется. Более того, версии Java, отличные от LTS, привносят в язык стабильный поток инноваций, а также получают некоторое распространение.

Ubuntu предлагает пакет default-jre, который регулярно обновляется для предоставления последней версии текущей OpenJDK JRE в рамках долгосрочной поддержки (LTS). default-jre — отличный выбор для большинства ситуаций благодаря отличной обратной совместимости виртуальной машины Java.

(В качестве альтернативы вы можете использовать конкретную версию Java, используя, например, пакет openjdk-11-jre; по мере выпуска обновлений для этой версии виртуальной машины Java эти пакеты будут обновляться, позволяя к последнему и самому большому обновлению одной конкретной версии языка Java.)

Чтобы установить OpenJDK JRE, мы запускаем:

Мы можем проверить правильность установки OpenJDK JRE, запустив:

Должно быть выведено следующее:

(Хотя выходные данные могут измениться в будущем, когда новые версии Java будут переведены в статус LTS или текущая версия LTS получит обновления.)

На следующем шаге мы установим Oracle HotSpot JRE.

3. Установка Oracle HotSpot JRE

Загрузка двоичных файлов Oracle HotSpot JRE

Загрузите двоичные файлы JRE в формате .tar.gz (tarball), перейдя на их веб-сайт. Для загрузки Oracle HotSpot JRE требуется учетная запись Oracle.

В настоящее время Oracle не предлагает пакеты JRE для Java 11 или выше на своем веб-сайте, поэтому в этом руководстве мы будем использовать версию Oracle HotSpot JRE 8u291 (Java 8, обновление 291).

Java 11 не поставляется с JRE для загрузки, в отличие от предыдущих версий Java. Я получил сообщение об ошибке «нет среды выполнения Java» при запуске некоторого программного обеспечения на основе Java. Чтобы решить эту проблему, мне пришлось установить Java 8 JRE.

Как я могу заставить свой компьютер запускать Java 11 JRE, если больше нет загрузки JRE 11?

Я использую Windows 10.


4 ответа 4

Загрузите и используйте OpenJDK Java 11 JDK с сайта OpenJDK.

Загрузите и используйте Oracle Java 11 JDK с сайта Oracle . и убедитесь, что вы полностью понимаете ограничения на «коммерческое использование», которые теперь применяются к выпускам Oracle Java 11+.

Попробуйте создать собственную JRE для Windows из исходников OpenJDK; см. Создание jre из OpenJDK Windows. (Я бы не рекомендовал этого делать. Есть альтернативы получше.)

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

Обсудите с отделом продаж Oracle контракт на поддержку Java и, в частности, спросите, как получить сборку JRE. (Я не знаю, каким будет ответ. Если кто-то попытается это сделать и получит положительный ответ, пожалуйста, прокомментируйте!)

Используйте сторонний дистрибутив Java JRE.

Список поставщиков Java со временем меняется, но на данный момент в него входят AdoptOpenJDK, Amazon, Azul, BellSoft, IBM, jClarity, Red Hat и SAP. См. также: Разница между OpenJDK и Adoptium/AdoptOpenJDK

Некоторые из этих поставщиков предлагают дистрибутивы JRE. Проверьте их сайты загрузки.

Поскольку (почти) все поставщики Java основывают свои продукты на одной и той же стандартной кодовой базе OpenJDK, которая используется для Oracle Java, нет причин беспокоиться о стабильности сторонних JRE. Некоторые поставщики предлагают (платную) поддержку.

(Или переключиться с Windows на Linux.Я могу установить пакет OpenJDK Java 11 только для JRE из диспетчера пакетов дистрибутива в последних версиях Ubuntu, Fedora, . )

Для тех, кто считает, что Oracle Java 11 и OpenJDK Java 11 — это одно и то же, прочитайте следующее на сайте загрузки Oracle:

Обратите внимание, что Oracle сообщает, что лицензии для Oracle Java и OpenJDK Java различаются. (Несмотря на то, что они созданы на основе одного и того же исходного кода.) Игнорируйте это на свой страх и риск!

Я хотел бы добавить, что некоторые сторонние дистрибутивы JDK очень стабильны и хорошо себя зарекомендовали. Например, AdoptOpenJDK существует уже давно и поддерживается Amazon, Azul, IBM, Microsoft и Red Hat. Его можно считать почти таким же официальным, как и собственный дистрибутив Oracle.

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

Ответ Стивена С. правильный и важный.

Oracle больше не предлагает конечным пользователям устанавливать JRE или JDK. Java-апплеты в браузере и доставка приложений Java Web Start постепенно прекращаются, в результате чего конечный пользователь не нуждается в JRE. Ожидается, что приложения на основе Java будут включать в себя собственную реализацию Java. Единственными людьми, сознательно устанавливающими JDK, будут разработчики и серверные системные администраторы.

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

Вот блок-схема, которая может помочь вам найти и выбрать среди различных поставщиков, предоставляющих реализацию Java 11.

Блок-схема, которая поможет вам выбрать поставщика для реализации Java 11.jpg

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

Мотивы выбора поставщика Java

В комментариях был поднят вопрос о проблемах совместимости между выпусками разных поставщиков.

Во-первых, знайте, что проект OpenJDK включает обширный набор тестов, известный как Комплект совместимости технологий сообщества OpenJDK (TCK). Поставщики могут свободно заявлять о том, прошел ли их выпуск эти тесты. Эти утверждения не проверены и основаны на системе чести. На приведенной выше диаграмме я отметил флажком "TCK" несколько поставщиков, которые, как я знаю, заявили о себе: Oracle JDK от Oracle и Zulu от Azul Systems.

Все продукты, перечисленные в области синего прямоугольника на моей диаграмме выше, построены почти непосредственно на исходном коде OpenJDK. В общем, вы должны увидеть практически идентичную совместимость.

Есть две проблемы, которые могут вас беспокоить: технологические различия и график обновлений/исправлений.

Что касается технологических различий, поставщики, использующие проект OpenJDK, могут поставлять либо движок HotSpot, либо движок OpenJ9. Они будут различаться по производительности (более быстрый/медленный запуск по сравнению с общей скоростью, больше/меньше памяти), но их поведение с точки зрения соответствия спецификациям Java должно быть идентичным. Они могут различаться, и, конечно же, у одного из них может быть недостаток (который, скорее всего, скоро будет исправлен), которого не было у другого. Лично меня это не беспокоит, но я упоминаю об этом для полноты картины.

Другое технологическое отличие заключается в том, что Zing от Azul Systems использует другой тип JVM, а Oracle — GraalVM. Каждый из них может каким-то образом отличаться друг от друга или от других продуктов, потому что они намеренно имеют другой тип реализации JVM, чтобы предлагать специальные функции. Но, учитывая тщательность спецификаций Java, они не должны быть несовместимы. Если бы они были, вы могли бы ожидать, что любая проблема совместимости будет быстро решена. Если бы мне понадобились специальные функции любого из этих продуктов, я бы использовал их с полной уверенностью.

Еще одна возможная проблема – скорость, с которой поставщик может обновлять свои версии, добавляя исправления определенных ошибок или исправления для системы безопасности. Например, Oracle заявила, что оставляет за собой право немедленно отправлять любые готовые исправления своим клиентам, отправляя их на рассмотрение проекту OpenJDK. Конечно, любой из поставщиков, предоставляющих коммерческую поддержку, может поторопиться с исправлением или патчем для своих платных клиентов. Эти выпуски, созданные в качестве любезности для сообщества и предоставляемые бесплатно, могут обновляться дольше, вероятно, после того, как проект OpenJDK включил исправление/исправление.

Кроме того, каждый поставщик может по своему усмотрению модифицировать свой код, если он соответствует спецификациям Java. Например, команда Corretto в Amazon уже внесла улучшения в свой собственный выпуск, а затем поделилась этими изменениями с проектом OpenJDK. Может пройти некоторое время, прежде чем OpenJDK включит эти изменения, если они решат это сделать.Так что вполне возможно, что разные версии могут отличаться. Но на данный момент кажется, что все поставщики в сообществе Java искренне привержены совместной работе по предотвращению фрагментации. Так что, опять же, меня это не особо беспокоит, но упомяну об этом для полноты картины.

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

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

Текст был успешно обновлен, но возникли следующие ошибки:

прокомментировал Хендрикебберс 20 июля 2020 г.

Я предполагаю, что настройка JAVA_HOME — это не та часть, о которой здесь спрашивали. Если я правильно понимаю @dhamann, он хочет добавить mimetype JAR для выполнения, например, Java. Верно?

прокомментировал dhamann 20 июля 2020 г.

привет вам обоим, @aahlenst вы думаете в правильном направлении, @hendrikebbers вы тоже!

<р>. на самом деле я хотел бы иметь возможность делать то, что установщик делает с реестром, запустив утилиту, которая устанавливает значения для версии, которая распространяется с zip-файлом.

запуск jar с помощью двойного щелчка — это один вариант использования, другой — запуск исполняемого файла, созданного с помощью launch4j

@aahlenst Мне, вероятно, нужно будет сделать то, на что ты мне указал. для каждой установленной версии Java и для каждого следующего обновления снова? как другие люди, использующие заархивированный дистрибутив, справляются с этим? (пожалуйста, укажите мне лучшую цель для моего вопроса, если репозиторий openjdk-installer не подходит для этого, я просто не знаю, где спросить)

прокомментировал Хендрикебберс 20 июля 2020 г.

Похож ли scoop на домашнее пиво для Windows? У проекта 11 тысяч звезд на GitHub. Может стоит подумать о предоставлении скрипта для scoop?

прокомментировал Хендрикебберс 20 июля 2020 г.

прокомментировал Хендрикебберс 20 июля 2020 г.

прокомментировал dhamann 20 июля 2020 г.

хм. Я только что попробовал это с текущим установщиком. и это похоже на то, что я хочу все, кроме корневого узла :)

image

Можно ли поместить все подзаписи корневого узла во второй узел, который просто задает конфигурацию? Он может использовать предоставленный путь, как показано на скриншоте ниже (я просто нарисовал это как наводящую идею, текущий диалог также показан НИЖЕ для справки)
Идея для другого диалога (два корневых узла):

image

Текущий диалог (один корневой узел):

прокомментировал dhamann 20 июля 2020 г.

привет, @aahlenst, предоставленная информация в глубинной ссылке, наверное, только вершина айсберга, я полагаю? не нужна ли мне также какая-то регистрационная запись для каталога, на который указывают эти ключи? URL-адрес orcl, к сожалению, ничего подобного там не упоминает

Может ли установщик также создать Windows cmd / пакетные файлы, которые позволяют повторно выполнять те же самые команды настройки реестра для конкретной версии? (хотя я только что заглянул в douph1@c79c7e8, и это кажется довольно сложным :)) Спасибо, что потратили свое время на это решение, кстати. Кажется, действительно сложно найти «правильное» решение!

aahlenst прокомментировал 21 июля 2020 г.

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

Чего вы хотите достичь? Помимо применения «магии реестра» к ZIP-файлам? Вам нужно несколько версий Java и простой способ переключения между ними? Почему нельзя использовать MSI?

прокомментировал doph1 21 июля 2020 г.

Чтобы написать "Oracle Java Key", вы должны написать
только HKLM (требуется root)
Путь к ключу основан на:

  • Основная версия (1.8 или более поздняя)
  • JRE и JDK
  • узнайте, используете ли вы Wow > Wow6432Node

Но ключ нельзя заменять более старым ключом (всегда указывающим на последнюю/новейшую версию Java)

Поскольку это зависит от версии, предназначенной для установки и уже установленной, просто писать регистрационный ключ без двоичного файла бесполезно, а/или копировать/вставлять регистрационный ключ с одного хоста на другой — плохая идея.

.jar и .jnlp относятся к HKMU (переключение между hklm и hkcu в зависимости от установки компьютера или пользователя)

.jnlp применяется только к Java 8

Добавление/разделение функций установщика на две группы нарушит фактическую совместимость уровней функций. Так что нет

прокомментировал dhamann 21 июля 2020 г. •

Я еще не уверен, в чем именно заключается проблема. [. ]

Воспроизведение параметров реестра Windows, которые задаются установщиком после распаковки (вручную или с помощью такого инструмента, как scoop) zip-дистрибутива.

Чего вы хотите достичь? [. ] Вам нужно несколько версий Java и простой способ переключения между ними?

Почему нельзя использовать MSI?

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

прокомментировал dhamann 21 июля 2020 г. •

Чтобы написать "Oracle Java Key", вы должны написать в
[. ]
[. ]
.jnlp применяются только к Java 8

@douph1 спасибо за ваш вклад!

Добавление/разделение функций установщика на две группы нарушит фактическую совместимость уровня функций. Так что нет

снэп, идея понравилась :)

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

не могли бы вы предложить соответствующие ветки регистрации, которые я должен отслеживать на наличие изменений, @douph1 ? В настоящее время я создал следующий reg-файл . и сейчас пытаюсь переключить текущую версию. Но я, вероятно, недостаточно хорошо уловил картину.

а как насчет [HKLM\SOFTWARE\WOW6432Node\JavaSoft]? Мне нужны оба? (Win10 Pro x64)

Я начинаю бояться этой кроличьей норы.

Командный файл, поставляемый с zip-дистрибутивом, который устанавливает правильные записи, вероятно, также слишком сложен?

//последнее редактирование: извините за бурю правок. это закончилось сейчас.

прокомментировал dhamann 21 июля 2020 г.

Я пытался не указывать параметр FeatureMain при вызове msi-installer . так например:

мог бы сделать все, кроме установки файлов в целевой каталог. Но это не дало ожидаемого результата.

это сложно.

прокомментировал doph1 21 июля 2020 г.

а как насчет [HKLM\SOFTWARE\WOW6432Node\JavaSoft]? Мне нужны оба? (Win10 Pro x64)

нет. предназначен для Java 32 на Win 64

По умолчанию он отображается только на JavaSoft,
поэтому вы должны посмотреть/создать (в зависимости от версии Java)
"CurrentVersion" на

  • HKEY_LOCAL_MACHINE\Software\JavaSoft\ JRE
    или/и
  • HKEY_LOCAL_MACHINE\Software\JavaSoft\ Java Runtime Environment (для версии 1.8)
    и/или
  • HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\ JDK
    и/или
  • HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\ Java Development Kit (для версии 1.8)

прокомментировал doph1 21 июля 2020 г.

в системах под управлением Windows 8 или более поздней версии
... был введен новый раздел реестра, и теперь Windows записывает выбор пользователя в
"UserChoice"

HKEY_LOCAL_MACHINE или HKEY_CURRENT_USER

Подразделы реестра «Пути приложений» и «Приложения» используются для регистрации и управления поведением системы от имени приложений. Подраздел App Paths является предпочтительным расположением.

Я даже не уверен, что WIX/наше использование установщика WIX использует новый регистрационный ключ «Пути приложений»,
так как я уже видел, что ассоциация файлов .jar работает не всегда.

прокомментировал doph1 21 июля 2020 г.

прокомментировал dhamann 13 сентября 2020 г. •

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

Если вы думаете, что это (что-то исполняемое, которое будет включено в zip-архив) может быть создано . Должен ли я создать новую проблему с просьбой относиться именно к этому (и относиться к этой проблеме как к документированию мыслительного процесса)?

В первом посте я спросил

". Есть ли способ воспроизвести то, что делает установщик при создании необходимых записей реестра?"

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

@douph1 спасибо особенно за последние три подробных ответа! Благодаря вашему вкладу я теперь лучше понимаю особенности установки jre/jdk на стороне клиента Windows.Или приложения должны узнать о настроенных двоичных файлах Java для запуска.

Также спасибо всем, кто нашел время изучить этот вопрос. :)

aahlenst прокомментировал 14 сентября 2020 г.

Если вы действительно хотите, вы можете создать PowerShell или пакетный скрипт, который вносит изменения в реестр. Но почему? Если вам нужна такая автоматизация, MSI поможет вам и даже предоставит несколько мер безопасности, которые вам пришлось повторно реализовать в сценарии. С чем-то вроде scoop в миксе становится очень сложно, потому что вам нужно удалить/обновить эти записи. Это то, что должно решаться приложением, которое управляет вашими установками JDK.

Для протокола: я не думаю, что Scoop или аналогичный инструмент имеет смысл использовать файлы MSI. VS Code делает это, и, судя по сообщениям об ошибках, которые мы здесь получаем, это был неправильный выбор. Если ваш инструмент управляет версиями JDK, пусть ваш инструмент занимается реестром.


Поэтому я установил java с помощью brew install java и следовал инструкциям по символической ссылке и добавил его в свой .zsh PATH. Все выглядит хорошо для java в терминале:

<р>. но как я могу сообщить приложению jEdit, где находится моя JRE.

Я тоже пытался установить jedit через homebrew, но результат был тот же.

Если я запускаю jar-файл в командной строке, jedit запускается, хотя в терминале появляются следующие ошибки (значительные? Может быть, нет):

Это обходной путь, но я хочу иметь возможность щелкнуть значок приложения!

16.0.2 (x86_64) "Доморощенный" - "OpenJDK 16.0.2" /usr/local/Cellar/openjdk/16.0.2/libexec/openjdk.jdk/Contents/Home

Я хотел бы отметить, что сборка датируется сентябрём 2020 года и, таким образом, предшествует Apple Silicon и поэтому предназначена только для Intel — также com.apple.eawt подразумевает классы, предоставленные Apple — это будет Java 6 — я подозреваю, что jEdit просто плохо поддерживается на macOS — сообщайте об этих проблемах в систему отслеживания ошибок jEdit, но даты публикации в списке рассылки не обнадеживают

5 ответов 5

В приложениях для Mac есть файл info.plist, в который иногда можно вводить скрытые настройки.

Вы можете перейти к нему, щелкнув правой кнопкой мыши и сказав "Показать содержимое пакета". Вы должны увидеть каталог «Содержание» и иметь возможность редактировать файл «info.plist».

Какие хитрые настройки? Ну, я получил достаточно подсказок из этого сообщения на форуме jedit.

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

(Создает символическую ссылку с именем "openjdk")

Сделав это, мы можем добавить запись в info.plist следующего вида:

Возможно, не имеет значения, где в файле. Я поместил эти две строки выше JVMOptions

После этого я могу щелкнуть значок jedit в приложениях, чтобы запустить его!

Я установил Java 11 и jEdit через homebrew на MacOS Big Sur. Для меня это работает, чтобы потом запустить jEdit:

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

Конечно, если вы добавили эту конкретную версию Java в свой путь. Brew даже предлагает это, когда вы устанавливаете java 11 через brew, но я не хотел предполагать, что все, кто наткнулся на это, сделали это, и, как я сказал в своем ответе, эта длинная командная строка будет работать в любом случае.

Вопрос говорит о том, что они есть. Так что вы ДОЛЖНЫ это предположить. В любом случае, я думаю, что вопрос заключается в том, как открыть приложение, а не запускать его из командной строки

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

Просто для информации, так как опубликованное решение с Info.plist отлично работает для меня!

В любом случае, я искал что-то, что действовало бы глобально, например, конфигурацию или настройку (тоже хитрую :-)), которая позволяла бы открывать любое Java-приложение с пользовательским интерфейсом, не выдавая сообщение об ошибке:
"Для этого приложения требуется java 11. или более поздней версии на вашем компьютере."

  • MBA (Intel) с Big Sur 11.6.1
  • Домашнее пиво с openjdk и jEnv (macos-javahome)

1. Использование команды jEnv 'macos-javahome'

Целью было попробовать команду jEnv:


Во-первых, в Big Sur 11.6.1 в каталоге моего профиля нет папки ~/Library/LaunchAgents.
Я все равно создал его с правильными разрешениями, чтобы продолжить работу с jEnv, применить все изменения и перезапустить все, что вам нужно.

Конечным результатом является то, что этот параметр через jEnv полностью игнорируется UI Java-приложениями и по-прежнему выдает ошибку:
"Это приложение требует, чтобы на вашем компьютере была установлена ​​java 11 или более поздней версии".

==> Этот способ с jEnv и Big Sur 11.6.1 не работает.

2. Изменение OpenJDK для запуска приложений Java

Цель состояла в том, чтобы изменить OpenJDK Info.plist, добавив возможность BundledApp, как указано здесь и здесь.

Вкратце, в моей среде измените файл /Library/Java/JavaVirtualMachines/openjdk.jdk/Contents/Info.plist из этого

==> Также этот способ с модифицированным OpenJDK Info.plist и Big Sur 11.6.1 не работает.

Результаты

Попробовав, оба способа в настоящее время не работают в моей среде с Big Sur 11.6.1.

Это с jEnv не работает в отличие от того, что говорит команда jEnv macos-javahome. Здесь также кажется, что приложения пользовательского интерфейса Java полностью игнорируют переменную среды JAVA_HOME, независимо от того, установлена ​​ли она через оболочку (например, zsh) или jEnv macos-javahome .

Читайте также: