DataInputStream java - program doesn't end once dis.close() is called then system.exit(0). Only happens on .exe

Question

There is a couple anomalies I have found here.

Program info: The program is a parser. It takes in data through a data input stream. Then when the data input stream is closed I call system.exit(0).

 dis.close();
 System.exit(0);

I have created a jar and exe. When I use the jar it seems to run fine. and everything is as expected. The console looks like this

 /the/path/that/im/currently/in
 $      <I type:>    java -jar myprogram.jar commandLineArg     *enter
                     Program output
                     Program output
                     Program output
 <program ends and goes back to>
 /the/path/that/im/currently/in
 $

When I use the exe. The console looks like this, and you can see how it kind of bounces.

 /the/path/that/im/currently/in
 $     <I type:>    ./myprogram commandLineArg       *enter
 /the/path/that/im/currently/in
 $                  Program output
                    Program output
                    Program output
 <now stuck hanging until I hit enter or ctrl+c>     *enter

 /the/path/that/im/currently/in
 $ <now i'm back where I should be>

Answer 1

This sounds like a problem with the tool you used to make the .exe file, it may no longer use a Java Virtual Machine to execute your code, or use one which is inappropriately implemented in that the System.exit(0) call is not recognised as a command to also exit the wrapper process, and as stated by the Javadocs for System.exit(int status):

public static void exit(int status)

Terminates the currently running Java Virtual Machine. The argument serves as a status code; by convention, a nonzero status code indicates abnormal termination.

This method calls the exit method in class Runtime. This method never returns normally.

The call System.exit(n) is effectively equivalent to the call:

 Runtime.getRuntime().exit(n)

As such, it may be worth trying another wrapper tool.

Answer 2

System.exit() is a drastic call -- it forces exit of all running threads, rather than allowing them to run to completion. It can be appropriate in cases where you need to communicate an exit code to the OS, or when there are threads you know should be killed. But it is not generally necessary, there are better ways to termnate your program.

We can't tell about yours, of course, unless we know more about the program. But I suspect a hack/quick fix would be to put a Thread.sleep(3000) right before the call to exit().