You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Tony Wu (JIRA)" <ji...@apache.org> on 2007/06/14 05:42:26 UTC
[jira] Created: (HARMONY-4150) [classlib][archive]RI could read
some bytes from an InputStream even if the jar file has been closed
[classlib][archive]RI could read some bytes from an InputStream even if the jar file has been closed
----------------------------------------------------------------------------------------------------
Key: HARMONY-4150
URL: https://issues.apache.org/jira/browse/HARMONY-4150
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Tony Wu
refer to HARMONY-2436
=== TestJarFileClose.java:
import java.util.jar.*;
import java.io.*;
public class TestJarFileClose{
public static void main(String[] args) {
byte[] b = new byte[4];
int cnt = 0;
try {
JarFile jf = new JarFile("ecj_3.3M7.jar");
InputStream is = jf.getInputStream(jf.getEntry(
"org/eclipse/jdt/internal/compiler/ClassFile.class"));
int r;
// attention! fill the internal buffer?
if (System.getProperty("initial.read") != null) {
r = is.read(b, 0, 4);
}
jf.close();
while (true) {
r = is.read(b, 0, 1);
if (r != -1) {
cnt += r;
} else {
break;
}
}
is.close();
} catch (Exception e) {
e.printStackTrace();
}
System.out.println("Bytes red after file closure: " + cnt);
}
}
===
CMD: java TestJarFileClose
OUTPUT:
java.util.zip.ZipException: ZipFile closed
at java.util.zip.ZipFile.ensureOpenOrZipException(ZipFile.java:524)
at java.util.zip.ZipFile.access$1400(ZipFile.java:35)
at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:556)
at java.util.zip.ZipFile$2.fill(ZipFile.java:338)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:134)
at TestJarFileClose.main(TestJarFileClose.java:24)
Bytes red after file closure: 0
CMD: java -Dinitial.read TestJarFileClose
OUTPUT:
java.util.zip.ZipException: ZipFile closed
at java.util.zip.ZipFile.ensureOpenOrZipException(ZipFile.java:524)
at java.util.zip.ZipFile.access$1400(ZipFile.java:35)
at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:556)
at java.util.zip.ZipFile$2.fill(ZipFile.java:338)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:134)
at TestJarFileClose.main(TestJarFileClose.java:24)
Bytes red after file closure: 24968
To run this test you need to put "ecj_3.3M7.jar" in the directory where the test class is located. The test shows that RI maintains some internal buffer and if this buffer is initialized and filled by reading some data from stream then ZipException is thrown only after reading 24968 bytes - probably after the buffer is exhausted and new read attempt is performed. AFAIU current Harmony implementation tries to allocate enough bytes to keep complete ZipEntry in memory without using any fixed-size buffer - see Java_java_util_zip_ZipFile_inflateEntryImpl2() in the file "zip.c".
I am not sure if we should try to refactor our code to completely follow RI here. It can appear to be a non-trivial fix.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4150) [classlib][archive]RI could read
some bytes from an InputStream even if the jar file has been closed
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Ellison updated HARMONY-4150:
---------------------------------
Component/s: (was: Classlib)
Non-bug differences from RI
> [classlib][archive]RI could read some bytes from an InputStream even if the jar file has been closed
> ----------------------------------------------------------------------------------------------------
>
> Key: HARMONY-4150
> URL: https://issues.apache.org/jira/browse/HARMONY-4150
> Project: Harmony
> Issue Type: Bug
> Components: Non-bug differences from RI
> Reporter: Tony Wu
>
> refer to HARMONY-2436
> === TestJarFileClose.java:
> import java.util.jar.*;
> import java.io.*;
> public class TestJarFileClose{
> public static void main(String[] args) {
> byte[] b = new byte[4];
> int cnt = 0;
> try {
> JarFile jf = new JarFile("ecj_3.3M7.jar");
> InputStream is = jf.getInputStream(jf.getEntry(
> "org/eclipse/jdt/internal/compiler/ClassFile.class"));
> int r;
> // attention! fill the internal buffer?
> if (System.getProperty("initial.read") != null) {
> r = is.read(b, 0, 4);
> }
> jf.close();
> while (true) {
> r = is.read(b, 0, 1);
> if (r != -1) {
> cnt += r;
> } else {
> break;
> }
> }
> is.close();
> } catch (Exception e) {
> e.printStackTrace();
> }
> System.out.println("Bytes red after file closure: " + cnt);
> }
> }
> ===
> CMD: java TestJarFileClose
> OUTPUT:
> java.util.zip.ZipException: ZipFile closed
> at java.util.zip.ZipFile.ensureOpenOrZipException(ZipFile.java:524)
> at java.util.zip.ZipFile.access$1400(ZipFile.java:35)
> at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:556)
> at java.util.zip.ZipFile$2.fill(ZipFile.java:338)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:134)
> at TestJarFileClose.main(TestJarFileClose.java:24)
> Bytes red after file closure: 0
> CMD: java -Dinitial.read TestJarFileClose
> OUTPUT:
> java.util.zip.ZipException: ZipFile closed
> at java.util.zip.ZipFile.ensureOpenOrZipException(ZipFile.java:524)
> at java.util.zip.ZipFile.access$1400(ZipFile.java:35)
> at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:556)
> at java.util.zip.ZipFile$2.fill(ZipFile.java:338)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:134)
> at TestJarFileClose.main(TestJarFileClose.java:24)
> Bytes red after file closure: 24968
> To run this test you need to put "ecj_3.3M7.jar" in the directory where the test class is located. The test shows that RI maintains some internal buffer and if this buffer is initialized and filled by reading some data from stream then ZipException is thrown only after reading 24968 bytes - probably after the buffer is exhausted and new read attempt is performed. AFAIU current Harmony implementation tries to allocate enough bytes to keep complete ZipEntry in memory without using any fixed-size buffer - see Java_java_util_zip_ZipFile_inflateEntryImpl2() in the file "zip.c".
> I am not sure if we should try to refactor our code to completely follow RI here. It can appear to be a non-trivial fix.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (HARMONY-4150) [classlib][archive]RI could read some
bytes from an InputStream even if the jar file has been closed
Posted by "Tony Wu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tony Wu closed HARMONY-4150.
----------------------------
Resolution: Won't Fix
close as non-bug difference according to disscussion on http://www.mail-archive.com/dev@harmony.apache.org/msg08137.html
> [classlib][archive]RI could read some bytes from an InputStream even if the jar file has been closed
> ----------------------------------------------------------------------------------------------------
>
> Key: HARMONY-4150
> URL: https://issues.apache.org/jira/browse/HARMONY-4150
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Tony Wu
>
> refer to HARMONY-2436
> === TestJarFileClose.java:
> import java.util.jar.*;
> import java.io.*;
> public class TestJarFileClose{
> public static void main(String[] args) {
> byte[] b = new byte[4];
> int cnt = 0;
> try {
> JarFile jf = new JarFile("ecj_3.3M7.jar");
> InputStream is = jf.getInputStream(jf.getEntry(
> "org/eclipse/jdt/internal/compiler/ClassFile.class"));
> int r;
> // attention! fill the internal buffer?
> if (System.getProperty("initial.read") != null) {
> r = is.read(b, 0, 4);
> }
> jf.close();
> while (true) {
> r = is.read(b, 0, 1);
> if (r != -1) {
> cnt += r;
> } else {
> break;
> }
> }
> is.close();
> } catch (Exception e) {
> e.printStackTrace();
> }
> System.out.println("Bytes red after file closure: " + cnt);
> }
> }
> ===
> CMD: java TestJarFileClose
> OUTPUT:
> java.util.zip.ZipException: ZipFile closed
> at java.util.zip.ZipFile.ensureOpenOrZipException(ZipFile.java:524)
> at java.util.zip.ZipFile.access$1400(ZipFile.java:35)
> at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:556)
> at java.util.zip.ZipFile$2.fill(ZipFile.java:338)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:134)
> at TestJarFileClose.main(TestJarFileClose.java:24)
> Bytes red after file closure: 0
> CMD: java -Dinitial.read TestJarFileClose
> OUTPUT:
> java.util.zip.ZipException: ZipFile closed
> at java.util.zip.ZipFile.ensureOpenOrZipException(ZipFile.java:524)
> at java.util.zip.ZipFile.access$1400(ZipFile.java:35)
> at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:556)
> at java.util.zip.ZipFile$2.fill(ZipFile.java:338)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:134)
> at TestJarFileClose.main(TestJarFileClose.java:24)
> Bytes red after file closure: 24968
> To run this test you need to put "ecj_3.3M7.jar" in the directory where the test class is located. The test shows that RI maintains some internal buffer and if this buffer is initialized and filled by reading some data from stream then ZipException is thrown only after reading 24968 bytes - probably after the buffer is exhausted and new read attempt is performed. AFAIU current Harmony implementation tries to allocate enough bytes to keep complete ZipEntry in memory without using any fixed-size buffer - see Java_java_util_zip_ZipFile_inflateEntryImpl2() in the file "zip.c".
> I am not sure if we should try to refactor our code to completely follow RI here. It can appear to be a non-trivial fix.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (HARMONY-4150) [classlib][archive]RI could read some
bytes from an InputStream even if the jar file has been closed
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Ellison closed HARMONY-4150.
--------------------------------
Resolution: Won't Fix
> [classlib][archive]RI could read some bytes from an InputStream even if the jar file has been closed
> ----------------------------------------------------------------------------------------------------
>
> Key: HARMONY-4150
> URL: https://issues.apache.org/jira/browse/HARMONY-4150
> Project: Harmony
> Issue Type: Bug
> Components: Non-bug differences from RI
> Reporter: Tony Wu
>
> refer to HARMONY-2436
> === TestJarFileClose.java:
> import java.util.jar.*;
> import java.io.*;
> public class TestJarFileClose{
> public static void main(String[] args) {
> byte[] b = new byte[4];
> int cnt = 0;
> try {
> JarFile jf = new JarFile("ecj_3.3M7.jar");
> InputStream is = jf.getInputStream(jf.getEntry(
> "org/eclipse/jdt/internal/compiler/ClassFile.class"));
> int r;
> // attention! fill the internal buffer?
> if (System.getProperty("initial.read") != null) {
> r = is.read(b, 0, 4);
> }
> jf.close();
> while (true) {
> r = is.read(b, 0, 1);
> if (r != -1) {
> cnt += r;
> } else {
> break;
> }
> }
> is.close();
> } catch (Exception e) {
> e.printStackTrace();
> }
> System.out.println("Bytes red after file closure: " + cnt);
> }
> }
> ===
> CMD: java TestJarFileClose
> OUTPUT:
> java.util.zip.ZipException: ZipFile closed
> at java.util.zip.ZipFile.ensureOpenOrZipException(ZipFile.java:524)
> at java.util.zip.ZipFile.access$1400(ZipFile.java:35)
> at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:556)
> at java.util.zip.ZipFile$2.fill(ZipFile.java:338)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:134)
> at TestJarFileClose.main(TestJarFileClose.java:24)
> Bytes red after file closure: 0
> CMD: java -Dinitial.read TestJarFileClose
> OUTPUT:
> java.util.zip.ZipException: ZipFile closed
> at java.util.zip.ZipFile.ensureOpenOrZipException(ZipFile.java:524)
> at java.util.zip.ZipFile.access$1400(ZipFile.java:35)
> at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:556)
> at java.util.zip.ZipFile$2.fill(ZipFile.java:338)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:134)
> at TestJarFileClose.main(TestJarFileClose.java:24)
> Bytes red after file closure: 24968
> To run this test you need to put "ecj_3.3M7.jar" in the directory where the test class is located. The test shows that RI maintains some internal buffer and if this buffer is initialized and filled by reading some data from stream then ZipException is thrown only after reading 24968 bytes - probably after the buffer is exhausted and new read attempt is performed. AFAIU current Harmony implementation tries to allocate enough bytes to keep complete ZipEntry in memory without using any fixed-size buffer - see Java_java_util_zip_ZipFile_inflateEntryImpl2() in the file "zip.c".
> I am not sure if we should try to refactor our code to completely follow RI here. It can appear to be a non-trivial fix.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (HARMONY-4150) [classlib][archive]RI could read
some bytes from an InputStream even if the jar file has been closed
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Ellison reopened HARMONY-4150:
----------------------------------
Just re-categorizing this issue.
> [classlib][archive]RI could read some bytes from an InputStream even if the jar file has been closed
> ----------------------------------------------------------------------------------------------------
>
> Key: HARMONY-4150
> URL: https://issues.apache.org/jira/browse/HARMONY-4150
> Project: Harmony
> Issue Type: Bug
> Components: Non-bug differences from RI
> Reporter: Tony Wu
>
> refer to HARMONY-2436
> === TestJarFileClose.java:
> import java.util.jar.*;
> import java.io.*;
> public class TestJarFileClose{
> public static void main(String[] args) {
> byte[] b = new byte[4];
> int cnt = 0;
> try {
> JarFile jf = new JarFile("ecj_3.3M7.jar");
> InputStream is = jf.getInputStream(jf.getEntry(
> "org/eclipse/jdt/internal/compiler/ClassFile.class"));
> int r;
> // attention! fill the internal buffer?
> if (System.getProperty("initial.read") != null) {
> r = is.read(b, 0, 4);
> }
> jf.close();
> while (true) {
> r = is.read(b, 0, 1);
> if (r != -1) {
> cnt += r;
> } else {
> break;
> }
> }
> is.close();
> } catch (Exception e) {
> e.printStackTrace();
> }
> System.out.println("Bytes red after file closure: " + cnt);
> }
> }
> ===
> CMD: java TestJarFileClose
> OUTPUT:
> java.util.zip.ZipException: ZipFile closed
> at java.util.zip.ZipFile.ensureOpenOrZipException(ZipFile.java:524)
> at java.util.zip.ZipFile.access$1400(ZipFile.java:35)
> at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:556)
> at java.util.zip.ZipFile$2.fill(ZipFile.java:338)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:134)
> at TestJarFileClose.main(TestJarFileClose.java:24)
> Bytes red after file closure: 0
> CMD: java -Dinitial.read TestJarFileClose
> OUTPUT:
> java.util.zip.ZipException: ZipFile closed
> at java.util.zip.ZipFile.ensureOpenOrZipException(ZipFile.java:524)
> at java.util.zip.ZipFile.access$1400(ZipFile.java:35)
> at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:556)
> at java.util.zip.ZipFile$2.fill(ZipFile.java:338)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:134)
> at TestJarFileClose.main(TestJarFileClose.java:24)
> Bytes red after file closure: 24968
> To run this test you need to put "ecj_3.3M7.jar" in the directory where the test class is located. The test shows that RI maintains some internal buffer and if this buffer is initialized and filled by reading some data from stream then ZipException is thrown only after reading 24968 bytes - probably after the buffer is exhausted and new read attempt is performed. AFAIU current Harmony implementation tries to allocate enough bytes to keep complete ZipEntry in memory without using any fixed-size buffer - see Java_java_util_zip_ZipFile_inflateEntryImpl2() in the file "zip.c".
> I am not sure if we should try to refactor our code to completely follow RI here. It can appear to be a non-trivial fix.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.