Difference between running a java application as jar or via batch file?Hi,
Hi,
I'm facing some strange differences in the behavior of my application , only caused by different methods to execute the application . So I have know the potential difference between these methods to locate the error.
1) running my application it with java -jar
(via batch-file or command-prompt) or in eclipse works fine
2) executing the jar by double click causes problems.
The difference I know are that you can easily pass arguments to jvm, when using the jar.Maybe there is a differences in thread scheduling, but I'm not sure about that.
Can anyone tell me, the differences between these to methods of execution?
Thanks a lot in advance.
Greetings Michael
[722 byte] By [
Urmecha] at [2007-11-26 19:28:10]
By the way , I'm using WinXP. Problem is caused by Java 5 and 6.Greetings Michael
When you call the JAR from the command line then you generally specify the classpath and any arguments. Double clicking on the JAR will use the default classpath or arguments that are specified in your Java console.
Try going to Control Panel and looking at your Java console to see what kind of parameters (if any) are being passed by default.
Please be descriptive about what you mean by "Strange behavior"
For starters, there is no mention of batch files in this thread.
1. By launching from the command prompt, you can choose a JVM other then your default JVM.
2. You can specify other jar dependencies in your jar/META-INF/Manifest.mf file.
3. You can place JVM & application arguments in your batch file.
4. You can add/modify classpath and system properties prior to launching from command prompt.
Hi,
the strange behavior is that:
I'm loading a stored file via XMLEncoder , which works in the first case but not in the second case. I don't receive any error message, so I'm quite clueless.
So I hope to get a clue, from knowing the differences between the two methods.
Greetings Michael
> Hi,
>
> the strange behavior is that:
> I'm loading a stored file via XMLEncoder , which
> works in the first case but not in the second case. I
> don't receive any error message, so I'm quite
> clueless.
Are you sure your aren't ignoring any errors that might be caught? Did anything print on the console? How did you know it didn't load?
Does anything that everyone else mentioned apply?
> For starters, there is no mention of batch files in
> this thread.
>
> 1. By launching from the command prompt, you can
> choose a JVM other then your default JVM.
>
> 2. You can specify other jar dependencies in your
> jar/META-INF/Manifest.mf file.
>
> 3. You can place JVM & application arguments in your
> batch file.
>
> 4. You can add/modify classpath and system properties
> prior to launching from command prompt.
Thanks, but I'm quite sure that these points aren't causing my problem. By the way the Manifest would be read always, when use the -jar Option. But nevertheless I just set the Main-Class there, nothing else. Also I'm launching the jar with no other options.
Also I'm sure that no java.lang.OutOfMemoryError is causing the problem.
Greetings Michael
> > Hi,
> >
> > the strange behavior is that:
> > I'm loading a stored file via XMLEncoder , which
> > works in the first case but not in the second case.
> I
> > don't receive any error message, so I'm quite
> > clueless.
>
> Are you sure your aren't ignoring any errors that
> might be caught? Did anything print on the console?
> How did you know it didn't load?
>
> Does anything that everyone else mentioned apply?
I'm using exactly the same save-file and exactly the same jar. I have set a own Listener to XMLDecoder to get all messages
final XMLDecoder dec = new XMLDecoder(fis, file);
dec.setExceptionListener( new ExceptionListener(){
public void exceptionThrown(final Exception e){
e.printStackTrace();
HauptFrame.LOG.error(e.getMessage(), e);
}
});
HauptFrame.LOG. is a Log4J-logger but the file remains empty.
Also [Event-Dispatchinh is logged.
// catches Event-Dispatching
System.setProperty("sun.awt.exception.handler", HandleAllExceptionOfEventDispatching.class.getName());
/** Used to log all Exceptions that are raised during Eventdispatching.*/
public class HandleAllExceptionOfEventDispatching {
private final transient Logger log = Logger.getLogger( "xxx.util.HandleAllExceptionOfEventDispatching");
public void handle(final Throwable t){
this.log.error("Uncaught Execption \t" + t.getMessage(), t);
t.printStackTrace();
}
}
But nothing appears in the log file.
I know that it fails, cause the program hangs.
On console it works, that's exactly the problem, why I'm clueless.
Greetings Michael
When you run the java command from the command line, the system searches the PATH environment variable for a java executable. On the other hand, what happens when you double-click on a jar file is determined (assuming you haven't changed it) by the Registry entry \HKEY_CLASSES_ROOT\jarfile\shell\open\command That means you could easily be running two different versions of the JVM without meaning to. And of course, javaw.exe suppresses console output, so the easiest way to find out what's happening is to inspect that Registry entry. On my system it's "C:\Program Files\Java\jre1.6.0\bin\javaw.exe" -jar "%1" %* If nothing is obviously wrong, try changing "javaw.exe" to "java.exe", so you can see the console output.
Hi,
to get a clue I have redirected the System.err and System.out to a TextArea
(see code below) and suddenly the error was gone. So according to the behavior that it had worked before in the ide and via batch file where the System stream can do unlimited writing. I think it is obvious, that something goes wrong with streams of System.
Does anyone knows what happens to messages which are send to the default streams, when running the app as jar? I normally would assume that they would point to /dev/null or something else, but as I have experienced it seems that they are blocking after a certain amount, which prevented my app from working. (By the way invoking it with javaw has the same effect.)
This goes a little bit off topic, perhaps I should post a new thread.
But this is a huge difference between java and and javaw (jar), I wasn't aware of i t until now.
Hope someone can explain me how javaw handles System.err and System.out.
Thanks for your participation.
Greetings Michael
@SuppressWarnings("unused")
private static void debug(){
/* Debug Jar-File if no console exists */
final JTextArea ta = new JTextArea(25, 80);
ta.setWrapStyleWord(true);
final JScrollPane jscp = new JScrollPane(ta);
class TextAreaPrintStream extends PrintStream {
private JTextArea consoleTextArea;
TextAreaPrintStream(JTextArea consoleTextArea, OutputStream out) {
super(out);
this.consoleTextArea = consoleTextArea;
}
/* (non-Javadoc)
* @see java.io.PrintStream#println(java.lang.String)
*/
@Override
public void println(String x) {
this.consoleTextArea.append(x +'\n');
}
/* (non-Javadoc)
* @see java.io.PrintStream#print(java.lang.String)
*/
@Override
public void print(String s) {
this.consoleTextArea.append(s);
}
}
TextAreaPrintStream out = new TextAreaPrintStream(ta, System.out);
TextAreaPrintStream err = new TextAreaPrintStream(ta, System.err);
System.setOut(out);
System.setErr(err);
JDialog dialog = new JDialog( (Frame) null, "Log" , false);
dialog.setContentPane(jscp);
dialog.setSize(dialog.getPreferredSize());
dialog.setVisible(true);
System.err.println("Test Error");
}
Used proposed solution from sn.schulz :
http://forum.java.sun.com/thread.jspa?forumID=257&threadID=213477
To the above example:
Is it possible to write the output to both the default System.err/out (in the case if a console is present) and to the TextArea without causing an infinitive loop (which is caused by the oblivious solution)?
Second: How can I determine if a console is present or not?
Thanks.
Greetings Michael
@Override
public void print(String s) {
super.print(s);
this.consoleTextArea.append(s);
}
Does the trick. Still need s to know how to determine f a console is present.
Greetings Michael
Adding the super-call enables the old problem, so its definetly the err-Stream which causes the problem.Greetings Michael
Hi, to get everything which is error related, you have to override also these methods.
/* (non-Javadoc)
* @see java.io.PrintStream#println(java.lang.String)
*/
@Override
public void println(Object o){
this.consoleTextArea.append(o.toString() +'\n');
}
/* (non-Javadoc)
* @see java.io.PrintStream#println(java.lang.String)
*/
@Override
public void print(Object o){
this.consoleTextArea.append(o.toString());
}
cause Throwable calls them, if it prints the first line of the stack trace.
Greetings Michael
Greetings Michael
