Patch for Enhancement Bug # 6313849 and 417591

Christopher Hegarty - Sun Microsystems Ireland Christopher.Hegarty at Sun.COM
Fri May 18 01:51:39 PDT 2007



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.

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.

BTW, Shouldn't JarURLConnection.disconnect release the resources held by 
its containing URLConnection.

-Chris.



More information about the net-dev mailing list