Patch for Enhancement Bug # 6313849 and 417591

[Andreas Schaefer]

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.

-Andy