A exception is generated in Windows but not in Linux

Question

FULL PRODUCT VERSION :
junmin@Linux:~/Workspace/JMessenger/build/classes$ java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)
E:\JMessenger\build\classes>java -version
java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
junmin@Linux:~/Workspace/JMessenger/build/classes$ uname -a
Linux Linux 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux
ubuntu feisty, installed sun-java-jre and jdk from the repository of ubuntu
and
Windows XP professional sp2
java6 installed
A DESCRIPTION OF THE PROBLEM :
reader = new BufferedReader(new InputStreamReader(client.getInputStream())); // client is the socket in the server side
             try{
                 while((incomingMessage = reader.readLine()) != null){
             catch(Exception e){
                     System.out.println(e);
             }       //serverthis is a client-server program, why in Windows it(server) throw the Exception when the client closes the program o the socket? and it doesnt throw any exception in Linux(ubuntu feisty/dapper) ??????
here is the exception generated in Windows:
     java.net.SocketException: Connection reset
             at java.net.SocketInputStream.read(Unknown Source)
             at sun.nio.cs.StreamDecoder.readBytes(Unknown Source)
             at sun.nio.cs.StreamDecoder.implRead(Unknown Source)
             at sun.nio.cs.StreamDecoder.read(Unknown Source)
             at java.io.InputStreamReader.read(Unknown Source)
             at java.io.BufferedReader.fill(Unknown Source)
             at java.io.BufferedReader.readLine(Unknown Source)
             at java.io.BufferedReader.readLine(Unknown Source)
             at Service.run(Service.java:37)is this could be considered a bug??? i hope java can throw the same exception in Linux too, cause this helps to check the statu of socket connection. thanks

Answer 1

The following is mostly an educated guess, but it is based in some understanding of how the different OSs work.
In linux sockets are handled by the driver(read: kernel part) that converts the actions on file descriptors to actions on network sockets. When a program shuts down, said driver continues to run, but receives a close request on the file descriptor, so it proceeds with a standard socket close.
On windows, the sockets are the property of the program, not the network driver, and when the program shuts down the sockets simply abort as they are discarded. The network driver is not allowed to temporarily hold the socket until its operation completes. They are simply thrown away.
Anyway, a proper solution that would be helpful for all OSs is to actually close the socket within the program, rather than hope the OS has a "garbage collector" for sockets. The same applies for all OS resources(files, pipes, GUI resources, etc). On certain OSs, certain resources may actually remain allocated after program shutdown, if not formally disposed.
On a side note, socket libraries for windows usually support socket auto-close on disposing of the socket object. I'm surprised the Java library doesn't (seem to) follow the same pattern. Then again, I've seen programs(non-java, of course) cause system freezes over stuff like that.