RFR: 6947916: JarURLConnection does not handle useCaches correctly

[Roger Riggs]

Hi Rob,

Looks ok.

Its also a good practice to cleanup the file.  (File.deleteOnExit).

Roger


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!
>
> http://cr.openjdk.java.net/~robm/6947916/webrev.02/
>
> 	-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:
>>>
>>> http://cr.openjdk.java.net/~robm/6947916/webrev.01/
>>> https://bugs.openjdk.java.net/browse/JDK-6947916
>> 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.
>>
>> -Chris.
>>
>>> 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