在罐子中执行包装好的罐子文件

Question

I am trying to create a wrapper around a runnable .jar file in order to pass parameters for the JVM. The related code of my wrapper is:

public static void main(String[] args) throws IOException
      String[] cmdArray = {"java",
        System.getProperty("os.arch").contains("64") ? "-d64" : "",
        "-XX:+AggressiveHeap",       
        "-jar",
        "/lib/A.jar"  //replace with jar name 
            };
      Runtime.getRuntime().exec(cmdArray);
}

The A.jar file is a referenced library (added in build path and class path) in my Wrapper project. Example:

 Wrap
   >src
       >org
           >Wrapper.java
   >lib
       >A.jar

When I create the second jar file, from the Wrapper project (lets call it B.jar), its content is

lib
   >A.jar
org
   >eclipse
          >jdt
             >... (i.e., all the files for the jarinjarloader)
   >Wrapper.class
META-INF
       >MANIFEST.MF

My manifest file from the second jar looks like this:

Manifest-Version: 1.0
Rsrc-Class-Path: lib/A.jar
Class-Path: .
Rsrc-Main-Class: org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader
Main-Class: org.Wrapper

When I launch the B.jar file, it shows me that the process started, but A.jar file is not called/launched. No error, no exception. The process starts and terminates. Tried to launch it via command line and double-click also.

If I modify the MANIFEST.MF file to

Rsrc-Class-Path: A.jar

and the element from cmdArray in the main method of the Wrapper.java from

"/lib/A.jar" to "A.jar"

and I make a copy of A.jar in the folder where my wrapper jar is present (eg, B.jar), it launches perfectly, calling the second jar. What am I doing wrong? How am I suppose to pass the class path to an inner jar file? Any help would be appreciated.

Answer 1

While this is not strictly speaking an answer to your question, I think I can propose you a better approach in solving your original problem (ie adding args to jvm).

This article discusses how to restart java app preserving jvm, command line and other launch options.

Why this might be interesting to you? Well, tweaking it a bit, what you can do is to get rid of adding wrapper around you main jar and do something like this in your main:

1. check for presence of some command line argument that tells that app is runned with tweaked vm options and:
2. if present - let the app to do it's work
3. in not - restart application, tweaking jvm options as well as passing command line argument referred in step 1

I've done something like this in one of my past projects and it helped to ease build/packaging and debugging compared to wrapped jar approach.

Hope this will be helpful.