On Mon, May 19, 2008 at 08:54:10PM +0200, Mark Brouwer wrote:
> Peter Jones wrote:
>> I finally uncovered an old (early 2001) email that was the code review
>> request for the change which added PreferredClassLoader's extra
>> retrieval of the first JAR file without using the "jar:" URL handler--
>> but the explanation it contains does not make sense to me. I'm now
>> inclined to think that we should just remove the extra retrieval,
>> simplifying this rather confusing code (and obviating the original
>> need for the RIVER-9 change).
>>
>
> Hi Peter, Bob,
>
> Sorry for the late response (was on holidays for while) and I'm having a
> lot of problems lately with regard to my cheiron.org mail adres.
>
> I would like to leave the code as it is for now. If the 'intriging' code
> is really not necessary it would be a good thing to simplify, but one
> could argue whether the spec for the JarURLConnection methods that throw
> IOException is enough to assume FileNotFoundException will be thrown in
> case a connection can be established and it can be determined the file
> doesn't exist.
>
> The implementations might seem to do the right thing, but as they don't
> specify when FileNotFoundException is thrown I think there is also no
> harm in the way the current codebase deals with it.
The HttpURLConnection.getErrorStream spec mentions the 404->FNFE
behavior in passing:
Returns the error stream if the connection failed but the server
sent useful data nonetheless. The typical example is when an HTTP
server responds with a 404, which will cause a
FileNotFoundException to be thrown in connect, but the server sent
an HTML help page with suggestions as to what to do.
One might read this "will cause" statement as a spec requirement, but
it is admittedly indirect in its placement and unclear in its coverage.
I'm OK with leaving the code as it is (with your RIVER-9 change) for
now-- it seems like the lower risk choice-- but I think that it would
be valuable to revise the code comments to clarify that the
PreferredClassLoader implementation is making this extra effort to
cover itself in the case of an imagined JarURLConnection
implementation behavior that is not believed to actually exist.
(Otherwise someone studying the code might reasonably assume that
there was a motivating case in practice and struggle to understand
what it could be, before discovering this mailing list thread.)
> One might create an issue for this, however.
Yup. I'll file one.
-- Peter
