ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Re: Reasons why Java 7 got me excited about Ant 2
Date Sun, 26 Feb 2012 18:09:44 GMT

Le 26 févr. 2012 à 18:12, Mansour Al Akeel a écrit :

> Java is widely used and accepted. Scala is functional and it could be more
> suitable for a build system, however, I don't see enough reasons for the
> core to be written with scala or any other language.
> I think it's better to keep it in java, and allow the addition of plugins
> written in other languages the works with JVM (scala, groovy, ... etc).
> This will allow contribution from users experts in java.


And knowing that scala is not stable yet (they break bytecode backward compatibility regularly),
maintaining an binary API would be quite complicated. Let's stick the core of Ant to Java.


> 2012/2/26 wolfgang häfelinger <>
>> Hi there,
>> how about rewriting Ant 2.0 using Scala? Scala appears to be well
>> suited as a scripting language. Charged with a scripting language, I
>> could write low level macros on the fly.
>> // Wolfgang
>> On Fri, Feb 17, 2012 at 2:31 AM, Bruce Atherton <>
>> wrote:
>>> I thought I'd expand on why I got so excited about NIO 2.0 and JSR 203 as
>>> well as the other changes in Java 7. I can see I have done a bad job of
>>> selling the benefits of a refactoring for potential volunteers. Reading
>>> through the changes that were introduced in Java 7, it seems to me that
>> Ant
>>> was probably an inspiration for a lot of them.
>>> Others come from taking the performance of I/O on Java more seriously.
>> This
>>> has the potential to speed Ant up enormously. Projects like Tim Bray's
>> Wide
>>> Finder 2[1] showcased just how badly Java performed and benchmarks like
>> that
>>> may have been an impetus to focus resources on taking advantage of all
>> the
>>> features of the native filesystems. Unfortunately the results of the
>> project
>>> are lost due to Oracle's acquisition of Sun, but you can still see the
>>> results from the original Wide Finder 1[2] although there isn't even an
>>> attempt to do a Java implementation there. I can tell you from memory
>> that
>>> the final results on WF2 were several C implementations with innovative
>> I/O
>>> using parallel processing at the top, erlang and ruby and scala were up
>>> there, but the fastest Java implementation was in the double digits in
>> the
>>> list as I recall.
>>> The basics for file handling in Java 7 are provided by Path and the Paths
>>> Utility class, along with the FileSystemProvider classes. If Ant 2 were
>>> created to make Resource a fundamental element and Path the Resource that
>>> represented something on a file system (native file systems, zip/jar file
>>> systems, and I expect eventually open source projects will add others
>> like
>>> HTTP, FTP, NFS and Samba), I think the LOC count on Ant could be reduced
>>> tremendously. Writing patches would be simplified and contributing to Ant
>>> would have a lower barrier to entry for new people coming in. Path is
>>> immutable which suits Ant well. Path has methods to access elements in a
>>> file path, compare, test, normalize, and relativize paths in the ways
>> that
>>> Ant has code to do. It has all kinds of features for determining
>>> accessibility on the native filesystem and bulk loading file metadata
>>> attributes whereas currently it is done one field at a time. Symbolic
>> link
>>> identification and handling is a core feature. And converting to and from
>>> File objects is trivial.
>>> Add to that the new methods on File. There is also a Files utility helper
>>> class. Files covers the most basic tasks in Ant implemented using all the
>>> features of the native filesystem to make them as fast as possible:
>> copying;
>>> deleting; moving; reading file contents; writing; creating directories,
>> file
>>> and links; getting input and output streams. There is also recursion
>> with a
>>> method for walking a file tree that creates a FileVisitor interface
>>> implementation, either default or custom, with 3 phases: previsit
>> directory,
>>> visit file, and postvisit directory. It also provides for a visit file
>>> failed method. At each point you can continue, stop, skip subtree, or
>> skip
>>> other entries in the current directory. Options control whether symlinks
>> are
>>> followed, and cycles are detected.
>>> DirectoryStream includes filters like glob, regex, and custom
>>> implementations that could be perfect for implementing Selectors.
>>> DirectoryStream uses less resources and works much better with remote
>>> resources. It also handles directories that are very large much more
>>> efficiently.
>>> Error handling throughout is by exception rather than boolean value as
>> it is
>>> now, which I'm sure we all agree is preferable.
>>> Then there is the Watch Service which uses the native eventing service if
>>> available, where you can get events in your build when a file is created
>> or
>>> deleted, or when a directory is modified. Would we translate it into
>>> something for BuildListeners? How would we harness it, scheduling a
>> target
>>> and its dependencies when the a watch fired an event?
>>> I could keep going  but this is getting rather long. I'll just point out
>> a
>>> few resources from other people that are clearer than I am and have more
>>> detail: The Java 7 feature list[3] is comprehensive but has little on the
>>> impact of features; this Doctor Dobbs post[4] has good code examples for
>> how
>>> NIO 2 could be used by Ant; an article listing "8 things I found most
>>> useful"[5], all of which are relevant to a simplified Ant implementation,
>>> details the NIO 2 changes at #8; interviews with Alan Bateman in text[6],
>>> video[7], and podcast[8] are interesting, as is a JavaOne 2011 slide
>>> show[9];  Leandro Pezzente sent me a link[10] (thanks, Leandro) that
>> lists
>>> some of the other changes to Java 7 to think about, although it only
>>> mentions the file system changes that JSR 203 introduces in passing.
>>> [1]
>>> [2]
>>> [3]
>>> [4]
>>> [5]
>>> [6]
>>> [7]
>>> [8]
>>> [9]
>>> [10]
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> --
>> Wolfgang Häfelinger
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

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

View raw message