Patch for Enhancement Bug # 6313849 and 417591

[Andreas Schaefer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: andreas.schaefer.vcf
Type: text/x-vcard
Size: 403 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/net-dev/attachments/20070518/ed33cd9c/andreas.schaefer.vcf