Patch for Enhancement Bug # 6313849 and 417591

[Alan Bateman]

Andreas Schaefer wrote:
> I added the disconnect() method to the java.net.URLConnection class and
> the implementation to its subclasses. I create the Disconnect.java test
> class which tests that  the InputStreams are closed and the a reconnect
> is possible.
>
>   
I don't work in the networking APIs but one comment is that it's not 
clear if this disconnect method is meant to work as an asynchronous 
close. If there a thread blocked reading from a resource, for example, 
and another thread invokes the disconnect method then what is supposed 
to happen? Is the close allowed to block indefinitely or do you expect 
the other thread to throw an I/O exception? One concern is that the 
latter may not be feasible with some protocol handler implementations. 
The spec will probably also need to deal with the case where the 
disconnect method is invoked while another thread is disconnecting. 
There are currency issues with the implementation here but if the 
expectation is that on return from the disconnect method that all 
resources have been released, then you probably want disconnect to wait 
until the first invocation has completed.

Another spec question is if we want to update HttpURLConnection's 
disconnect method. It doesn't define a checked exception (that should be 
okay) but more interesting, is that it doesn't have the same guarantee 
about releasing resources that you are looking to add to URLConnection.

One final thing to think about is if we want a default implementation 
rather than adding an abstract method.

-Alan.