InputStream is abstract, but...

java-programmer, InputStream is abstract, but... System has a static data member called in which is an InputStream object,
and has a non-abstract read() method - but the read() method of InputStream
is abstract.

Is the answer something to do with it being native code?

java-programmer >> InputStream is abstract, but... Walter Milner wrote:
> System has a static data member called in which is an InputStream object,
> and has a non-abstract read() method - but the read() method of InputStream
> is abstract.
>
> Is the answer something to do with it being native code?

No, simply that it's actually instantiated a class that extends
InputStream, but for which they just want to hold the handle as an
InputStream for the sake of convienence.

The following code, for example, is completely valid:

InputStream in = new FileInputStream(fileName);

The potential benifits of doing this are:

0) The end developer doesn't have to concern themselves with the
specifics of the implementation of the stream. They have access to the
most basic methods, and can use it anywhere they can use an InputStream, and

1) The JRE developer has some flexability as to which actual
InputStream implementation they use (including their own). If for
example some platform A needed some extra special buffering for I/O, it
could return a different stream object than platform B might. To have
each return a potentially different object class would be confusing to
developers, and would ruin Java's cross-platform capabilities (as the
API would be inconsistant between platforms), so instead they return the
most basic parent object class type.

HTH!

Brad BARCLAY

--
=-=-=-=-=-=-=-=-=
From the OS/2 WARP v4.5 Desktop of Brad BARCLAY.
The jSyncManager Project: http://www.jsyncmanager.org

java-programmer >> InputStream is abstract, but... Walter Milner wrote:

> InputStream is abstract, but
> System has a static data member called in which is an InputStream object,
> and has a non-abstract read() method - but the read() method of InputStream
> is abstract.

System.in is (a reference to) an instance of a concrete class
that extends the abstract InputStream class.
Which means it is also an instance of InputStream.

java-programmer >> InputStream is abstract, but... Thanks Brad
"Brad BARCLAY" <email***@***.com> wrote in message
news:jOUKb.18801$email***@***.com...
> Walter Milner wrote:
> > System has a static data member called in which is an InputStream
object,
> > and has a non-abstract read() method - but the read() method of
InputStream
> > is abstract.
> >
> > Is the answer something to do with it being native code?
>
> No, simply that it's actually instantiated a class that extends
> InputStream, but for which they just want to hold the handle as an
> InputStream for the sake of convienence.
>
> The following code, for example, is completely valid:
>
> InputStream in = new FileInputStream(fileName);
>
> The potential benifits of doing this are:
>
> 0) The end developer doesn't have to concern themselves with the
> specifics of the implementation of the stream. They have access to the
> most basic methods, and can use it anywhere they can use an InputStream,
and
>
> 1) The JRE developer has some flexability as to which actual
> InputStream implementation they use (including their own). If for
> example some platform A needed some extra special buffering for I/O, it
> could return a different stream object than platform B might. To have
> each return a potentially different object class would be confusing to
> developers, and would ruin Java's cross-platform capabilities (as the
> API would be inconsistant between platforms), so instead they return the
> most basic parent object class type.
>
> HTH!
>
> Brad BARCLAY
>
> --
> =-=-=-=-=-=-=-=-=
> From the OS/2 WARP v4.5 Desktop of Brad BARCLAY.
> The jSyncManager Project: http://www.jsyncmanager.org