Patch for Enhancement Bug # 6313849 and 417591

[Andreas Schaefer]

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.
There are two independent bug reports asking for the disconnect() method 
and on 6313849 there are 9 votes. I am going to blog about this and see 
if I can get more feedback from the community.
> Obviously even with disconnect being abstract implementers can still 
> provide an empty implementation in the subclass. I do not see the 
> advantage to forcing them to do this. Also, not all protocol handlers 
> and URLConnection subclasses have specific public API's exposed, for 
> example 'file'. Therefore it is even more important to try and clearly 
> specify the methods of URLConnection.
Well, I can also create an URLConnection that has an empty connect() 
method, silly but true. If you really want an empty disconnect() method 
then be my guest but I still think that is worse than forcing the 
extended classes to create one so that it adheres to the "contract" 
otherwise I could also ask why is the connect() method abstract?
>
> BTW, Shouldn't JarURLConnection.disconnect release the resources held 
> by its containing URLConnection.
Maybe you saw a bug in my implementation and if yes then tell me but 
otherwise you should do your homework and checkout my patch because that 
is what is in there.

-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/ac71f6aa/andreas.schaefer.vcf