Summary
1. I am import java.io.console,i am not getting any error in my code,
code is correct, I thought, It's getting some error in eclipse
software... Error :
Exception in thread "main" java.lang.NullPointerException at
loops.Escapey.main(Escapey.java:9)
Coding:
package loops;
import java.io.Console;
public class Escapey {
public static void main(String[] args) {
Console ar = System.console(); // creating a new object for console
String name = ar.readLine("how old are you ?"); //reads a user input
System.out.printf("%s - pretty age",name);
}
}
Ouput :
- I except the output how old are you ?? 18 18 - pretty age
But the actual output is getting error... Exception in thread "main"
java.lang.NullPointerException at loops.Escapey.main(Escapey.java:9)
I assume you are running this into some IDE. Since System.console returns the attached console, if you run it into IDE, it will return NULL. The better approach is to use Scanner class. If you really want to use System.console, you will have to test it on some console. If on Mac, run the terminal. On Linux any of the terminal apps would work.
If we run this in IDE (Intellij), it is throwing null pointer exception. Since this is related to console, I tried to execute this in command line and it works fine.
Execute these steps in terminal or command line and it will work
1) javac Escapey.java
2) java Escapey
Trying out Apache procrun I see a behaviour that I do not understand. It boils down to the main method of the Java program throwing an exception. This is not logged anywhere and the Windows service does not stop. To investigate further I changed the main method to
public static void main(String[] args) throws Exception {
if (args.length<10000000) {
throw new Exception("one exception right away");
}
...
}
When I install this as a service with prunsrv.exe and then start it, it starts without problems and produces no log output whatsoever. In particular the service does not stop.
For reference, here is how the service is installed with procrun:
& $procrun "//$operation//$service" `
--DisplayName="$service" `
--Description="$service" `
--DependsOn="$depends" `
--Startup=auto `
--Install="$procrun" `
--Jvm="$JVM" `
--Classpath="$cp" `
--Environment="PATH=$env:JAVA_HOME\bin" `
--JavaHome="$env:JAVA_HOME" `
--StartPath="c:\Search" `
--JvmOptions="-Xmx512M;-Xms512M;-Djava.awt.headless=true" `
--StartMode="jvm" `
--StartClass="$classname" `
--LogPath="c:\Search\std-logs" `
--LogPrefix="procrun-$service" `
--LogLevel="Debug" `
--StdError="c:\Search\std-logs\stderr-$no0" `
--StdOutput="c:\Search\std-logs\stdout-$no0" `
--StartParams="(unused)"
I would have expected that the service stops right away and I find some log output in the stderr/stdout files, but nothing. Can anyone explain this?
EDIT: Oh my, it seems like procrun swallows java.lang.Error (in my case java.lang.noClassDefFoundError) instead of screaming, shouting and exiting.
After I wrapped a catch(Throwable) around the main, logging whatever popped out and then exiting without re-throwing, I saw the problem. I got a java.lang.NoClassDefFoundError.
Bottom line: procrun seems to swallow error type exceptions and does not even terminate if one is thrown in the called Java program.
Created an issue: https://issues.apache.org/jira/browse/DAEMON-344
In an effort to make my app more OSX friendly, I am trying to set the dock name of my program to something like MyApp instead of a fully qualified class name (the default), such as myproject.mypackage.mysubpackage.myclass. Obviously, the first is much more appealing.
To do this, I use the OSX -Xdock:name command as a command line option when executing my .jar file. So to execute it, the command might look something like java -Xdock:name=MyApp -jar /mypath/myjar.jar. This works perfectly and sets the .jar's dock name to MyApp. But the issue is that this .jar will never be executed via command line and will be a double-clicked runnable .jar with a GUI display.
The only way I have thought of to set this command line option programmatically is to have a second class execute the class that actually starts the program. So something like this:
public class AppStarter {
public static void main(String[] args) {
String cmd = "java -Xdock:name=MyApp -cp myproject/mypackage/AppBuilder";
try {
Runtime runtime = Runtime.getRuntime();
runtime.exec(cmd);
} catch(IOException ex) {
//Display error message
}
}
}
public class AppBuilder {
public static void main(String[] args) {
//Start actual program and build GUI display
}
}
So here, AppStarter sets the command line options for AppBuilder, which when executed, has the dock name MyApp. The problem I see with this is that it is very tightly coupled. If for some reason the command line is inaccessible on the device or some IOException keeps getting thrown, literally nothing will happen with the program and it will be dead. There would be no way for the average computer user to recover from this.
So I'm wondering if it is possible to perhaps set these command line options after the .jar has already started executing. The old way to programmatically set the app's name has been ineffective for several OSX updates, so I'm stuck with only this command line option. Thanks for any advice.
Once the java command is executed, the command line arguments are parsed and set for the running JVM. You cannot change it any more.
This is usually handled by execution scripts (bash, etc.). If you cannot use them, you can use your approach, but the biggest disadvantage is that it will be running in a separate process.
I have the ubiquitous HelloWorldApp.java file
/**
* The HelloWorldApp class implements an application that
* simply prints "Hello World!" to standard output.
*/
class HelloWorldApp {
public static void main(String[] args) {
System.out.println("Hello World!");
}
}
I run:
javac HelloWorldApp.java
then I run:
jdb HelloWorldApp
I get:
Initializing jdb ...
>
I type:
stop at HelloWorldApp.main:7
where prompted
then I get
Deferring breakpoint HelloWorldApp.main:7.
It will be set after the class is loaded.
>
I type:
run
where prompted
then I get
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
>
VM Started: Hello World!
The application exited
I didn't type anything on that last prompt it just exited without breaking. My question is why did it output those Throwable lines and why didn't the debugger stop at the breakpoint I gave it?
I just checked the syntax for stop in JDB Documentation
stop in <class-name>.<method-name> Stop on entry to the given method.
stop at <class-name>:<line-number> Stop at the given line.
I think you command for stop should be either one of the following
stop in HelloWorldApp.main
stop at HelloWorldApp:7
Give it a try to see that fixes your issue!
I am working on a program written in Java which, for some actions, launches external programs using user-configured command lines. Currently it uses Runtime.exec() and does not retain the Process reference (the launched programs are either a text editor or archive utility, so no need for the system in/out/err streams).
There is a minor problem with this though, in that when the Java program exits, it doesn't really quit until all the launched programs are exited.
I would greatly prefer it if the launched programs were completely independent of the JVM which launched them.
The target operating system is multiple, with Windows, Linux and Mac being the minimum, but any GUI system with a JVM is really what is desired (hence the user configurability of the actual command lines).
Does anyone know how to make the launched program execute completely independently of the JVM?
Edit in response to a comment
The launch code is as follows. The code may launch an editor positioned at a specific line and column, or it may launch an archive viewer. Quoted values in the configured command line are treated as ECMA-262 encoded, and are decoded and the quotes stripped to form the desired exec parameter.
The launch occurs on the EDT.
static Throwable launch(String cmd, File fil, int lin, int col) throws Throwable {
String frs[][]={
{ "$FILE$" ,fil.getAbsolutePath().replace('\\','/') },
{ "$LINE$" ,(lin>0 ? Integer.toString(lin) : "") },
{ "$COLUMN$",(col>0 ? Integer.toString(col) : "") },
};
String[] arr; // array of parsed tokens (exec(cmd) does not handle quoted values)
cmd=TextUtil.replace(cmd,frs,true,"$$","$");
arr=(String[])ArrayUtil.removeNulls(TextUtil.stringComponents(cmd,' ',-1,true,true,true));
for(int xa=0; xa<arr.length; xa++) {
if(TextUtil.isQuoted(arr[xa],true)) {
arr[xa]=TextDecode.ecma262(TextUtil.stripQuotes(arr[xa]));
}
}
log.println("Launching: "+cmd);
Runtime.getRuntime().exec(arr);
return null;
}
This appears to be happening only when the program is launched from my IDE. I am closing this question since the problem exists only in my development environment; it is not a problem in production. From the test program in one of the answers, and further testing I have conducted I am satisfied that it is not a problem that will be seen by any user of the program on any platform.
There is a parent child relation between your processes and you have to break that.
For Windows you can try:
Runtime.getRuntime().exec("cmd /c start editor.exe");
For Linux the process seem to run detached anyway, no nohup necessary.
I tried it with gvim, midori and acroread.
import java.io.IOException;
public class Exec {
public static void main(String[] args) {
try {
Runtime.getRuntime().exec("/usr/bin/acroread");
} catch (IOException e) {
e.printStackTrace();
}
System.out.println("Finished");
}
}
I think it is not possible to to it with Runtime.exec in a platform independent way.
for POSIX-Compatible system:
Runtime.getRuntime().exec(new String[]{"/bin/sh", "-c", "your command"}).waitFor();
I have some observations that may help other people facing similar issue.
When you use Runtime.getRuntime().exec() and then you ignore the java.lang.Process handle you get back (like in the code from original poster), there is a chance that the launched process may hang.
I have faced this issue in Windows environment and traced the problem to the stdout and stderr streams. If the launched application is writing to these streams, and the buffer for these stream fills up then the launched application may appear to hang when it tries to write to the streams. The solutions are:
Capture the Process handle and empty out the streams continually - but if you want to terminate the java application right after launching the process then this is not a feasible solution
Execute the process call as cmd /c <<process>> (this is only for Windows environment).
Suffix the process command and redirect the stdout and stderr streams to nul using 'command > nul 2>&1'
It may help if you post a test section of minimal code needed to reproduce the problem. I tested the following code on Windows and a Linux system.
public class Main {
/**
* #param args the command line arguments
*/
public static void main(String[] args) throws Exception {
Runtime.getRuntime().exec(args[0]);
}
}
And tested with the following on Linux:
java -jar JustForTesting.jar /home/monceaux/Desktop/__TMP/test.sh
where test.sh looks like:
#!/bin/bash
ping -i 20 localhost
as well as this on Linux:
java -jar JustForTesting.jar gedit
And tested this on Windows:
java -jar JustForTesting.jar notepad.exe
All of these launched their intended programs, but the Java application had no problems exiting. I have the following versions of Sun's JVM as reported by java -version :
Windows: 1.6.0_13-b03
Linux: 1.6.0_10-b33
I have not had a chance to test on my Mac yet. Perhaps there is some interaction occuring with other code in your project that may not be clear. You may want to try this test app and see what the results are.
You want to launch the program in the background, and separate it from the parent. I'd consider nohup(1).
I suspect this would require a actual process fork. Basically, the C equivalent of what you want is:
pid_t id = fork();
if(id == 0)
system(command_line);
The problem is you can't do a fork() in pure Java. What I would do is:
Thread t = new Thread(new Runnable()
{
public void run()
{
try
{
Runtime.getRuntime().exec(command);
}
catch(IOException e)
{
// Handle error.
e.printStackTrace();
}
}
});
t.start();
That way the JVM still won't exit, but no GUI and only a limited memory footprint will remain.
I tried everything mentioned here but without success. Main parent Java process can't quit until the quit of subthread even with cmd /c start and redirecting streams tu nul.
Only one reliable solution for me is this:
try {
Runtime.getRuntime().exec("psexec -i cmd /c start cmd.cmd");
}
catch (Exception e) {
// handle it
}
I know that this is not clear, but this small utility from SysInternals is very helpful and proven. Here is the link.
One way I can think of is to use Runtime.addShutdownHook to register a thread that kills off all the processes (you'd need to retain the process objects somewhere of course).
The shutdown hook is only called when the JVM exits so it should work fine.
A little bit of a hack but effective.