На мой взгляд, большинство ответов здесь относительно разных архитектур Eclipse и Java просто ошибочны, и это можно легко проверить, например, Монитор процессов под Windows. Опция -vm
предназначена для запуска определенной версии java, и точка ее заключается в том, что сконфигурированный процесс запущен и сам запускает весь код Java, поэтому вы настраиваете до java.exe
. В этом случае вам не нужно иметь одну и ту же архитектуру для Eclipse и Java, но может с радостью смешивать 32 бит и 64 бит. Вы НЕ МОЖЕТЕ смешивать оба, если вы НЕ используете -vm
, но пусть Eclipse загружает Java изначально в свой собственный процесс с помощью jvm.dll и т. Д. Последнее поведение Eclipse по умолчанию, но не в том случае, если вы правильно настроили -vm
в eclipse.ini
.
Если вы мне не верите, сделайте некоторые тесты самостоятельно, используя разные архитектуры Eclipse и Java и настроить -vm
или не правильно. В конце концов, именно это вопрос, описанный в его комментарии к принятому ответу:
Не удается запустить Eclipse; JVM завершена. Код выхода = 13
Он говорит, что сейчас работает 64-битный JDK, но на его снимке экрана видно, что его Eclipse - 32 бит, потому что путь для launcher.library
равен 32 Бит.
И теперь по той причине, что я пришел сюда: у Оби моих клиентов возникли проблемы с загрузкой одного из наших приложений на основе Eclipse / OSGI, а Java вышло с кодом выхода 13. В итоге это показало, что проблема была не в -vm
, а в архитектуре Java и eclipse.exe
, но вместо этого он просто отсутствовал config.ini
, и я предполагаю, что eclipse.exe
не знал, что загрузить или что такое. После того, как мы это узнали и положили config.ini
на место, приложение загрузилось с использованием -vm
и 64-битного JRE7 в комбинации с 32-битным eclipse.exe
.