Does FileInputStream reimplement mark() ?

I don't know the answer, but I know where you can find it...
the entire source code of the API classes is freely downloadable from
http://download.java.net/jdk6/source/
so you can look at the code and see exactly how it is written.

Thanks. I read the code here : http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/io/FileInputStream.java The mark() method is indeed not implemented. The mark() method of InputStream is also empty. Then, how is it that calling markSupported() on a FileInputStream object returns true ? The code was

import java.io.*;
class ana
{
	public static void main(String aa[])throws IOException
	{
		BufferedInputStream a=new BufferedInputStream(new FileInputStream("faltu1.java"));
		System.out.println(a.markSupported());
	}
}

However, if I do this :

System.out.println (new FileInputStream("faltu1.java").markSupported());

it returns false.

Could it be that BufferedInputStream implements it?

Yes which seems pretty logical given the context in which mark() and reset() methods are used i.e. the "going back" to a mark would be only supported if the underlying stream supports either random FP seeks(RandomAccessFile) or a buffered nature (BufferedInputStream).

Thanks. But then why do the docs say that calling markSupported() on an object of FilterInputStream's subclass (like BufferedInputStream) performs in.markSupported() where "in" is the underlying InputStream ?

At one place it says that that BufferedInputStream adds the mark functionality to InputStreams. If its simply calling the underlying streams mark() method, how is it adding anything ?

But then why do the docs say that calling markSupported() on an object of FilterInputStream's subclass (like BufferedInputStream) performs in.markSupported() where "in" is the underlying InputStream ?

Because that's what it is; calling mark/reset/markSupported on FilterInputStream *delegates* the call to the InputStream instance with which the FilterInputStream was created. This instance can be *anything* which extends the InputStream class.

At one place it says that that BufferedInputStream adds the mark functionality to InputStreams. If its simply calling the underlying streams mark() method, how is it adding anything ?

I think you are reading docs the wrong way; if a given class *overrides* a given functionality of its superclass, you read the Javadoc for that overridden part instead of the original one present in the superclass.

calling mark/reset/markSupported on FilterInputStream *delegates* the call to the InputStream instance with which the FilterInputStream was created. This instance can be *anything* which extends the InputStream class.

It can delegate the call to the mark/reset method of the underlying InputStream object only if that underlying object has an implementation for mark/reset. Assuming that underlying instance is of FileInputStream, FileInputStream doesn't have an implementation for mark/reset ( I take delegating here to mean calling the function with the same name on the underlying object ) other than the empty one inherited from InputStream. So what is BufferedInputStream delegating the mark() function call to ?

The API doc BufferedInputStream has, as its very first sentence:

A BufferedInputStream adds functionality to another input stream-namely, the ability to buffer the input and to support the mark and reset methods

and the source code for BufferedInputStream includes this:

public synchronized void mark(int readlimit) {
	marklimit = readlimit;
	markpos = pos;
    }
...
    public synchronized void reset() throws IOException {
        getBufIfOpen(); // Cause exception if closed
	if (markpos < 0)
	    throw new IOException("Resetting to invalid mark");
	pos = markpos;
    }

I guess that's pretty clear then?

Thanks. I was thinking BufferedInputStream's markSupported()'s contract was the same as InputStream()'s which stated that the underlying input stream's markSupported() would be called. Probably that was what S.O.S was also trying to say, but I didn't get it. Thanks again.