ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey N. Solofnenko" <>
Subject Re: DO NOT REPLY [Bug 42219] - Inefficient code in Union, DirectoryScanner makes large copy tasks very slow
Date Thu, 26 Apr 2007 16:03:42 GMT
Classpath ordering is a usual practice that is used, for example, for 
patching. The same classpath order could be used in debugger too. In our 
case it could be hidden inside launcher. But there are other ways to 
achieve the same - for example, factories that can return Java6 specific 
FileResource, but it is cumbersome: 
(FileResource)project.createObject("org.apache....FileResource"). The 
later has its advantages too - project could configure the class to 
support permissions or not.

This follows to settings. I think we could put the settings in the 
project class (as get/set methods or somehow else) - support or not 
permissions, old/new behaviour is not a property of the environment, but 
it is a property of a specific build script.

- Alexey.

Steve Loughran wrote:
> Alexey N. Solofnenko wrote:
> Relying on order of stuff in classloaders is just wrong.
> -gets complicated when you bring signing into the bix
> -gets complex when the IDE sets up the build order
> -makes debugging a PITA.
>> I think we should not limit supported features supported by modern 
>> Java while keeping backward compatibility with older versions. One 
>> way is to use reflection. Another is to provide an alternative 
>> implementation of some classes (FileResource) to be used with modern 
>> Java. The later is straightforward, but the most recent Java is 
>> required to build it.
> That's effectively what we do at build need to build under 
> 1.5 to get everything compiled, though we omit the stuff to let people 
> still build on java 1.3+.
> For the proxy diagnostics, I abuse the toString() method, so we just 
> cast the proxy diags to a method and do it from there. For the other 
> stuff, well, there's nothing to stop FileUtils looking for a subclass 
> of itself if it is there
>> If something could be done better with modern Java, why not to use it 
>> when possible?
> Only one reason: when it makes backwards compatibility odd, or screws 
> up x-platformness. For example, for all the failings with file perms 
> on java, requiring people to spec permissions when tarring a folder 
> guarantees that the permissions in the tar get set in all platforms
> At the same time, sometimes I do want copy to preserve stuff, untar to 
> propagate permissions, at least on unix. I may even want to use file 
> permissions as a selector, selecting all files that are executable for 
> some further action. As long as people understand the operations are 
> not portable, well, they have the right to use them.
> Perhaps a limited set of operations could have permissions enabled, 
> with some enum like
> permissions="always"   - copy all perms, fail if we are a windows box 
> or if the build doesnt allow it (wrong JVM, wrong class file)
> permissions="never"     -the default
> permissions="optional"  -copy perms if the JVM is right and the OS 
> supports perms.
> we could also add another Permissions interface to resources, so you 
> can read/write perms of files. This would work inside zip/tar files 
> today, and on filesystem files on Java6+unix.
> I worry about what cygwin does does it manage permissions? 
> Because people are going to be disappointed if they expect ant to 
> handle it.
> -Steve
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Alexey N. Solofnenko <>
Pleasant Hill, CA (GMT-8 usually)

View raw message