Bug 117890 - JavaElement.getURLContents(...) leaves file open
Summary: JavaElement.getURLContents(...) leaves file open
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.2 M4   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-24 06:38 EST by Jerome Lanneluc CLA
Modified: 2014-11-12 08:59 EST (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jerome Lanneluc CLA 2005-11-24 06:38:06 EST 
I20051123

The AttachedJavadocTests sometimes fail because JavaElement.getURLContents(...) leaves a file open and the test cannot delete the project in the tearDownSuite() method because of that. 

More specifcally URLConnection.getContentEncoding() opens a file stream on the doc.zip and never closes it. So this looks like a bug in the implementation of URLConnection.getContentEncoding().
Comment 1 Jerome Lanneluc CLA 2005-11-24 06:42:25 EST 
I added a workaround in AbstractJavaModelTests.deleteResource(IResource) to force the GC to run so that the finalize method of the file input stream is run.

I also noticed that getContentEncoding() always return null for this test. If this call is not necessary, a fix would be to always use the default encoding.

Olivier, since this is your code, I'll let you decide.
Comment 2 Olivier Thomann CLA 2005-11-24 09:01:10 EST 
I suspected something like that. The problem is that this call is necessary to make sure that the stream is read using the right encoding. If we use the default encoding, it might work most of the time, but if the file specifies explicitely what encoding should be used, we will miss it.
I disabled the caching in the URL connection to prevent such open streams, but it seems that this is not enough.
I need to investigate if there is another way to retrieve the encoding in the file.
Comment 3 Olivier Thomann CLA 2005-11-24 11:52:14 EST 
I don't get the content encoding anymore. I use the default encoding specified as a parameter first. If null, I use the default encoding of the project and if this one is unsupported, I use the platform encoding.
Fixed and released in HEAD.
I'll monitor future builds to ensure the intermittent failure is gone.
Comment 4 Frederic Fusier CLA 2005-12-13 05:49:04 EST 
Verified for 3.2 M4 with build I20051213-0010
Comment 5 Markus Keller CLA 2014-11-12 08:59:05 EST 
(In reply to Olivier Thomann from comment #3)
> I don't get the content encoding anymore.

Note that this "fix" has been reverted with bug 122506, but the outdated comment on org.eclipse.jdt.internal.core.JavaElement#getURLContents(..) stayed. Will remove the comment with fix for bug 450684.