ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <>
Subject Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Date Tue, 14 Feb 2012 19:35:53 GMT

On 2/13/2012 2:55 PM, Jesse Glick wrote:
> On 02/13/2012 01:25 PM, Bruce Atherton wrote:
>> could Java 7 and NIO 2.0 be a good reason to create Ant 2.0?
> While the new java.nio.file.* APIs are indeed valuable for a tool like 
> Ant, I hardly think a fork or major rewrite is required to take 
> advantage of them. As Stefan pointed out, it would be as easy as 
> creating a new FileUtils subclass, and for now compiling it conditionally.

Required, no. If there is not enough interest in creating an Ant 2 then 
everything will be fine staying with Ant 1.x. We've been doing it 
through massive changes in the Java libraries and we can keep doing it 
the same way. If there aren't enough people interested in doing the work 
then we should just drop it.

But I've talked about a few of the advantages I see in dropping backward 
API compatibility and doing a major refactoring. Let me list a few more.

My biggest problem with Ant is the many ways that files are dealt with. 
It is all over the map. This isn't anyone's fault, it happened because 
of hysterical porpoises, but both our users and ourselves have to deal 
with the fallout.

Users have to deal with understanding the differences between paths and 
filelists and filesets and dirsets and resources.  They have to come to 
grips with how <include> and <exclude> don't work like selectors. 
Filters aren't much better since there are different ways that they can 

We have it a bit easier because under the covers most things have been 
normalized. Resources, for example. But thanks to API compatibility that 
brings its own problems. For example, we have two completely separate 
yet very similar set of classes for Selectors, one for FileSelectors and 
one for ResourceSelectors. Fix a bug in one, did you remember to fix it 
in the other? Does it matter if users of the FileSelector APIs still 
have the bug?

Or look at the utility classes. How many methods, or lines of extra code 
in methods that should be relatively simple, are devoted to dealing with 
edge cases and these hangers on from our past?

All of these things were an itch bad enough that I started to scratch 
it, but for now I won't be doing any coding at all for a while. Maybe, 
though, there are others who are as bothered by these things as I am who 
are looking for a scratching post.

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

View raw message