Patch for Enhancement Bug # 6313849 and 417591

[Andreas Schaefer]

Alan Bateman wrote:
> Andreas Schaefer wrote:
>> :
>> 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.
>>   
> The specification of the proposed disconnect method will need to set
> expectations. If you are saying that it depends on if the streams can
> be asynchronously closed then this should go into its spec. In that
> case, disconnect may block and you will also need to specify how
> disconnect behaves when invoked by several threads at around the same
> time. It may be best to say that it blocks until the first invocation
> completes as that will ensure that on completion, all resources will
> have been released.
>
> -Alan.

For the Jar- and FileURLConnection there is no such thing as an
invocation. For the FTPURLConnection I am not quite sure if it would be
a great thing to wait until an invocation is done especially when a huge
file is transferred. Mostly we are dealing with Input / Output Stream
and when they are closed the using thread gets an exception.
On the other hand right now a user of any URLConnection has to make
handle by themselves already so why we just let them handle it by
themselves now.

I suggest that we refer to the sub class' disconnect() method for
protocol specific issues like concurrency and say by default the user
has to take care of it by themselves.

I also have a problem to come up with an use case of an asynchronous
disconnect. How would another thread knows when to disconnect. The only
use case I can come up with is than two threads could collide during
connect / disconnect and we might want to prevent the URLConnection from
doing so. This way we make sure that either a URLConnection is fully
connected or disconnected.

-Andy