Patch for Enhancement Bug # 6313849 and 417591
andreas.schaefer at madplanet.com
Fri May 18 09:18:25 PDT 2007
Michael McMahon wrote:
> 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
>>> just needs to implement it. Compiling means that he/she has the code
>>> 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.
My idea is that connect() / disconnect() are orthogonal methods meaning
that after a disconnect() one can reopen the Connection by issuing
another connect() call. Calling it close() would break that
linguistically but with the proper documentation it should be fine.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 403 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/net-dev/attachments/20070518/ed33cd9c/andreas.schaefer.vcf
More information about the net-dev