I'am trying to write the inputstream image to OutputStream to display the image in the browser this is the code:
try
{
InputStream input = Filer.readImage("images/test.jpg");
byte[] buffer = new byte[1024];
int bytesRead;
while ((bytesRead = input.read(buffer)) != -1)
{
responseBody.write(buffer, 0, bytesRead);
}
}
catch(IOException e)
{
System.out.println(e);
}
the readImage:
public static InputStream readImage(String file) throws IOException {
try (InputStream input = new FileInputStream(file)) {
return input;
}
}
but I get an error while writing:
java.io.IOException: Stream Closed
any ideas?
The try-with-resources closes the stream when you exit the block
try (InputStream input = new FileInputStream(file)) {
ie. when your method returns.
Just remove it and take care of closing the stream at the end of your other method body.
As stated in the comments, here's a link to the official tutorial on try-with-resources.
Taken from oracle tutorial the resource is closed when the statement completes:
The try-with-resources statement ensures that each resource is closed at the end of the statement. Any object that implements java.lang.AutoCloseable, which includes all objects which implement java.io.Closeable, can be used as a resource.
Prior to Java SE 7, you can use a finally block to ensure that a resource is closed regardless of whether the try statement completes normally or abruptly. The following example uses a finally block instead of a try-with-resources statement:
Related
here is the code.
public static void main(String[] args) throws IOException {
FileInputStream fis = null;
fis = new FileInputStream(new File("D:\\za180s.ser"));
// do something
fis = new FileInputStream(new File("D:\\za185s.ser"));
// do something
fis = new FileInputStream(new File("D:\\za186s.ser"));
// do something
fis = new FileInputStream(new File("D:\\za187s.ser"));
// do something
fis.close();
}
the problem is : need i call fis.close() method after every "do something" or i just call fis.close() once after all.
ignore whether the close() position in finally and the code need try catch or not.
thx all.
Yes, you need to call close on each individual InputStream. The problem with your code is that you're reassigning the variable fis each time you create a new stream. In other words: fis no longer points to the old InputStream, so calling close will not close the previous stream.
For more information, check https://stackoverflow.com/a/40523/8819761
What you could also do is use Java 7's try-with-resources syntax, which will auto-close the stream once you exit the try block:
try (InputStream fis = new FileInputSteam(yourFile)) {
// Do something
}
try (InputStream fis = new FileInputSteam(yourFile)) {
// Do something else
}
You have to do close everytime you finish working with InputStream.
In java, if you assign
fis = new FileInputStream(new File("D:\\za180s.ser"));
fis will point to the new object so when you call fis.close() the old streams are not affected. And there is no way to close it.
You need to call close method every time but don't worry now.From Java SE 7 you can use try-with-resources. As per Java-Oracle Doc,
The try-with-resources statement is a try statement that declares one
or more resources. A resource is an object that must be closed after
the program is finished with it. The try-with-resources statement
ensures that each resource is closed at the end of the statement. Any
object that implements java.lang.AutoCloseable, which includes all
objects which implement java.io.Closeable, can be used as a resource.
Please have a look on example.
static String readFirstLineFromFile(String path) throws IOException {
try (BufferedReader br =
new BufferedReader(new FileReader(path))) {
return br.readLine();
}
}
In this example, the resource declared in the try-with-resources statement is a BufferedReader. The declaration statement appears within parentheses immediately after the try keyword. The class BufferedReader, in Java SE 7 and later, implements the interface java.lang.AutoCloseable. Because the BufferedReader instance is declared in a try-with-resource statement, it will be closed regardless of whether the try statement completes normally or abruptly (as a result of the method BufferedReader.readLine throwing an IOException).
For more details, Please have a look on Oracle-Java doc for try-with-resources.
https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html
This question already has an answer here:
Why is ObjectInputStream readObject() throwing EOF exception
(1 answer)
Closed 7 years ago.
So, I write an object to a client like so:
ObjectOutputStream out = new ObjectOutputStream(client.getOutputStream());
out.writeObject(args);
out.close();
And receive the object on the client side like so:
ObjectInputStream in = new ObjectInputStream(connection.getInputStream());
Object objIn;
while(true) {
if((objIn = in.readObject()) != null) {
//work with obj
}
}
I never create an output stream on the client side or an input stream on the server side.
Also, the object I send is serializable.
Thanks for you help!
EDIT: The "duplicate" of this question doesn't help me answer my problem, so this one is not a duplicate.
while(true) {
if((objIn = in.readObject()) != null) {
//work with obj
}
}
Q. Why are you testing for null? Are you planning on sending a null? Because that's the only time you'll ever get one.
A. Because you think readObject() returns null at end of stream. Although you've left out the break that would escape the infinite loop.
It doesn't. It throws EOFException. So your loop should look like this:
try
{
while(true) {
objIn = in.readObject();
//work with obj
}
}
catch (EOFException exc)
{
// end of stream
}
finally
{
in.close();
}
Assuming you received the exception while reading the input stream from connection Object .
If you already invoked the connection.getInputStream() prior to the above cited code for input stream you will receive a EOF exception . Because the input Stream in the connection object is already consumed .
related topic
One solution to such problem is to write the content of the input stream in a Random access file as they enables you to traverse through the file .
public static RandomAccessFile toRandomAccessFile(InputStream is, File tempFile) throws IOException
{
RandomAccessFile raf = new RandomAccessFile(tempFile, "rwd");
byte[] buffer = new byte[2048];
int tmp = 0;
while ((tmp = is.read(buffer)) != -1)
{
raf.write(buffer, 0, tmp);
}
raf.seek(0);
return raf;
}
Later you can always read from the file as follows .
public static InputStream toInputStream(RandomAccessFile file) throws IOException
{
file.seek(0); /// read from the start of the file
InputStream inputStream = Channels.newInputStream(file.getChannel());
return inputStream;
}
This question already has answers here:
Closing inputstreams in Java
(6 answers)
Closed 3 years ago.
InputStream in = SomeClass.getInputStream(...);
BufferedInputStream bis = new BufferedInputStream(in);
try {
// read data from bis
} finally {
bis.close();
in.close();
}
The javadoc for BufferedInputStream.close() doesn't mention whether or not the underlying stream is closed:
Closes this input stream and releases any system resources associated
with the stream. Once the stream has been closed, further read(),
available(), reset(), or skip() invocations will throw an IOException.
Closing a previously closed stream has no effect.
Is the explicit call to in.close() necessary, or should it be closed by the call to bis.close()?
From the source code of BufferedInputStream :
public void close() throws IOException {
byte[] buffer;
while ( (buffer = buf) != null) {
if (bufUpdater.compareAndSet(this, buffer, null)) {
InputStream input = in;
in = null;
if (input != null)
input.close();
return;
}
// Else retry in case a new buf was CASed in fill()
}
}
So the answer would be : YES
BufferedInputStream doesn't hold any system resources itself; it simply wraps around an InputStream which holds those resources. Therefore the BufferedInputStream forwards the close operation onto the wrapped InputStream which will then release its resources.
When you close a BufferedInputStream, the underlying InputStream is indeed also closed. :)
Yes. The underlying stream will be closed.
Here is the Java implementation
/**
* Closes this input stream and releases any system resources
* associated with the stream.
* Once the stream has been closed, further read(), available(), reset(),
* or skip() invocations will throw an IOException.
* Closing a previously closed stream has no effect.
*
* #exception IOException if an I/O error occurs.
*/
public void close() throws IOException {
byte[] buffer;
while ( (buffer = buf) != null) {
if (bufUpdater.compareAndSet(this, buffer, null)) {
InputStream input = in;
in = null;
if (input != null)
input.close();
return;
}
// Else retry in case a new buf was CASed in fill()
}
}
So, the stream will be closed
Are the following try-with blocks similar? Will the dataSocket.getOutputStream() be closed in both cases?
a)
try (Socket dataSocket = new Socket(...);
OutputStream socketStream = dataSocket.getOutputStream();
BufferedOutputStream outputStream = new BufferedOutputStream(socketStream)
) {.....}
b)
try (Socket dataSocket = new Socket(...);
BufferedOutputStream outputStream = new BufferedOutputStream(dataSocket.getOutputStream())
) {.....}
Note. in b) there is no explicit variable for dataSocket.getOutputStream(), in a) we have socketStream.
According to BufferedOutputStream JavaDoc,
Closes this output stream and releases any system resources associated with the stream.
Closing outputStream would close the underlying outputstream. This is also proven in the source code of BufferedOutputStream's close() method.
public void close() throws IOException {
try {
flush();
} catch (IOException ignored) {
}
out.close();
}
Yes, it will be closed in both cases. Even using only Socket sentence, they should be closed. When socket is closed, streams are closed. Anyway, I prefer explicity add Streams declaration on try-with structure.
I have this method:
private void unZipElementsTo(String inputZipFileName, String destPath) throws FileNotFoundException, IOException {
OutputStream out = null;
InputStream in = null;
ZipFile zf = null;
try {
zf = new ZipFile(inputZipFileName);
for (Enumeration<? extends ZipEntry> em = zf.entries(); em.hasMoreElements();) {
ZipEntry entry = em.nextElement();
String targetFile = destPath + FILE_SEPARATOR + entry.toString().replace("/", FILE_SEPARATOR);
File temp = new File(targetFile);
if (!temp.getParentFile().exists()) {
temp.getParentFile().mkdirs();
}
in = zf.getInputStream(entry);
out = new FileOutputStream(targetFile);
byte[] buf = new byte[4096];
int len;
while ((len = in.read(buf)) > 0) {
out.write(buf, 0, len);
}
out.flush();
out.close();
in.close();
}
}
finally
{
if (out!=null) out.close();
if (zf!=null) zf.close();
if (in!=null) in.close();
}
}
For this method Sonar give me this Violation:
Bad practice - Method may fail to close stream on exception
unZipElementsTo(String, String) may fail to close stream on exception
But, I don't see any violations there. Maybe, it is just a False-positive ?
That's right.
The OutputStream.close() method can itself throw an exception.
If this happens, e.g. on the 1st line of your finally{} block, then the other streams will be left open.
If out.close() or zf.close() in the finally block throw an exception then the other closes won't be executed.
Alternatively if you're using Java 7 or better, you can use the new try-with-resources mechanism, which handles the close for you. See: http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html for details on this new mechanism.
Note that try-with-resources also works with multiple objects that are opened and closed and still preserves the guarantee that objects will be closed in the reverse order of their construction. Quoth that same page:
Note that the close methods of resources are called in the opposite order of their creation.
To avoid masking an exception with an exception during the close of the streams
It's often recommended to "hide" any io exception in the finally.
To fix use the org.apache.commons.io.IOUtils.closeQuietly(...)
or guava Closeables.html#closeQuietly(java.io.Closeable)
in the finally close
more on exception handling issues :
http://mestachs.wordpress.com/2012/10/10/through-the-eyes-of-sonar-exception-handling/