| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| java_class_process [2013/04/29 08:12] – yann | java_class_process [2025/01/15 21:40] (current) – external edit 127.0.0.1 |
|---|
| The Java class Process is used together with class Runtime. As explained by Oracle: "The Runtime.exec methods create a native process and return an instance of a subclass of Process that can be used to control the process and obtain information about it. The class Process provides methods for performing input from the process, performing output to the process, waiting for the process to complete, checking the exit status of the process, and destroying (killing) the process." (from the [[http://docs.oracle.com/javase/1.4.2/docs/api/java/lang/Process.html|Javadocs of version 1.4.2]]). | The Java class Process is used together with class Runtime. As explained by Oracle: "The Runtime.exec methods create a native process and return an instance of a subclass of Process that can be used to control the process and obtain information about it. The class Process provides methods for performing input from the process, performing output to the process, waiting for the process to complete, checking the exit status of the process, and destroying (killing) the process." (from the [[http://docs.oracle.com/javase/1.4.2/docs/api/java/lang/Process.html|Javadocs of version 1.4.2]]). |
| |
| Typically, in [[MoDeC]], we created and run a Process that executes a new Java virtual machine, which itself runs a program whose bytecodes we had instrumented to collect traces. Simply put: | Typically, in [[MoDeC]], we created and ran a Process that executes a new Java virtual machine, which itself runs a program whose bytecodes we had instrumented to collect traces. Simply put: |
| |
| <code> | <code> |
| String commandLine = ...; | final String commandLine = ...; |
| String absolutePathToInstrumentedFiles = ...; | final File absolutePathToInstrumentedFiles = ...; |
| |
| final Process process = | final Process process = |
| * commandLine is the complete command line to run a new Java virtual machine; | * commandLine is the complete command line to run a new Java virtual machine; |
| * new string[0] tells the Runime.exec() that we do not touch the environment; | * new string[0] tells the Runime.exec() that we do not touch the environment; |
| * absolutePathToInstrumentedFiles is the complete, absolute path to the root directory containing the instrumented bytecodes. | * absolutePathToInstrumentedFiles is a File pointing on the root directory containing the instrumented bytecodes. |
| |
| ===== The Bug ===== | ====== The Bug ====== |
| |
| When applying [[MoDeC]] on "small" program, we did not encounter any problem, neither on Windows nor on Mac OS. However, when Soumaya ran [[MoDeC]] on the instrumented version of ArgoUML v0.19.8, should got this exception (here reproduced using Venera's Mac): | When applying [[MoDeC]] on "small" programs, we did not encounter any problem, neither on Windows nor on MacOS. However, when Soumaya ran [[MoDeC]] on the instrumented version of ArgoUML v0.19.8, she got this exception (here reproduced using Venera's Mac): |
| |
| <code> | <code> |
| </code> | </code> |
| |
| which was very puzzling because the version of [[MoDeC]] and the same input file and the same instrumented bytecodes would work on Yann's Windows laptop and produce the expected traces. | which was very puzzling, because the //same// version of [[MoDeC]] and the //same// input file and the //same// instrumented bytecodes would work on Yann's Windows laptop and produce the expected traces. |
| |
| ===== The Solution ===== | ====== The Solution ====== |
| |
| After much tinkering, we decided manage to get [[MoDeC]] to work by using the "new" class ProcessBuilder because "As of 1.5, ProcessBuilder.start() is the preferred way to create a Process." (according to [[Oracle|http://docs.oracle.com/javase/7/docs/api/java/lang/Process.html]] in a version of the Javadocs subsequent to 1.5). We modified essentially the code as follows: | After much tinkering, we managed to get [[MoDeC]] to work by using the "new" class ProcessBuilder because "As of 1.5, ProcessBuilder.start() is the preferred way to create a Process." (according to [[http://docs.oracle.com/javase/7/docs/api/java/lang/Process.html|Oracle]] in a version of the Javadocs subsequent to 1.5). We modified essentially the code as follows: |
| |
| <code> | <code> |
| </code> | </code> |
| |
| ===== Acknowledgements ===== | With these changes, the same input file and the same instrumented bytecodes would produce the same, expected traces in both Windows and MacOS computers! Soumaya and Venera could now continue their research works 8-). However, these changes were not satisfying because they did not explain why... |
| | |
| | So, after some more tinkering, it appeared that it is **not** ProcessBuilder that saved the day but the implementations of the Runtime.exec() methods that have different behaviour on Windows and MacOS. The class Runtime provides several exec() methods to create new processes but two are of particular interest here: |
| | - Runtime.exec(String command, String[] envp, File dir): "Executes the specified string command in a separate process with the specified environment and working directory." |
| | - Runtime.exec(String[] command, String[] envp, File dir): "Executes the specified command **and arguments** in a separate process with the specified environment and working directory." (bold added). |
| | |
| | In previous versions of [[MoDeC]], we used the first method, e.g., in the case of ArgoUML with the following command: |
| | |
| | <code> |
| | final String command = "java -classpath "/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/MoDeC Invoker/bin:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/pdf-transcoder.jar:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/batik-anim.jar:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/batik-bridge.jar:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/batik-codec.jar:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/batik-extension.jar:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/batik-gui-util.jar:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/batik-gvt.jar:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/batik-script.jar:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/batik-swing.jar:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/batik-transcoder.jar:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/batik-parser.jar:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/batik-css.jar:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/batik-svg-dom.jar:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/batik-ext.jar:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/commons-lang-2.4.jar:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/bin:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/tools.jar:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/xalan-2.6.0.jar:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/xerces_2_5_0.jar:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/xml-apis.jar:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/xml-apis-ext.jar:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/cfparse:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/bcel:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/batik-awt-util.jar:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/batik-dom.jar:/Users/Neni/Documents/Research/2013-LabalingTraceSegm/eclipseWS/CPL/lib/batik-svggen.jar:/Users/Neni/Documents/ |