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.
More information about the net-dev