Andreas Schaefer wrote:
Michael McMahon wrote:
Andreas Schaefer wrote:
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
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.
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.
-Andy
One other thing, URLConnections can't be reused. I imagine it could
lead to all kinds
of security issues if we tried to support that. They are basically
immutable in terms
of the resource that is accessed. I don't think this RFE really needs
that. What do you think?
- Michael.
If that is necessary then it is OK with me. We just must make sure that
nobody can (re)connect throwing an IOException in the connect() method.
The problem is that every sub class that implements connect() must
adhere to it and if they don't then one could still reconnect.
I would suggest that a reconnect is possible except the URLConnection
throws an exception. Glancing at the HttpURLConnection.disconnect()
method I think they do allow reconnects.
Yes, unfortunately it does, even though the docs for HttpURLConnection
explicitly state:
"Each HttpURLConnection instance is used to make a single request".
There are likely all kind of problems with reusing HttpURLConnection
objects because there
is a lot of state that doesn't get reset when disconnect() is called.
This is another reason why I think we should leave
HttpURLConnection.disconnect() well alone,
and put the new functionality into a close() method.
I think Alan's question is valid, about specifying what happens when one
thread calls close() while another
thread could be blocked in a read (for example). One way of approaching
this, would be to describe
what will happen, with your proposed changes, for jar, file and http
URLConnection types in that situation
and then if the behavior is ok, we can document it that way.
- Michael.
-Andy
