ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: [patch] NioFileUtils, FileUtilsAdapter + factory (was Re: AW: Adding a methof to StringUtils)
Date Thu, 20 Apr 2006 14:29:22 GMT
--- Antoine Levy-Lambert <antoine@gmx.de> 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 would be packaged in
> ant-nodeps.jar
> 
I don't really care either way here, but couldn't we
explicitly exclude the file(s)?  Why must they live in
another directory?

> We need also a FileUtilsFactory. The
> FileUtilsFactory would instantiate
> NioFileUtils if the java runtime is 1.4 or 1.5, the
> normal FileUtils
> otherwise.
> This should be developed along the lines of the
> RegexpFactory, which
> means no imports of optional classes such as
> NioFileUtils or
> Java16FileUtils.

I found it in Kev's (long :) mail:

package org.apache.tools.ant.util;

public class FileUtilsAdapterFactory {

    private FileUtilsAdapterFactory() {}
    
    public static FileUtilsAdapter getFileUtils(final
String type) {
        if (type.equals("nio")) {
            //just print out to see if it's actually
picking up the correct class
            System.out.println("Using nio fileutils");
            return new NioFileUtils();
        } else if (type.equals("java6")) {
            System.out.println("Using java6
fileutils");
            return new Java6FileUtils();
        } else {
            System.out.println("Using classic
fileutils");
            return new FileUtils();
        }
    }
    
    public static FileUtilsAdapter getBestFileUtils()
{
        final int v =
JavaEnvUtils.getJavaVersionNumber();
        if (v >= 16) {
            return getFileUtils("java6");
        } else if (v >=14) {
            return getFileUtils("nio");
        } else {
            return new FileUtils();
        }
    }
}

Since the other impls will be conditionally compiled,
we should use Class.forInstance()...

> 
> Similarly, users of FileUtils would call
> FileUtilsFactory.newFileUtils(Project p) instead of
> FileUtils.newFileUtils() where a project member
> variable is available,
> otherwise FileUtilsFactory.newFileUtils().

What would the Project reference be used for?

Kev: your mail showed:

public class NioFileUtils extends FileUtils implements
FileUtilsAdapter {...}

public class Java6FileUtils extends FileUtils
implements FileUtilsAdapter {...}


But shouldn't that actually be:

+public class FileUtils implements FileUtilsAdapter
{...}

public class NioFileUtils extends FileUtils {...}

public class Java6FileUtils extends NioFileUtils {...}

?

br,
Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message