I have a program that will create a child process, and I want it inherit all the classpath from its parent. In javadoc, it says:
public Process exec(String[] cmdarray,
String[] envp)
throws IOException
Executes the specified command and arguments in a separate process with the specified environment.
Given an array of strings cmdarray, representing the tokens of a command line, and an array of strings envp, representing "environment" variable settings, this method creates a new process in which to execute the specified command.
If envp is null, the subprocess inherits the environment settings of the current process.
When I set envp to null, it didn't inherit anything.
Here is the code:
System.out.print("Debug system path: "+System.getProperty("java.class.path"));
startTime();
Process proc = Runtime.getRuntime().exec(cmd,null);
I can see the path information, but these path information is not inherited by the new created process.
How did you specify the classpath of your application? If it was not through the CLASSPATH environment variable, it will not be inherited.
Runtime.exec method can invoke any native application, and the envp here refers to system environment, not your java environment.
If you want to pass your classpath to the child java process, you can do so explicitly:
String[] cmdarray = new String[] {
"java", "-classpath", System.getProperty("java.class.path"), "com.example.MyChildApp", "appParam"};
Process p = Runtime.getRuntime().exec(cmdarray);
No can do. Your 'classpath' at the time you call exec is whatever is hiding away in your current class loader at the time you call it. You can't, in general, ask a class loader to tell you the class path. It could be fetching classes from a database, or the planet Mars.
Reading java.class.path will tell you what was going on when your application started, but not what's going on at the time you go to launch something else.
Finally I have to insert "-cp System.getProperty("java.class.path")" into the cmd to make it work.
Is there any better way to do that?
Related
I am using the JDI to debug another running java application.
What I do that works:
Run two applications using Eclipse. The debugger is launched with the following VM Options:
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=4000
The other application connects to the socket at port 4000, and follows normal procedures (break points, etc.) to get a value of a Local Variable.
Works properly and gives me that value.
What I want to do now:
Instead of using Eclipse to launch two processes, I launch one in Eclipse, and that Process uses a ProcessBuilder to launch another one with the following arguments:
String[] args1 = {getJavaDir(),"-cp",classpath,"-Xdebug", "-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=4000", "processII.Main2"};
ProcessBuilder builder = new ProcessBuilder(args1);
builder.directory(directory);
Process process = builder.start();
The process starts successfully. However, when I try to access it through the first process, I get the following Error:
com.sun.jdi.connect.IllegalConnectorArgumentsException: Argument invalid
Looked this up online, and there is little information about what the Exception is.
I would appreciate any help figuring out what the problem is!
This exception is throw when there is an error on the connector parameters to debug the JVM. I think that your debug parameters must go in the same argument together instead of two separate arguments (put -Xdebug with -Xrunjdwp... on the same argument), try with:
String[] args1 = {getJavaDir(),"-cp",classpath,"-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=4000", "processII.Main2"};
ProcessBuilder builder = new ProcessBuilder(args1);
builder.directory(directory);
Process process = builder.start();
Hope this helps,
You missed this code :import com.sun.jdi.connect.IllegalConnectorArgumentsException;
It depends on the jdk/lib/tool.jar.If you add this jar to you classpath,you can fixout your problem.
So I'm creating a Java program and I want to make it so that you can ask it to open a program.
But, here's the catch, I want the program it opens to be taken from the user input, right now I'm trying to change this
try{Process p = Runtime.getRuntime().exec("notepad.exe");}
catch(Exception e1){}
Into something that opens a program that you asked it to open.
Here's an example of what I want:
User: Can you open chrome?
Program: Of course, here you go!
chrome opens
Could anyone tell me how I would be able to do this?
You can do it in two ways:
1.By Using Runtime:
Runtime.getRuntime().exec(...)
So, for example, on Windows,
Runtime.getRuntime().exec("C:\application.exe -arg1 -arg2");
2.By Using ProcessBuilder:
ProcessBuilder b = new ProcessBuilder("C:\application.exe", "-arg1", "-arg2");
or alternatively
List<String> params = java.util.Arrays.asList("C:\application.exe", "-arg1", "-arg2");
ProcessBuilder b = new ProcessBuilder(params);
or
ProcessBuilder b = new ProcessBuilder("C:\application.exe -arg1 -arg2");
The difference between the two is :
Runtime.getRuntime().exec(...)
takes a single string and passes it directly to a shell or cmd.exe process. The ProcessBuilder constructors, on the other hand, take a varargs array of strings or a List of strings, where each string in the array or list is assumed to be an individual argument.
So,Runtime.getRuntime.exec() will pass the line C:\application.exe -arg1 -arg2 to cmd.exe, which runs a application.exe program with the two given arguments. However, ProcessBuilder method will fail, unless there happens to be a program whose name is application.exe -arg1 -arg2 in C:.
You can try it with like. Pass whole path of where you install chrome.
try{
Process p = Runtime.getRuntime().exec("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe");
}
catch(Exception e1){
}
When using exec, it is essentially the same as if you were using the command line on windows. Open Command Prompt, type open, and see if it gives details as to how it opens files. If not, find the opener. Usually when dealing with command line operations, there are multiple parameters that are required for opening files/applications. An example of this would be for opening the "TextEdit.app" application on a mac.
Process p = Runtime.getRuntime().exec("open -a TextEdit.app");
Terminal(for mac) would open the app using the -a flag, meaning "application." You could open a file doing:
Process p = Runtime.getRuntime().exec("open filename.file_ext -a TextEdit.app");
The second one will tell the computer to find the application named <app_name>.app and open the file filename.file_ext
I know this is not going to work for a windows machine, but it's only to show how to use the command line operations for opening files and applications. It should be similar for windows though.
Hope this helps
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
How do I set environment variables from Java?
I'm trying to set an environment variable, and read it back to verify it was actually set.
I've got the following :
import java.io.IOException;
public class EnvironmentVariable
{
public static void main(String[] args) throws IOException
{
Runtime.getRuntime().exec("cmd.exe set FOO=false");
String s = System.getenv("FOO");
System.out.println(s);
}
}
However, it appears that FOO is always null, meaning its probably not set correctly.
Do I have the exec command correct? The javadocs state it can take a string argument as the command.
Any ideas?
There are overloaded exec methods in which you can include an array of environment variables. For example exec(String command, String[] envp).
Here's an example (with proof) of setting an env variable in a child process you exec:
public static void main(String[] args) throws IOException {
String[] command = { "cmd", "/C", "echo FOO: %FOO%" };
String[] envp = { "FOO=false" };
Process p = Runtime.getRuntime().exec(command, envp);
BufferedReader reader = new BufferedReader(new InputStreamReader(p.getInputStream()));
String s = reader.readLine();
System.err.println(s);
}
However, that sets the variable in the env of the created process, not of your current (Java) process.
Similarly, if you are creating a process from Ant (as you mention in comments to aix) using the exec task, then you can pass environment variables to the child process using nested env elements, e.g.
<exec executable="whatever">
<env key="FOO" value="false"/>
</exec>
This won't work. When you start a new process, that process receives a copy of the environment. Any changes it then makes to environment variables are made within that copy, and at no point will become visible to the caller.
What are you actually trying to achieve?
By running "cmd.exe", you start a new process, which receives the new environment variable, however the java process does not get that new environment variable set this way.
In Unix/Windows, each process has it's own set of environment variables and inherits the environment variables from it's parent during process creation.
System.getenv() only returns the environment variables that were set when the process was started, as far as I see there is no way to change the environment variables of the java process itself.
The only way you can check if the set works is by starting a small batch script where you set and do the check in one process.
It's null because you launch another cmd.exe: it's a different environment from the one of your Java application (cf aix answer).
I don't think the Java runtime can change an environment variable: it can read them, but can't change them.
If you want to change a system property available in your executing JVM, use System.setProperty(String key, String value).
I have written a java program named Automate.java, in which the another java program named newsmail will be executed.
The problem i face here is, Automate.java is in Desktop location(should be in desktop only always due to some requirements) and newsmail is in /home/Admin/GATE521/LN_RB this location.
What must be done before the below code, such that the command prompt automatically goes to the required folder and executes the program.
String command = "java newsmail";
Process child = Runtime.getRuntime().exec(command);
You can use this exec() :
Process child = Runtime.getRuntime().exec(command, null, new File("/home/Admin/GATE521/LN_RB"));
Resources :
javadoc - Runtime.exec()
Use the new ProcessBuilder class, instead of Runtime.exec().
ProcessBuilder pb = new ProcessBuilder("java", "newsmail");
pb.directory("/home/Admin/GATE521/LN_RB");
pb.start();
You can even look at pb.environment() to change environment variables if necessary.
is there a way to add a specific directory to the Windows systemvariable %PATH%?
This doesn't seem to work:
String[] cmd = { "cmd", "/c", "set", "PATH=\"%PATH%;c:\\test\"" };
Runtime.getRuntime().exec( cmd );
c:\test\ doesn't appear in System.getenv("PATH"); or in the output of
String[] cmd = { "cmd", "/c", "echo", "%PATH%" };
Runtime.getRuntime().exec( cmd );
What I need is to modify the %PATH%-variable for the current Java-Process under Windows. The reason is, that I need to load some native dll-files which cross-reference each other. So I'd like to add the application-path to the Windows environment.
The next thing I tried was a small JNI-Wrapper for the C-Function "putenv" which looks like this:
JNIEXPORT void JNICALL Java_com_splitscreen_AppletTest_PutEnv_putEnv
(JNIEnv *env, jobject jobj, jstring val) {
jboolean iscopy;
const char *mvalue = (*env)->GetStringUTFChars(
env, val, &iscopy);
putenv(mvalue);
}
This is how I call it:
final String curPath = System.getenv( "PATH" );
final PutEnv pe = new PutEnv();
pe.putEnv( "PATH=" + curPath + ";c:\test" );
final String newPath = System.getenv( "PATH" );
System.out.println( newPath );
But the pathes are equal. I'm not sure whether the Map of the Java-System-Environment isn't updated or whether putenv didn't work. Is there a way to check this?
The reason this doesn't work is that the two exec() invocations start two different shells; the one you set the path in isn't the one you check it in.
It's difficult to change the permanent, systemwide path setting. But you can change the path for the duration of the invocation of one or more programs that you need it for.
Specifically, the thing to do is to write yourself a batch file (.CMD or .BAT, as you please), set the PATH near the beginning, follow that with whatever DOS/Windows commands you'd like executed with that path, and then exec() that script file.
Updating the PATH for the current Java process seems pretty pointless. Java, once running, doesn't care about the path. Or are you running some library code that does?
If you are running DOS/Windows commands from Java using exec(), the above trick will work.
Update: OK, you have library code that for reasons of its own wants the PATH set just so, and you want to give it what it wants.
What I would consider here is to fire up a new JVM. You can use exec(cmd, envp) to start up a new Java application ("yourself," in a pinch) with a custom set of environment variables in envp. Just copy the ones that are already there and manipulate the contents of PATH, if any.
The standard way to start up a new Java app is to create a new ClassLoader, and there are various descriptions on how to accomplish that. But I'm not sure you can use that procedure to come up with a new environment - so exec-ing the JVM may not only be simpler, but possibly the only way.
This is not possible with just running a batch file. See here for details.
Your solution doesn't work, because it only modifies the environmental variable in the process level and not in system level.
You can pass paths to where the native libraries are located via the -Djava.library.path option if you are using JNI extensions, this may also work for your exec case. The other option is to launch the java app from a batch file and edit the PATH settings in the command interpreter "before" you launch the java app, the java app will inherit this PATH settings.
NASA WorldWind uses native libraries and can be run as an Applet, here is a howto on setting this up with JNLPAppletLauncher. What this basically does is detect the OS, fetch appropriate native libraries, save them in a location in default jvm path and execute. Calling exec from a Java applet violates all sorts of sane security and sandboxing principles and I would really avoid it.