Patch for Enhancement Bug # 6313849 and 417591

[Michael McMahon]

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.