Почему Eclipse использует встроенную пусковую установку?

Eclipse IDE - один из лучших примеров огромного настольного приложения, написанного на Java.

Большинство приложений Java, которые я видел, обычно полагаются на пакет или оболочку script для создания строки с пути класса приложения и запускают JVM с помощью пути класса как переменной env.

Eclipse, с другой стороны, полагается на собственную пусковую установку. Почему это? Что делает эта пусковая установка такими сценариями?

Я помню, как читал статью около полутора лет назад, в которой объяснялось, что "нам лучше с родной пусковой установкой", но id не объяснил внутреннюю работу пусковой установки.

Ответ 1

Equinox launcher использует JNI для запуска виртуальной машины Java в том же процессе, что и пусковая установка. Использование JNI также позволяет нам использовать виджеты SWT в заставке.

На самом деле вы все еще можете иметь script, так как исполняемый файл запуска, eclipse.exe, был разбит на 2 части с 3.3M5:

исполняемый файл и
общая библиотека (например: eclipse_1006.dll).

Исполняемый файл находится в корне установки eclipse.
Общая библиотека находится в определенном платформе фрагменте org.eclise.equinox.launcher.[config] в каталоге плагинов.

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

Как объяснено здесь, вы можете запустить Eclipse 3.3 без встроенного запуска,

java -jar plugins/org.eclipse.equinox.launcher_1.0.0.v20070319.jar

Обратите внимание, что имя jar файла теперь зависит от версии, вызывая наивные скрипты, которые вызывают банку с использованием точного имени файла, чтобы сломаться после обновления файла jar файла.

Вместо этого вы можете искать файл, соответствующий org.eclipse.equinox_*.jar. К счастью, Eclipse-wiki содержит соответствующие шаблоны сценариев, которые полезны в этом случае.
Если вы хотите избежать изменения существующих сценариев, вы также можете найти плагин Equinox Launcher, скопировать его в основной каталог Eclipse и переименовать его в startup.jar.

Ответ 2

Некоторые из них относятся к конкретным окнам, некоторые из них являются общими.

Интеграция вашей оболочки значительно улучшена по сравнению с пакетом script в исходно доступном языке сценариев вашей целевой платформы.
Нет необходимости запускать дополнительный процесс для выполнения script (это может быть большой проблемой, если вы сами скриптируете IDE как часть цикла сборки/тестирования/развертывания.
Обычно исполняемые заголовки определяют "битту" вашей программы. Таким образом, исполняемый файл может явно указывать, что он разрешает/запрещает выполнение 32 или 64 бита.
Исполняемые файлы в Windows могут быть криптографически подписаны.
Многие программы защиты от вредоносных программ/брандмауэров поддерживают исполняемые белые списки. Как таковой, гораздо приятнее при запуске eclipse (и он проверяет себя на обновления в Интернете) в первый раз, когда появляется всплывающее окно "Eclipse пытается получить доступ к Интернету", а не общий "javaw.exe пытаясь получить доступ к Интернету". Это также позволяет пользователю более точно контролировать этот тип поведения.
Процесс будет отображаться в ps/task manager как "you_app_name", а не java -jar "ваш файл jar". Это упрощает отслеживание/управление ошибочными процессами. Что-то не так необычно в настройках разработки.

Ответ 3

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

Конечный пользователь не должен беспокоиться ни о чем, чтобы заставить его работать. (Да, вы можете спорить с ним, если хотите использовать другую виртуальную машину или передать аргументы vm и т.д., Но вы НЕ ИМЕЕТЕ).

Там больше ничего не нужно для пользователя, чем для установки программы, а затем попробуйте запустить ее, только чтобы получить поле dos, в котором говорится: "Введите путь к вашему java vm", или, что еще хуже, вы дважды щелкните по нему, и ничего не происходит потому что вам нужно отредактировать командный файл, чтобы он работал.

Это 2009 год, а не 1996 год. Ни один пользователь (даже разработчики!) не должен будет редактировать пакетные файлы, чтобы программа запускалась в первый раз.