I'm afraid so.
The option of changing the the JarURLConnection spec to indicate what
could happen when the class file is missing was discussed but that will
require some further thought. (and it may not necessarily result in a fix
for this problem, the assumption being that behaviour changes in th
Daniel's summary is useful but changing URLClassPath doesn't feel right.
Are you in a hurry to find a solution to this? Just asking as I think
I'd prefer to see other options explored that fixed it in the protocol
handler instead.
-Alan
On 25/11/2019 13:31, Rob McKenna wrote:
Thanks Danie
Thanks Daniel,
cc'ing core-libs-dev in case there are any objections.
-Rob
On 25/11/19 10:47, Daniel Fuchs wrote:
> Hi Rob,
>
> That looks good to me. I wonder if that should go to corelibs for
> review as well.
>
> The underlying issue here is that JarURLConnection open both its
> jar fil
Hi Rob,
That looks good to me. I wonder if that should go to corelibs for
review as well.
The underlying issue here is that JarURLConnection open both its
jar file and its jar file entry in its connect() method.
However, it delegates the opening of the jar file to the cache,
when uses cache is t
Hi folks,
If a FileNotFoundException is thrown when attempting to load a class
from a jar file, a reference to the open JarFile remains even after the
loader is closed. The test in the webrev demonstrates the problem by
attempting to delete the JarFile after attempting a class load.
The deletion
