我尝试了很多方法，并将-VM参数放在建议的位置。但这行不通。最后我找到了解决办法。在执行任何插件或jar之前，vm args应该放在eclipse.ini文件中。我尝试了ubuntu 18.04中最新的eclipse [Photon]，它非常适合我。

-startup
-vm        
/usr/local/java/jdk1.8.0_251/bin/java.exe
plugins/org.eclipse.equinox.launcher_1.5.700.v20200207-2156.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.1100.v20190907-0426
-product
org.eclipse.epp.package.jee.product
-showsplash
org.eclipse.epp.package.common
--launcher.defaultAction
openFile
--launcher.defaultAction
openFile
--launcher.appendVmargs
-vmargs
-Dosgi.requiredJavaVersion=1.8
-Dosgi.instance.area.default=@user.home/eclipse-workspace
-XX:+UseG1GC
-XX:+UseStringDeduplication
--add-modules=ALL-SYSTEM
-Dosgi.requiredJavaVersion=1.8
-Dosgi.dataAreaRequiresExplicitInit=true
-Xms256m
-Xmx2048m
--add-modules=ALL-SYSTEM

Eclipse:

在eclipse.ini中添加了这两行

第二行表示javaw.exe文件的JDK位置。

虚拟机 C:\Program Files\Java\ jdk1.7.0_60 \ bin \ javaw.exe

注意:将-vm行放在-vmargs之前，否则采用默认位置。

为STS

在STS.ini中进行如上更改

在我的情况下，我安装Java 64位，并使用64位eclipse，错误消失了。你可以这样组合

64位Java - 64位系统- 64位eclipse 32位Java - 32位系统- 32位eclipse 32位Java - 64位系统- 32位eclipse

在所有这些情况下，我们永远不会看到这个错误。

In my opinion the most answers here regarding different architectures of Eclipse and Java are simply wrong and this can be easily checked using e.g. Process Monitor under Windows. The -vm option is there to run a specific version of java and the point of it is, that the configured process is started and runs all the Java code on its own, that's why you configure up to java.exe. In that case you DON'T need to have the same architecture for Eclipse and Java, but can happily mix both 32 Bit and 64 Bit. You only CAN'T mix both, if you DON'T use -vm, but let Eclipse load Java natively into its own process using jvm.dll and such. That latter behavior is Eclipse's default, but not the case anymore if you properly configure -vm in eclipse.ini.

如果你不相信我，你可以自己用Eclipse和Java的不同体系结构做一些测试，并正确地配置-vm。最后，这正是提问者在对公认答案的评论中所描述的:

不能运行Eclipse;JVM终止。退出代码= 13

他说64位JDK现在正在工作，但在他的截图中可以看到他的Eclipse是32位的，因为启动器的路径。库是32位的。

And now for the reason I came here: Ony of my customers had some problems loading one of our Eclipse/OSGI based applications as well and Java exited with exit code 13. In the end it showed that the problem was not about -vm or the architectures of Java and eclipse.exe, but instead he was simply missing config.ini and I guess eclipse.exe wasn't aware what to load or such. After we recognized that and put a config.iniback in place, the app loaded fine with using -vm and a 64 Bit JRE7 in combination with a 32 Bit eclipse.exe.

我刚遇到同样的问题，花了大约一个小时来解决这个问题。 最后它是路径中的“#”字符。

因此，我将“C:\# IDE\eclipse 3.7\”重命名为“C: + IDE\eclipse 3.7\”，这就解决了问题。

使用下面的配置;

    -startup
    plugins/org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar
    --launcher.library
    plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.200.v20130807-1835
    -product
    org.springsource.ggts.ide
    --launcher.defaultAction
    openFile
    --launcher.XXMaxPermSize
    256M
    -vm
    C:\Program Files\Java\jdk1.7.0_51\jre\bin\javaw.exe
    -vmargs
    -Dorg.eclipse.swt.browser.IEVersion=10001
    -Dgrails.console.enable.interactive=false
    -Dgrails.console.enable.terminal=false
    -Djline.terminal=jline.UnsupportedTerminal
    -Dgrails.console.class=grails.build.logging.GrailsEclipseConsole
    -Dosgi.requiredJavaVersion=1.6
    -Xms40m
    -Xmx768m
    -XX:MaxPermSize=256m
    -Dorg.eclipse.swt.browser.IEVersion=10001