RFR: 6947916: JarURLConnection does not handle useCaches correctly
rob.mckenna at oracle.com
Fri Sep 9 16:02:00 UTC 2016
On 09/09/16 11:00, Roger Riggs wrote:
> Hi Rob,
> Looks ok.
> Its also a good practice to cleanup the file. (File.deleteOnExit).
> On 9/9/2016 9:23 AM, Rob McKenna wrote:
> >Hey Chris,
> >Apologies, I'm guilty of "just doing what adjacent tests do" here.
> >That shell script is actually there in the test source already, but generating the jar from the test means theres no need to use it or to check in a binary. Thanks for picking me up!
> > -Rob
> >On 08/09/16 08:40, Chris Hegarty wrote:
> >>>On 7 Sep 2016, at 14:17, Rob McKenna <rob.mckenna at oracle.com> wrote:
> >>>Hi folks,
> >>>Looking for a review of this simple enough fix:
> >>I think that the source changes are good, but the tests has a
> >>reference to a shell script that is absent. Also, could the test just
> >>create a simple jar file, rather than checking in a binary artifact.
> >>>In a nutshell, if multiple URLConnections are made to several files in a single jar, each will use the same backing JarFile object. Unfortunately JarURLConnections connect() method recreates the jarFileURLConnection for a given JarURLConnection using the default value for getUseCaches instead of the *current* value.
> >>>In effect this means that jarURLConnection.getUseCaches() may return true before calling connect() and false after. This in turn means that when a JarURLConnection's inputstream is closed, it will believe that caching has been turned off and the underlying jarFile will be closed out from under all other JarURLConnection inputstreams.
> >>> -Rob
More information about the net-dev