Java 从另一个JVM中启动JVM-避免代码重复的坏主意？
我有一个Java控制台应用程序，它是从Windows中的批处理脚本和Linux中的shell脚本启动的。在这两种情况下，任何命令行参数（复杂的）都会简单地传递到java应用程序中，java应用程序使用ApacheCommonsCLI解释这些参数 现在我想允许用户为程序分配额外的内存。最简单的方法可能是对此有一个额外的参数（例如-m 1000），但也有缺点。批处理脚本和shell脚本现在都需要解释命令行，以便能够提取内存参数并将其用作JVM的-Xmx参数。这实际上意味着在3个位置（批处理/shell/java）满足参数解析的全部复杂性 想到的另一种方法是让脚本调用虚拟Java应用程序，该应用程序使用现有的解析逻辑来查找新参数，然后使用正确的内存上限（使用Runtime.exec（））派生另一个JVM来运行主应用程序。这将绕过代码重复问题Java 从另一个JVM中启动JVM-避免代码重复的坏主意？,java,command-line-arguments,runtime.exec,Java,Command Line Arguments,Runtime.exec,我有一个Java控制台应用程序，它是从Windows中的批处理脚本和Linux中的shell脚本启动的。在这两种情况下，任何命令行参数（复杂的）都会简单地传递到java应用程序中，java应用程序使用ApacheCommonsCLI解释这些参数 现在我想允许用户为程序分配额外的内存。最简单的方法可能是对此有一个额外的参数（例如-m 1000），但也有缺点。批处理脚本和shell脚本现在都需要解释命令行，以便能够提取内存参数并将其用作JVM的-Xmx参数。这实际上意味着在3个位置（批处理/shel
我的问题是——这对任何人来说都是个坏主意吗？也许有些问题我没有考虑 除非您需要非常高的性能，否则我认为还可以。在工作中，我们对类似的问题使用相同的方法：用户双击应用程序jar文件；然后，这个jar文件启动另一个具有适当内存量的进程（-Xmx512m） 需要考虑的事项：用户可以向类路径添加额外的jar文件吗？用户可以设置一个不同的JVM来使用吗？如果是的话，可能会很棘手。您还应该确保过程结束。您可能需要重定向输入流、输出流和错误流，可能需要使用单独的线程