title: Launching JVM from within another JVM - Bad idea for avoiding code duplication?
body: <p>I have a Java console application that is launched from a batch script in Windows and a shell script in Linux. In both cases, any command-line arguments (which are complex) are simply passed into the java app, which interprets them using Apache Commons CLI.</p>
  
  <p>Now I want to allow users to allocate additional memory to the program. The simplest approach might be to have an additional argument for this (e.g. -m 1000), but there are drawbacks. Both the batch and shell scripts would now need to interpret the command line so they can pluck out the memory argument and use it as an -Xmx parameter for the JVM. This effectively means catering for the full complexity of argument parsing in 3 places (batch/shell/java).</p>
  
  <p>The only other approach that springs to mind is to have the scripts call a dummy Java application, which uses the existing parsing logic to find the new argument, then fork another JVM to run the main application, using the correct memory ceiling (using Runtime.exec()). This would get around the code duplication issue.</p>
  
  <p>My question is - does this seem like a bad idea to anyone? Perhaps there are issues I'm not considering. </p>