ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <>
Subject Re: Virtual FileSystem Layer
Date Sat, 29 Dec 2001 16:07:12 GMT
 --- Stefan Bodewig <> wrote: > On
Sat, 22 Dec 2001, Peter Donald <>
> wrote:
> > JNDI is nice. It will be slower - a lot slower -
> and a bit more
> > memory hungry ... whether this is an issue or not
> is another thing
> > altogether.
> This could become a big issue, at least the "a lot
> slower" part.  All
> the crude "are we doing a slow scan" parts in
> DirectoryScanner are
> there because Ant 1.1 has simply been too slow when
> scanning large
> directory trees.  Even now, most time of the javac
> task will be spent
> scanning the source tree for files that match
> **/*.java - the
> compilation itself will probably be a lot faster (at
> least when using
> jikes or modern).  <javac>'s perfomance is one of
> Ant's big pros, so
> we shouldn't destroy that 8-)
> Any estimate how bad the performance of JNDI
> compared to direct file
> access is?  Can we implement a hybrid solution that
> uses direct file
> system access when we know that we are talking about
> plain local
> files?

JNDI is an empty shell. It all depends on the
implementation of the providers. They can be very
smart or they can be very stupid. For example the
directory search capabilities of JNDI can be
implemented in a provider so that it understands ´**´
and so on directly and evaluates them on the native
provider code (smart) or it can be scanning and
creating JNDI objects which are filtered after being
created (stupid). 

The problem with JNDI is that it is easy to write
stupid providers, and it could be hard work to
implement smart ones.

Jose Alberto

Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts

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

View raw message