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
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
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.)
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
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
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
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
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
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 be
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 getting a
--- 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 should be
--- 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, no bells
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. Most
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
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 probably
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
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
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 faster
gump
--- 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 NioFileUtils
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 the
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
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 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
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
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
--- 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
a
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:
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
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
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
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 the
[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 performance
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 1.5.0_06-b05)
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/1.5
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.init:()V
7: aload_1
8: invokevirtual #4; //Method
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
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 in
--- 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
at which the
. 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:
As I've been
--- 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.isDebug())
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
--- 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 raised, is that you
can't
42 matches
Mail list logo
