A DESCRIPTION OF THE PROBLEM :
When handling File through URL -> URLConnection, reading any header (such as cnx.getLastModified() ) will leave an underlying InputStream open, thus leaking a file handle.

https://bugs.openjdk.java.net/browse/JDK-6956385 was already opened for the same issue, but :
- no test case was provided
- no workaround was provided
- issue reference a old jdk and was never addressed, and still relevent today

URLConnection javadoc states the following :
"Invoking the close() methods on the InputStream or OutputStream of an URLConnection after a request may free network resources associated with this instance, unless particular protocol specifications specify different behaviours for it."

However this is completely counter intuitive as does not seems to follow good Java pattern.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Invoke url.openConnection().getLastModified() when url reference a File

[code]
File file = File.createTempFile("test-URLConnection", ".tmp");
URL url = file.toURI().toURL();
URLConnection cnx = url.openConnection();
long lastModified = cnx.getLastModified(); // BUG : InputStream leaked in FileURLConnection.initializeHeaders -> FileURLConnection.connect

System.out.println(file.delete()); // Symptom : prints false because delete could not be performed due to opened filedescriptor
[/code]


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
file handle must be released,
thus delete should be successful and true should be printed

ACTUAL -
file is not released, thus delete fails, and false is printed


---------- BEGIN SOURCE ----------
File file = File.createTempFile("test-URLConnection-leak", ".tmp");
file.toURI().toURL().openConnection().getLastModified();
assertTrue(file.delete());

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Invoke close method on the URLConnection input stream

[code]
// workaround to force relase of the underlying InputStream
try { cnx.getInputStream().close(); } catch(IOException ioex) {};
    
System.out.println(file.delete()); // delete successful now that workaround has been called
[/code]


FREQUENCY : always