Stefan Bodewig wrote:
On Thu, 20 Apr 2006, Matt Benson <[EMAIL PROTECTED]> wrote:
--- Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:
NioFileUtils should go into another package
org.apache.tools.ant.util.java14 otherwise we are going to have
build problems under java 1.2 This should be entere
On Thu, 20 Apr 2006, Matt Benson <[EMAIL PROTECTED]> wrote:
> --- Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:
>> NioFileUtils should go into another package
>> org.apache.tools.ant.util.java14 otherwise we are going to have
>> build problems under java 1.2 This should be entered in the
>> buil
On Thu, 20 Apr 2006, Matt Benson <[EMAIL PROTECTED]> wrote:
> Another thought about the factory--it should cache an
> instance of each FileUtils type to minimize object
> creation. We can either just have it be known that
> FileUtilsAdapter impls should be stateless or have a
> StatelessFileUtils
> You do not gain by using nio when copying files to a local drive.
As far as I know, you do gain a little, in the flexibility offered
(memory mapped files, channels etc). The code is also (usually) much
easier to maintain compared to standard IO.
>
> I do not know what in the implementation of
> I'm afraid I've never studied nio in much detail... do
> its performance enhancements extend to non-file-based
> IO?
>
> -Matt
Hello Matt,
I never studied nio in detail either.
What I found out empirically in a Windows environment is that copying
files to a share goes about 4 times faster whe
--- Martijn Kruithof <[EMAIL PROTECTED]> wrote:
> Matt Benson schreef:
>
> >viewcvs(svn) shows I did it 6.5 months ago...
> >apparently so. Speaking of which, Kev (I think)
> >mentioned these are static in ResourceUtils, but as
> >they are unreleased we could change them to
> instance
> >methods
Matt Benson schreef:
viewcvs(svn) shows I did it 6.5 months ago...
apparently so. Speaking of which, Kev (I think)
mentioned these are static in ResourceUtils, but as
they are unreleased we could change them to instance
methods. The behavior there is fairly
straightforward, though, so I'm not
--- Martijn Kruithof <[EMAIL PROTECTED]> wrote:
> Matt Benson schreef:
>
> >Another thought about the factory--it should cache
> an
> >instance of each FileUtils type to minimize object
> >creation. We can either just have it be known that
> >FileUtilsAdapter impls should be stateless or have
>
Matt Benson schreef:
Another thought about the factory--it should cache an
instance of each FileUtils type to minimize object
creation. We can either just have it be known that
FileUtilsAdapter impls should be stateless or have a
StatelessFileUtilsAdapter interface--if implemented,
cache, else
O by the way I am / was looking if FileUtils could be split into os
dependend version this way, so I actually did some work on this as well.
Martijn Kruithof schreef:
I actually had a similar problem in my dtd work recently.
We had a class that applied one single strategy to determine somethi
I actually had a similar problem in my dtd work recently.
We had a class that applied one single strategy to determine something
important for telecommunication systems, had some static methods, some
nonstatic methods, was used by different components of which some could
not be updated.
Backwa
Matt Benson wrote:
Another thought about the factory--it should cache an
instance of each FileUtils type to minimize object
creation. We can either just have it be known that
FileUtilsAdapter impls should be stateless or have a
StatelessFileUtilsAdapter interface--if implemented,
cache, else don
Another thought about the factory--it should cache an
instance of each FileUtils type to minimize object
creation. We can either just have it be known that
FileUtilsAdapter impls should be stateless or have a
StatelessFileUtilsAdapter interface--if implemented,
cache, else don't.
thoughts?
-Matt
--- Kevin Jackson <[EMAIL PROTECTED]> wrote:
> > I found it in Kev's (long :) mail:
> >
>
> Sorry it was rather long, but there were a few files
> packed in there!
parenthetical smiley above.
> > Since the other impls will be conditionally
> compiled,
> > we should use Class.forInstance()...
>
Kevin Jackson wrote:
I found it in Kev's (long :) mail:
Sorry it was rather long, but there were a few files packed in there!
No problem, I should have washed my glasses this morning, ...
Since the other impls will be conditionally compiled,
we should use Class.forInstance()...
> I found it in Kev's (long :) mail:
>
Sorry it was rather long, but there were a few files packed in there!
> Since the other impls will be conditionally compiled,
> we should use Class.forInstance()...
>
ok, so we use dynamic class-loading to get the correct fileutils? Is
there an example in t
--- Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:
> Hello Kevin,
>
> NioFileUtils should go into another package
> org.apache.tools.ant.util.java14 otherwise we are
> going to have build
> problems under java 1.2
> This should be entered in the build.xml (selector
> needs.jdk14+)
> Therefore Ni
Hello Kevin,
NioFileUtils should go into another package
org.apache.tools.ant.util.java14 otherwise we are going to have build
problems under java 1.2
This should be entered in the build.xml (selector needs.jdk14+)
Therefore NioFileUtils would be packaged in ant-nodeps.jar
We need also a FileUtil
18 matches
Mail list logo
