When I try to subclass FileReader:
package java.io; // this is true even if I put this in an other
package and import java.io.*
public class MockFileReader extends FileReader
{
public MockFileReader(String file)
{
}
}
I get:
MockFileReader.java:14: cannot find symbol
symbol : constructor FileReader()
location: class java.io.FileReader
{
Is there anyway to get around this... the context is in unit testing I
do want to use real files (for reasons that should be clear to most
unit test designers) but need to pass something that is a FileReader
(the formal param is a FileReader)
--Aryeh
Roedy Green - 29 Mar 2006 03:04 GMT
On 28 Mar 2006 17:55:47 -0800, "Aryeh.Friedman@gmail.com"
<Aryeh.Friedman@gmail.com> wrote, quoted or indirectly quoted someone
who said :
>package java.io; // this is true even if I put this in an other
>package and import java.io.*
That package is reserved for Sun. They sometimes let you extend
classes. Check if the class is public and not final.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Lee Weiner - 29 Mar 2006 03:07 GMT
>When I try to subclass FileReader:
>
[quoted text clipped - 14 lines]
>location: class java.io.FileReader
> {
There is no empty constructor in the FileReader class. When you execute the
constructor in your MockFileReader class, you have to call super() to execute
FileReader's constructor, and pass it the file string.
public MockFileReader(String file)
{
super( file );
}
Lee Weiner
lee AT leeweiner DOT org
Mike Schilling - 29 Mar 2006 07:16 GMT
> When I try to subclass FileReader:
>
[quoted text clipped - 17 lines]
> Is there anyway to get around this... the context is in unit testing I
> do want to use real files
I'm guessing there's a *not* missing.
> (for reasons that should be clear to most
> unit test designers) but need to pass something that is a FileReader
> (the formal param is a FileReader)
A subclass constructor has to call a base class constructor. Since all the
constructors of FileReader open files, your class is going to open a file,
like it or not. I suppose you could do something like
public MockFileReader(String dummyFile)
{
super(dummyFile)
}
where dummyFile is a file that your caller ensures exists, and then you
ignore the fact that it's open. (Though you should probably close it in
your close() method).
Why, though, would the formal param be a FileReader? There's nothing a
FileReader does that an InputStreamReader doesn't do, and little it does
that a generic Reader doesn't do. A method's parameters should in general
be as general as possible, and it's not really the method's business that
it's reading a file rather than some other source of characters. Change the
formal parameter to InputStreamReader or Reader , and you'll have no
difficulty creating a class your test can use.