Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2121362 | 5.0u2 | Michael McMahon | P3 | Resolved | Fixed | b04 |
JDK-2121363 | 1.4.2_08 | Poonam Bajaj Parhar | P3 | Resolved | Fixed | b01 |
The bug seems to be located in the inner class in java.util.zip.ZipFile ? ZipFileInputStream, and more specifically its
public void close()
It doesn?t close its field handle to the ZipFile there and this leaves the file handle leak.
In the customer case the usage of URL.openStream() the customer cannot get access to the zipFile handle and there is no way it can be explicitly closed.
The problem resulting of this effect is that the partner's J2EE is not able to redeploy applications
###@###.### 10/30/04 01:46 GMT
public void close()
It doesn?t close its field handle to the ZipFile there and this leaves the file handle leak.
In the customer case the usage of URL.openStream() the customer cannot get access to the zipFile handle and there is no way it can be explicitly closed.
The problem resulting of this effect is that the partner's J2EE is not able to redeploy applications
###@###.### 10/30/04 01:46 GMT
- backported by
-
JDK-2121362 ZipFile$ZipFileInputStream doesn't close handle to zipfile
- Resolved
-
JDK-2121363 ZipFile$ZipFileInputStream doesn't close handle to zipfile
- Resolved
- duplicates
-
JDK-6175450 12 javax/imageio tests are failing with package based installation of JDK on solaris10 sparc
- Closed
-
JDK-6962459 Can' t delete zip files accessed with jar protocol
- Closed
- relates to
-
JDK-4797189 Finalizers not called promptly enough
- Closed
-
JDK-5072161 OutOfMemoryError while using GZIPOutputStream
- Closed
(1 relates to)