По моему мнению, большинство ответов здесь, касающихся различных архитектур Eclipse и Java, просто неверны, и это легко проверить, например, с помощью Process Monitor под Windows.Опция -vm
предназначена для запуска определенной версии Java, и смысл в том, что настроенный процесс запускается и выполняет весь код Java самостоятельно, поэтому вы настраиваете до java.exe
.В этом случае вам НЕ необходимо иметь одинаковую архитектуру для Eclipse и Java, но вы можете успешно смешивать 32-битные и 64-битные.Вы только НЕ МОЖЕТЕ смешивать оба, если вы НЕ используете -vm
, но позволяете Eclipse загружать Java непосредственно в свой собственный процесс, используя jvm.dll и т.п.Это последнее поведение по умолчанию в Eclipse, но это не так, если вы правильно настроили -vm
в eclipse.ini
.
Если вы мне не верите, проведите несколько тестов самостоятельно, используя различные архитектуры Eclipse иЯва и настроить -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
.