Patch for Enhancement Bug # 6313849 and 417591

[Andreas Schaefer]

Christopher Hegarty - Sun Microsystems Ireland wrote:
>
> Alan Bateman wrote:
>> One final thing to think about is if we want a default implementation
>> rather than adding an abstract method.
>
> I agree with Alan here. Adding disconnect as an abstract method will
> break both binary and source compatibility.
>
> From a binary point of view URLConnection subclasses compiled and
> runnable with Java SE 6 (or lower) will now throw a
> java.lang.AbstractMethodError if the disconnect method is called.
That can only happen if some code is 1.7 aware and some of the code is
not like a library. AFAIK there were already changes in the JDK that
caused that as well. I think that needs to be documented. On the other
hand URLConnection is not a class that is extended quite a lot.
> From a source perspective URLConnection subclasses that previously
> compiled with Java SE 6 will no longer compile with the java compiler
> (javac) from Java SE 7 : ...Class is not abstract and does not
> override abstract method disconnect() in ...
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.

-Andy