ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Magesh Umasankar" <>
Subject Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/filters
Date Wed, 24 Apr 2002 15:31:04 GMT
----- Original Message -----
From: "Jon Skeet" <>

> I noticed a couple of oddities when fixing this up:
> o readLine doesn't do the "normal" thing of coping with \r, \n or \r\n. It
does, however,
> include the '\n' in the string, which is probably correct given usage.

This is by design.  We are interested in returning
the line with the EOL characters intact - hence,
we keep adding characters to the line till we reach
'\n' and include that too.

> o The no-arg constructor claims to be there just for Ant's introspector:
when does Ant's
> introspector actually *need* this? What would break if we got rid of it?
Ant shouldn't be
> trying to create any instances of this anyway, as it's abstract.

Let me try to explain the implementation -
it may seem a bit complex - so be warned ;-)

Let us say you define the following:
        <reader1 att1="blah"/>
        <reader2 att2="blee"/>

When Ant's introspector adds the filterchain element,
it instantiates the relevant class of reader1 by invoking
its no-arg constructor and then invokes its setAtt1(...)
method.  It then invokes readers's class's no-arg constructor
followed by calling its setAtt2(...) method.  Please note that
we are trying to 'chain' these filterreaders, however, we still
do not have access to the underlying inputstream.  Therefore,
at the end of the Introspection, all we have is a bunch of
'dummy' unusable readers which are not really chained.  This
is where the no-arg constructor that you see in BaseFilterReader
gets used...
Now, when the wrapper task (in this case, <copy>), starts working
through its input streams, the ChainReaderHelper invokes the
filterreader's chain method which chains one reader with another
by invoking the constructor that takes in the InputStream as
argument and then sets the new reader's state.  This is how the
unchained readers created by Introspector gets chained (cloned,
too, in a way) 'during' the execution of the task.

So, why is the constructor present in the abstract class??
The inheriting classes anyway have to explicitly define a
no-arg constructor because of reasons explained above and also
because there will be another non-default constructor.  However,
the code that would go into these constructors are going to be
exactly the same.  So, if the contents of such a constructor is
moved to the superclass's constructor, all it needs to do is
invoke super();  So, the ctor is there in the abstract base
class just to inherit common functionality.

Hope this clarifies the code better.  The ctor in the
abstract base class needs to stay...

> Jon


* Courage is acting as if your hands aren't  *
* trembling.                                 *

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message