Patch for Enhancement Bug # 6313849 and 417591

[Alan Bateman]

Andreas Schaefer wrote:
> :
> 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.
>   
If you add a disconnect method (maybe it should be named "close" and 
have URLConnection implement Closeable), then it is likely that 
developers may attempt to use it for cancellation. In error situations 
or network file systems then access to JAR or file resources may block 
or take significant time. There is nothing in the spec that requires 
protocol handlers to support asynchronous close and it is highly likely 
there are protocol handlers where it doesn't work - invoking close on 
the intput or output stream may block or may not preempt threads blocked 
doing I/O on the streams for example. For the proposed disconnect method 
I'm just suggesting that these issues need to be considered. One 
suggestion is to specify that it can't make any guarantees, beyond a 
best effort attempt,  to close the connection to the resource in a 
timely manner. It would not be unreasonable to specify that, on 
completion, the connection to the resource has been closed (which means 
that disconnect may block).

One other thing - a common issue for new developers is to attempt re-use 
a URLConnection (it comes up with http a lot as developers don't know 
how the HTTP protocol handler works with persistent connections). In the 
disconnect method it may be useful to set expectations. Also, you may 
need to add wording to the connect method to specify the behavior after 
the connection has been closed.

-Alan.