Kev Jackson wrote:
>
> I'm coming round to think that Martijn's approach would be the least
> disruptive to the code base - simply as the delegate approach wouldn't
> mean recoding all tasks to use an interface instead of an
> implementation. This reduces the effort a lot and would make it less
>
FileUtils to select (Martijn's approach is
ridiculously insane enough to have captured my fancy
;) ), it must also take into account whether the
desired classes are available, falling back to the
basic impl. otherwise.
I'm coming round to think that Martijn's approach would be the least
disr
--- Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:
[SNIP]
>
> If anyway ResourceUtils does the work now,
> ResourceUtils could test
> whether running under Java 1.4 or more and call
> NIOUtils to do the work
> happening between lines 364 to 379 of ResourceUtils
> (copying files with no filters, n
--- Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:
[SNIP]
> One issue :
>
> If NIOFileUtils is in the same package as FileUtils,
> bootstrapping under
> JDK 1.2 or 1.3 would not work.
> The bootstrap scripts (build.bat, build.sh) are
> using primitive
> mechanisms (directories) to find out what s
Kev Jackson wrote:
>
>> In that case I would like some time to think things over, as to
>> provide one face, and to have different implementations for currently
>> different parts.
>> Classes that support copying, things that support permissions, things
>> that support path manipulation, without
Hello Kevin,
Kev Jackson wrote:
> Ok, this is what I've managed to bash together this morning:
>
> - NioFileUtils (uses Java1.4 NIO libraries, altered the TRANSFER_SIZE
> as suggested to 32000, currently no way to override that (yet))
> - Java6FileUtils (currently has no implementation, but could
Ist es nicht schrecklich, dass der menschlichen Klugheit so enge Grenzen
gesetzt sind und der menschlichen Dummheit überhaupt keine? (Konrad
Adenauer)
Isn't it terrible that so close borders are set to the human intelligence
and the human stupidity at all none?
This is a nice quote (tot
Ist es nicht schrecklich, dass der menschlichen Klugheit so enge
Grenzen gesetzt sind und der menschlichen Dummheit überhaupt keine?
(Konrad Adenauer)
Isn't it terrible that so close borders are set to the human
intelligence and the human stupidity at all none?
This is a nice quote (tot
Ist es nicht schrecklich, dass der menschlichen Klugheit so enge Grenzen
gesetzt sind und der menschlichen Dummheit überhaupt keine? (Konrad Adenauer)
Isn't it terrible that so close borders are set to the human intelligence and
the human stupidity at all none?
On Fri, 21 Apr 2006, Kev Jacks
In that case I would like some time to think things over, as to
provide one face, and to have different implementations for currently
different parts.
Classes that support copying, things that support permissions, things
that support path manipulation, without getting a really big number of
c
Kev Jackson wrote:
2) If the FileUtilsFactory is called from or implemented in
FileUtils.getFileUtils() / FileUtils.newFileUtils(), every task is
going to benefit.
I think the implementation I provided does precisely this, or rather
it calls from the interface (FileUtilsAdapter) instead of f
Martijn Kruithof wrote:
Hi,
Adding setting the property using -D to ANT_OPTS should do.
5 things:
1) I saw you removed public members (constants) from FileUtils (Non
backward compatible change, keeping everything BC also frustrates me
sometimes, but still I think it is best not to break par
Hi,
Adding setting the property using -D to ANT_OPTS should do.
5 things:
1) I saw you removed public members (constants) from FileUtils (Non
backward compatible change, keeping everything BC also frustrates me
sometimes, but still I think it is best not to break parts we do not
know of.)
Ok, this is what I've managed to bash together this morning:
- NioFileUtils (uses Java1.4 NIO libraries, altered the TRANSFER_SIZE as
suggested to 32000, currently no way to override that (yet))
- Java6FileUtils (currently has no implementation, but could be used in
future for implementing Java
> 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
>> We could use the buildfiles from the testcases. Just run as simple
>> builds and ignore their results. Just for having a bunch of
>buildfiles
>> ;-)
>> Realistic? .
>
>still not that accurate as it doesnt represent real builds.
>Better to turn off logging for a day and see how much faste
[EMAIL PROTECTED] wrote:
One thing I've always been curious about is how much speedup
we'd get by turning off all logging. That is, if I modified
log() to discard its contents, how much faster would
everything be? We couldnt use the test suite as a benchmark,
because too many tests depend on
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
Hi,
As promised, here's the code that I hacked together today at Antoine's
suggestion regarding a patch in bugzilla [1].
Feel free to tear it to pieces and point out obvious problems. I've
patched my version of copy to use this code instead of FileUtils
directly and so far there have been n
>One thing I've always been curious about is how much speedup
>we'd get by turning off all logging. That is, if I modified
>log() to discard its contents, how much faster would
>everything be? We couldnt use the test suite as a benchmark,
>because too many tests depend on the log, and it proba
Kev Jackson wrote:
If it came to it I'd -1 it too! I don't like any of the solutions I
could come up with yesterday, the one I showed was the 'least worst'
that I could think of, with a semi-upgrade path to Java5 style varargs
(use an object array). I was mainly throwing the idea out to se
Antoine Levy-Lambert wrote:
Matt Benson wrote:
Kev: I've asked some stuff about FileUtils before...
historically it was thought it might be pluggable,
hence all the instance methods. But that never
happened so the static methods crept in. I think it
was Martijn who really pushed in the Fil
Matt Benson wrote:
>
> Kev: I've asked some stuff about FileUtils before...
> historically it was thought it might be pluggable,
> hence all the instance methods. But that never
> happened so the static methods crept in. I think it
> was Martijn who really pushed in the FileUtils
> singleton. Mo
--- Kev Jackson <[EMAIL PROTECTED]> wrote:
> Dominique Devienne wrote:
>
> >>The point about building the strings when they
> aren't used (because
> >>logging verbosity is set too low) still stands
> though - this is less
> >>than efficient
> >>
> >>
> >
> >The point, which Matt already rai
Dominique Devienne wrote:
The point about building the strings when they aren't used (because
logging verbosity is set too low) still stands though - this is less
than efficient
The point, which Matt already raised, is that you can't know the level
at which the logger and the listeners ar
--- "Burgess, Benjamin" <[EMAIL PROTECTED]>
wrote:
> A good description of this comes from the JavaDocs
> for Log4j here:
>
>
http://logging.apache.org/log4j/docs/api/org/apache/log4j/Category.html#
> isDebugEnabled()
>
> So actually, you would only wrap the debug log
> statement in an
> if(log.
. Contains concatenation or creates an object).
Ben
-Original Message-
From: Steve Loughran [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 19, 2006 8:49 AM
To: Ant Developers List
Subject: Re: AW: Adding a methof to StringUtils
Kev Jackson wrote:
> [EMAIL PROTECTED] wrote:
>
>&
--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > The point about building the strings when they
> aren't used (because
> > logging verbosity is set too low) still stands
> though - this is less
> > than efficient
>
> The point, which Matt already raised, is that you
> can't know the level
>
> The point about building the strings when they aren't used (because
> logging verbosity is set too low) still stands though - this is less
> than efficient
The point, which Matt already raised, is that you can't know the level
at which the logger and the listeners are set. There is nothing ATM i
Kev Jackson wrote:
[EMAIL PROTECTED] wrote:
As I've been hacking away today, I've been swapping a load of "" + ""
+ "" style code over to use StringBuffers. I thought that perhaps
there's a potential use of a static method in StringUtils to
construct these strings from an array
For a s
javap -c AAA
public java.lang.String concat(java.lang.String, java.lang.String,
java.lang.String);
Code:
0: new #2; //class java/lang/StringBuilder
3: dup
4: invokespecial #3; //Method java/lang/StringBuilder."":()V
7: aload_1
8: invokevirtual #4; //Method
java/la
>Please, don't.
>
>Modern compilers already implement string addition using StringBuffer
>(1.4 already have this optimization, I don't remember about
>earlier versions).
>
>And 1.5 compiler can do it using StringBuilder which is faster.
Mmh so we should do the performance tests on a ??? 1.4
Kev Jackson wrote:
> It's less to do with speed performance and more to do with memory
> performance. "a" + "b" + "c" creates "a" + "bc" <- intermediate String,
> and then "abc"
Many years ago - yes, but not now.
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build
[EMAIL PROTECTED] wrote:
As I've been hacking away today, I've been swapping a load of
"" + "" + "" style code over to use StringBuffers. I thought
that perhaps there's a potential use of a static method in
StringUtils to construct these strings from an array
For a significant perform
>As I've been hacking away today, I've been swapping a load of
>"" + "" + "" style code over to use StringBuffers. I thought
>that perhaps there's a potential use of a static method in
>StringUtils to construct these strings from an array
For a significant performance boost we had to refactor
48 matches
Mail list logo
