Does it make sense to always wrap an InputStream as BufferedInputStream, when I know whether the given InputStream is something other than buffered? For e.g:
InputStream is = API.getFromSomewhere()
if(!(is instanceof BufferedInputStream))
return new BufferedInputStream(is);
return is;
I would not do that, I would leave it at the highest abstraction level possible. If you are not going to use tha mark and reset capabilities of a BufferedStream, why bother wrapping it?
If a consumer needs it, it is better to wrap it there.
It also depends on how you are going to read from the InputStream. If you are going to read it a character/byte at a time (ie read()), then the BufferedInputStream will reduce your overheads by queitly doing bulk reads on your behalf. If you are going to read it into a 4k or 8k byte/char array a block at a time then the BuffredInputStream probably won't benefit you.
Of course it depends on how the Stream is used. Sometimes buffering is not desired (e.g. if you want to read single bytes immediately after they arrive - using a buffered Stream would cause the read to block until the buffer is full, which in turn may cause a deadlock if some other application waits for a response). So as in the previous answer, buffering should only be used if you really know that all possible consumers can deal with it.
Does it make sense to always wrap an InputStream as BufferedInputStream, when I know whether the given InputStream is something other than buffered?
No.
It makes sense if you are likely to perform lots of small reads (one byte or a few bytes at a time), or if you want to use some of the higher level functionality offered by the BufferedInputStream API; for example the readLine method.
However, if you are only going to perform large block reads using the read(byte[]) and / or read(byte[], int, int) methods, wrapping the InputStream in a BufferedInputStream does not help. (And in response to @Peter Tillman's comment, the block read use-cases definitely represent more than 0.1% of uses of InputStream classes!!)
You may not always need buffering so, for that, the answer would be No, in some cases it's just overhead.
There is another reason it is "No" and it can be more serious. BufferedInputStream (or BufferedReader) can cause unpredictable failures when used with network socket when you also have enabled a timeout on the socket. The timeout can occur while reading a packet. You would no longer be able to access the data that were transferred to that point - even if you knew that there was some non-zero number of bytes (see java.net.SocketTimeoutException which is a subclass of java.io.InterruptedIOException so has bytesTransferred variable available).
If you are wondering how a socket timeout could occur while reading, just think of calling the read(bytes[]) method and the original packet that contains the message ended up being split but one of the partial packets is delayed beyond the timeout (or the remaining portion of the timeout). This can happen more frequently when wrapped again in something that implements java.io.DataInput (any of the reads for multiple byte values, like readLong() or readFully() or the BufferedReader.readLine() method.
Note that java.io.DataInputStream also is a bad candidate for socket streams that have a timeout since it doesn't behave well with timeout exceptions either.