Patch for Enhancement Bug # 6313849 and 417591

[Andreas Schaefer]

Alan Bateman wrote:
> 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.
I don't think we need to deal with blocking etc because so far people
had to obtain the underlying resource and close them which would have
all the problems you mentioned. This new method is not any different
except that its avoids the upcasts and the fishing for resources.

-Andy