im Verzeichnissbaum recursiv nur bestimmte Dateien finden

[xhi2018]

Hallo,

ich muß in meinem Programm unterhalb einem Verzeichnis nach bestimmten Dateien suchen. Die Dateinamen haben alle den selben Namen lediglich die Extension ist unterschiedlich. Kleines Beispiel - es müssen alle Dateien mit dem Namen

foo.properties, foo.txt, foo.xml, foo.ini, ...

gefunden werden die irgendwo unterhalb einem bestimmten Verzeichnis liegen. Das hier funktioniert soweit schon mal wie von mir gewünscht. Weil ich jetzt nicht gerade der Experte bin wollt ich hier mal fragen wie ihr diese Aufgabe lösen würdet und habe ich vielleicht noch irgendwo was vergessen bzw. könnte besser/effizienter/schneller gemacht werden ???:L

	public Collection<File> traverse( final File f, final FilenameFilter filter, final boolean recurse) {
		Collection<File> result = new ArrayList<File>();
		if (f.isDirectory()) {
			File[] entries = f.listFiles();
			for (File entry : entries) {
				if (filter == null || filter.accept(f, entry.getName())) {
					result.add(entry);
				}
				if (recurse && entry.isDirectory()) {
					result.addAll( traverse(entry, filter, recurse) );
				}
			}
		}
		return result;
	}

und der dazu passende FilenameFilter

public class PropertyFileNameFilter implements FilenameFilter {

	private final Collection<String> fileNamesToMatch;
	public PropertyFileNameFilter(String fileName) {
		fileNamesToMatch = new ArrayList<String>();
		fileNamesToMatch.add(fileName + ".properties");
		fileNamesToMatch.add(fileName + ".txt");
		fileNamesToMatch.add(fileName + ".xml");
                // usw. usw.
	}
	
	public boolean accept(File dir, String name) {
		return fileNamesToMatch.contains(name);
	}

Beim Erzeugen des Filters wird dann der zu suchende Dateiname angegeben

FilenameFilter propertyFileFilter = new PropertyFileNameFilter("foo");

Ich danke schon mal sehr für Eure Hilfe und Tipps!!

 

[nrg]

du kannst listFiles direkt deinen FileFilter übergeben. Diesen würde ich persönlich in einer nested class schreiben. Benutz @Override. listFiles kann auch null liefern, deshalb ist es imho zwingend erforderlich entries vor dem iterieren auf null zu überprüfen. ansonsten würde ich das so ähnlich machen

 

[xhi2018]

Hallo,

vielen Dank für Deine Antwort!

du kannst listFiles direkt deinen FileFilter übergeben.

Wenn ich das so mache, befinden sich in dem

File[] entires

nur die gefundenen Datei aber keine Unterverzeichnisse mehr. Die Verzeichnisse werden aber für den rekursiven Aufruf der Methode bei [JAVA=9]...
if (recurse && entry.isDirectory()) {
...[/code]benötigt oder verstehe ich Dich nicht ganz richtig ???:L

Benutz @Override.

Im

PropertyFileNameFilter

..?[JAVA=12]@Override
public boolean accept(File dir, String name) {
return fileNamesToMatch.contains(name);
}[/code] Ich muß noch mit Java5 arbeiten. Da kann ich die @Override annotation bei Interface nicht einsetzen, zumindest bekomme ich die Klasse dann nicht compiliert - stimmt das ???:L

listFiles kann auch null liefern, deshalb ist es imho zwingend erforderlich entries vor dem iterieren auf null zu überprüfen.

oha - das war mir nicht bewusst, ja logisch - vielen Dank für den Tipp!! [JAVA=3]if (f.isDirectory()) {
File[] entries = f.listFiles();
if (entries != null) {
for (File entry : entries) {
if (filter == null || filter.accept(f, entry.getName())) {
result.add(entry);
}
if (recurse && entry.isDirectory()) {
result.addAll( traverse(entry, filter, recurse) );
}
}
}
}[/code]

ansonsten würde ich das so ähnlich machen

nochmals Danke für Deine Antwort! :applaus:

 

[nrg]

Wenn ich das so mache, befinden sich in dem

File[] entires

nur die gefundenen Datei aber keine Unterverzeichnisse mehr. Die Verzeichnisse werden aber für den rekursiven Aufruf der Methode bei

Ich würde dafür einen normalen FileFilter nehmen (edit: aber wie gesagt, eher in einer inner class, ausser du brauchst den gleichen filter öfters):

public class PropertyFileNameFilter implements FileFilter {
// ....
    public boolean accept(File file) {
        return file.isDirectory() || fileNamesToMatch.contains(file.getName());
    }
}

Ich muß noch mit Java5 arbeiten. Da kann ich die @Override annotation bei Interface nicht einsetzen, zumindest bekomme ich die Klasse dann nicht compiliert

sollte imho seit 1.5 gehen. Welcher Fehler kommt denn?

 

[Niki]

du könntest dir auch das commons-io package von apache anschauen: Commons IO - Home
schau dir mal die Klasse FileUtils und die
Methode
public static Collection<File> listFiles(File directory, IOFileFilter fileFilter, IOFileFilter dirFilter)
an

 

[xhi2018]

Ich würde dafür einen normalen FileFilter nehmen (edit: aber wie gesagt, eher in einer inner class, ausser du brauchst den gleichen filter öfters):

public class PropertyFileNameFilter implements FileFilter {
// ....
    public boolean accept(File file) {
        return file.isDirectory() || fileNamesToMatch.contains(file.getName());
    }
}

ja klar - so geht's natürlich! Manchmal kommt man auf die einfachsten Ideen nicht...
Ich hab's jetzt so geändert, das mit der inner class schau ich mir nochmals an, so richtig verstehe ich den Vorteil nicht. Ich finde dadurch wird der Code schwerer lesbar, kann aber daran liegen, dass ich noch nicht sooo viel Erfahrung & Routine hab...

sollte imho seit 1.5 gehen. Welcher Fehler kommt denn?

In Eclipse bekomme ich dann diesen Fehler

- implements java.io.FilenameFilter.accept
- The method accept(File, String) of type PropertyFileNameFilter must override a superclass

Scheint wohl auf @Override specification changes in Java 6 raus zulaufen...

wie auch immer - danke nochmals für Deine Tipps (war sehr interessant & lehrreich)

 

[xhi2018]

Hallo,

du könntest dir auch das commons-io package von apache anschauen: Commons IO - Home schau dir mal die Klasse FileUtils und die Methode
public static Collection<File> listFiles(File directory, IOFileFilter fileFilter, IOFileFilter dirFilter)
an

danke für den Hinweis.
Aber wegen so ein "bisschen" Dateien aufsammeln würde ich nur sehr ungern eine neue Abhängigkeit in mein Programm aufnehmen. Zumal ich ja jetzt eine funktionierende Lösung für das Problem hab'.
Aber - who knows - vielleicht ist es in einem anderen Fall mal ganz nützlich. Ich werd's mir merken - dank' Dir!

 

[nrg]

Ich finde dadurch wird der Code schwerer lesbar,

das sehe ich genau anders rum. ein argument wäre noch eine bessere kapselung. aber vielleicht ist das auch etwas geschmackssache

Scheint wohl auf @Override specification changes in Java 6 raus zulaufen...

ja da hast du wohl recht. dann vergess das mit @Override, solange du noch mit java5 arbeitest