Patch for Enhancement Bug # 6313849 and 417591

[Michael McMahon]

Andreas Schaefer wrote:
> Michael McMahon wrote:
>   
>> Andreas Schaefer wrote:
>>     
>>> Michael McMahon wrote:
>>>       
>>>> Christopher Hegarty - Sun Microsystems Ireland wrote:
>>>>         
>>>>> Andreas Schaefer wrote:
>>>>>  > Well, the reason I did make it abstract is the fact that I did
>>>>> want to
>>>>>           
>>>>>> avoid someone getting away with an empty implementation. This is only
>>>>>> causing a problem if someone is compiling its code for 1.7 and so
>>>>>> he/she
>>>>>> just needs to implement it. Compiling means that he/she has the
>>>>>> code and
>>>>>> so this is pretty easy fix. Providing an empty implementation is more
>>>>>> costly that adding an implementation.
>>>>>>             
>>>>> While breaking source compatibility in a major release ( and jdk 7
>>>>> is a major release ) is acceptable, I think there should be a good
>>>>> reason to do so, and I do not believe that there is one in this case.
>>>>>
>>>>>           
>>>> This case is probably in a grey area. Normally, the justification
>>>> has to be very strong, but
>>>> URLConnection and its sub-classes would mostly be considered as part
>>>> of the platform rather
>>>> than as part of applications. In other words, (as Andy said) there
>>>> probably aren't that many
>>>> implementations out there. So long as we maintain binary
>>>> compatibility for existing applications
>>>> using third party URLConnections (assuming there are some) then we
>>>> should be ok.
>>>>
>>>> I think I prefer the method name close() to disconnect() since it
>>>> seems to be closer to
>>>> what the bug report is asking for. HttpURLConnection.disconnect() is
>>>> slightly different
>>>> in meaning.
>>>>
>>>> - Michael.
>>>>         
>>> My idea is that connect() / disconnect() are orthogonal methods
>>> meaning that after a disconnect() one can reopen the Connection by
>>> issuing another connect() call. Calling it close() would break that
>>> linguistically but with the proper documentation it should be fine.
>>>
>>> -Andy
>>>       
>> One other thing, URLConnections can't be reused. I imagine it could
>> lead to all kinds
>> of security issues if we tried to support that. They are basically
>> immutable in terms
>> of the resource that is accessed. I don't think this RFE really needs
>> that. What do you think?
>>
>> - Michael.
>>     
> If that is necessary then it is OK with me. We just must make sure that
> nobody can (re)connect throwing an IOException in the connect() method.
> The problem is that every sub class that implements connect() must
> adhere to it and if they don't then one could still reconnect.
> I would suggest that a reconnect is possible except the URLConnection
> throws an exception. Glancing at the HttpURLConnection.disconnect()
> method I think they do allow reconnects.
>
>   
Yes, unfortunately it does, even though the docs for HttpURLConnection 
explicitly state:
"Each HttpURLConnection instance is used to make a single request".
There are likely all kind of problems with reusing HttpURLConnection 
objects because there
is a lot of state that doesn't get reset when disconnect() is called.

This is another reason why I think we should leave 
HttpURLConnection.disconnect() well alone,
and put the new functionality into a close() method.

I think Alan's question is valid, about specifying what happens when one 
thread calls close() while another
thread could be blocked in a read (for example). One way of approaching 
this, would be to describe
what will happen, with your proposed changes, for jar, file and http 
URLConnection types in that situation
and then if the behavior is ok, we can document it that way.

- Michael.
> -Andy
>