-
Bug
-
Resolution: Not an Issue
-
P4
-
None
-
8u66, 9
-
x86_64
-
windows_7
FULL PRODUCT VERSION :
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b18, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]
A DESCRIPTION OF THE PROBLEM :
I just spent hours to find out that the official ObjectInputStream Java class shows some pretty bad behavior if the input stream is corrupted. In expression: ObjectInputStream .close() won't close the underlying stream after trying ObjectInputStream .readObject() on an input stream with a bad header. So
try(ObjectInputStream ois = new ObjectInputStream(new FileInputStream(...))) {
ois.readObject();
...
}
does NOT (!) reliably close the file handle! The safe way to go is to use try-with-resources directly on the file input stream
try(InputStream is = new FileInputStream(...)) {
ObjectInputStream ois = new ObjectInputStream(is);
ois.readObject();
...
}
and never on ObjectInputStream directly. Java is a very nice language in general, but this implementation does not live up to it. Please fix that and make it behave like everyone would expect.
REPRODUCIBILITY :
This bug can be reproduced always.
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b18, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]
A DESCRIPTION OF THE PROBLEM :
I just spent hours to find out that the official ObjectInputStream Java class shows some pretty bad behavior if the input stream is corrupted. In expression: ObjectInputStream .close() won't close the underlying stream after trying ObjectInputStream .readObject() on an input stream with a bad header. So
try(ObjectInputStream ois = new ObjectInputStream(new FileInputStream(...))) {
ois.readObject();
...
}
does NOT (!) reliably close the file handle! The safe way to go is to use try-with-resources directly on the file input stream
try(InputStream is = new FileInputStream(...)) {
ObjectInputStream ois = new ObjectInputStream(is);
ois.readObject();
...
}
and never on ObjectInputStream directly. Java is a very nice language in general, but this implementation does not live up to it. Please fix that and make it behave like everyone would expect.
REPRODUCIBILITY :
This bug can be reproduced always.
- relates to
-
JDK-8136895 Writer not closed with disk full error, file resource leaked
-
- Closed
-
ObjectInputStream does not reliably close the underlying stream
-
Bug
-
Resolution: Not an Issue
-
P4
-
None
-
8u66, 9
-
x86_64
-
windows_7
FULL PRODUCT VERSION :
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b18, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]
A DESCRIPTION OF THE PROBLEM :
I just spent hours to find out that the official ObjectInputStream Java class shows some pretty bad behavior if the input stream is corrupted. In expression: ObjectInputStream .close() won't close the underlying stream after trying ObjectInputStream .readObject() on an input stream with a bad header. So
try(ObjectInputStream ois = new ObjectInputStream(new FileInputStream(...))) {
ois.readObject();
...
}
does NOT (!) reliably close the file handle! The safe way to go is to use try-with-resources directly on the file input stream
try(InputStream is = new FileInputStream(...)) {
ObjectInputStream ois = new ObjectInputStream(is);
ois.readObject();
...
}
and never on ObjectInputStream directly. Java is a very nice language in general, but this implementation does not live up to it. Please fix that and make it behave like everyone would expect.
REPRODUCIBILITY :
This bug can be reproduced always.
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b18, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]
A DESCRIPTION OF THE PROBLEM :
I just spent hours to find out that the official ObjectInputStream Java class shows some pretty bad behavior if the input stream is corrupted. In expression: ObjectInputStream .close() won't close the underlying stream after trying ObjectInputStream .readObject() on an input stream with a bad header. So
try(ObjectInputStream ois = new ObjectInputStream(new FileInputStream(...))) {
ois.readObject();
...
}
does NOT (!) reliably close the file handle! The safe way to go is to use try-with-resources directly on the file input stream
try(InputStream is = new FileInputStream(...)) {
ObjectInputStream ois = new ObjectInputStream(is);
ois.readObject();
...
}
and never on ObjectInputStream directly. Java is a very nice language in general, but this implementation does not live up to it. Please fix that and make it behave like everyone would expect.
REPRODUCIBILITY :
This bug can be reproduced always.
- relates to
-
JDK-8136895 Writer not closed with disk full error, file resource leaked
-
- Closed
-