intellij run vs debug configuration has different args input paramter

Answered

Same as stackoverflow question: http://stackoverflow.com/questions/35662978/intellij-run-vs-debug-configuration-has-different-args-input-paramter

Intellij 15.0.3
Main class: xxx.project.Boot
VM args: -cp xxx.jar -Dxxx.work.dir=yyy xxx.project.Boot
Program arguments: dump_args

Project Code

public static void main (String[] args) Throwable {
   // first line in the Main entry point of the program
   for (int i = 0; i < args.length; i++){
      System.out.println("args["+i+"] = "+args[i]);
   }
   ...
}

Run output:

args[0] = -Didea.launcher.port=7536
args[1] = -Didea.launcher.bin.path=/home/dev/Software/idea-IU-143.1821.5/bin
args[2] = -Dfile.encoding=UTF-8
args[3] = com.intellij.rt.execution.application.AppMain
args[4] = xxx.project.Boot
args[5] = dump_args

Debug output:

args[0] = -Dfile.encoding=UTF-8
args[1] = xxx.project.Boot
args[2] = dump_args

I have tried to invalid cache and restart Intellj. The behavior in this case does not change. When I tried to create another entry point using the same code, the behavior is as expected. How can I debug this type of configuration problem?

5 comments
Comment actions Permalink

What's in xxx.jar? Can you share a sample project to reproduce? Overriding the default app classpath may be not a good idea.

0
Comment actions Permalink

Hi Serge, 

   Our project is has some simple based upon Java chord project. http://www.cc.gatech.edu/~naik/chord.html

The source code is available here. http://jchord.googlecode.com/files/chord-src-2.1.tar.gz

Instructions on how to run the application is here: http://pag-www.gtisc.gatech.edu/chord/user_guide/start.html#id4

 

Inside the instruction, we are given 

java -cp <CHORD_MAIN_DIR>/chord.jar -D<key1>=<val1> ... -D<keyN>=<valN> chord.project.Boot

 

This is definitely one of the most unconventional programs I have configured with Intellij. I have tried the following: 

1) Main class: xxx.project.Boot
VM args: -cp xxx.jar -Dxxx.work.dir=yyy xxx.project.Boot
Program arguments: dump_args

2) Main class: xxx.project.Boot
VM args: -cp xxx.jar -Dxxx.work.dir=yyy 
Program arguments: dump_args xxx.project.Boot 

Both gives very strange behavior. I agree that overriding the default application classpath is unconventional.

 

Side note/question: 

What makes this project even worse for debugging is that the "chord.project.Boot" entry point and "chord.project.Main" entry point uses different classpath. Chord.project.Boot uses ProcessExecutor.execute to launch chord.project.Main with different VMArgs and paramters. For all run and debugging sessions, the current process is to break the program into two parts and run them separately by dumping out the VMargs and parameters generated by chord.project.Boot and feed them into chord.project.Main through intellij. The generated VMArgs for chord.project.Main consists of about 500-4000 words! It's very easy to make copy and paste mistakes! 

Is there anyway to automatically use the return value of one run/debug session for chord.project.Boot and feed it into the VMArgs for chord.project.Main? Is there a better way to work with this kind of project configurations? If not is there a good way to change the program such that it's IDE/debugger friendly? 

 

0
Comment actions Permalink

You can create your own startup class that will run Boot to get the parameters and then run Main class with these parameters, run without overriding classpath so that all the classes are in the single classpath.

0
Comment actions Permalink

1

Hi Serge,

     I forgot to mention this important thing earlier that the classpath for Main is also generated by chord.program.Boot. The classpath is generated by Boot by reading one of the variable inside a configuration file provided by the user (may change frequently). Therefore there is no way to know the entire classpath of main beforehand without doing some processing (essentially what java.chord.Boot is doing). The problem right now is that after a new JVM is spawned from Boot using new classpath and VMargs, I am not sure if there is a way to debug the "spawned" program without resorting to manually connecting a remote debugging session. 

 

0
Comment actions Permalink

I guess Remote debug is the only way to debug it properly without implementing some custom launcher.

0

Please sign in to leave a comment.