[Java] komisches Verhalten bei Collections.sort und Listen

[Milbret]

Hallo,
ich habe ein komisches Verhalten meines Java Programms bemerkt.

Das Programm synchronisiert Dateien zwischen Verzeichnissen.
Aktuell habe ich eine Methode die aus einem Verzeichnis den relativen Pfad zu allen enthaltenen Dateien auflistet.
Dies klappt an sich gut.

Hier die Methode:
http://nopaste.debianforum.de/35352

Die Synchronisierung durchläuft dabei alle Dateien und fügt der Liste für relative Pfade neue Einträge hinzu wenn der aktuelle Pfad ein Verzeichnis ist
Wenn ich Collections.sort um unteren Teil aufrufe enthält die Liste maximal 100 Einträge wie ich erwarten würde.
Wird diese Methode aber nicht aufgerufen, dann enthält die Liste bis zu 1000 Einträge.

Ich habe dies bei einer Testsynchronisation geprüft mit meinem Home Verzeichnis.
Dort sind rund 1.600 Dateien vorhanden.

Kann dies ein Fehler sein oder ist dies im Normalfall sogar in Ordnung?

Nachtrag:
Hier ein einfacheres Java Programm was den selben Effekt hat wenn ich alle Dateien in meinem Home Verzeichnis durchlaufe.
http://nopaste.debianforum.de/35353

Ich habe dieses Problem sowohl mit dem OpenJDK sowie dem SUN(Oracle) JDK.
Wie kann es sein, dass die Menge der Einträge mit und ohne Sort variiert?
Dies dürfte doch nicht sein.

Martin

[Milbret]

Hallo,
kennt keiner eine Antwort?

Konnte den Effekt auch unter Windows nachstellen...
Scheinbar wieder ein unerklärliches Java Phänomen :/

Martin

[Bert]

Debianforum war nie der beste Platz für Java Fragen. Ich würde Dir da stackoverflow.com vorschlagen..

Zu Deinem Problem: was willst Du denn eigentlich erreichen? Aus Deinem main() werd ich nicht ganz so schlau. Wenn Du recursiv durch das FS willst, dann würde ich auch Recursion verwenden

Ansosnten: Ohne mir das jetzt supergenau anzugucken: Was gibt das Programm denn aus?

[Bert]

Habe jetzt nicht wiederstehen können und Dein Programm (mit einigen zusätzlichen System.out erweitert) mal bei mir getestet.
Verstehe aber immer noch nicht was Du erreichen willst. Die Anzahl der Einträge sind vor und nach dem sort() korrekterweise gleich.

In der äußeren Schleife greifst Du immer auf Index 0 zu. Je nachdem ob Du sortierst oder nicht hast Du dort immer das gleiche drin. Am Ende ist Deine Liste aber immer leer.., korrekt.

Willst Du eine Liste aller Files recusiv unter einem Verzeichniss?

Edit: hab das mal eben zusammengehackt:

http://nopaste.debianforum.de/35356

[Milbret]

Okay nochmal eine genauere Erklärung des Problems.

Wenn ich Collections.sort nicht aufrufe ist die Anzahl der Strings und somit auch der Speicherverbrauch höher.
Wenn ich aber sort verwende, sinkt die Anzahl der Elemente und somit auch der Speicherverbraucht enorm.
Es geht hier aber um die Menge der Elemente zur Laufzeit nicht am Anfang oder Ende.

Dies macht für mich aber keinen Sinn, da ich eher erwarten würde, dass die Menge der Elemente in der Liste konstant aber der Speicherverbrauch durch sort höher sein sollte.

@Bert
Aktuell soll es die Anzahl der noch vorhanden Einträge in der Liste anzeigen bevor und nachdem neue Elemente hinzu gefügt wurden.

Martin

[Bert]

Ich frag nochmal was Du eigentlich erreichen willst?

Gib mal vor und nach dem sort() die Größe der Collection aus. Du wirst sehen das Sie sich nicht ändert. Die Änderung im verhalten liegt außerhalb der listRelativeFilePaths(). Zumindest in Deinem main() Beispiel verhält es sich anders, je nachdem ob sort() aufgerufen wird oder nicht. Dies liegt aber nicht am sort(), sondern daran wie Du das verwendest.

Wenn Du wirklich nur eine rekursive Liste aller Dateien erstellen willst würde ich mir keinen Kopf über den Speicherbedarf machen..

Du schriebst am Anfang was von Syncronisation? Wenn es Dir darum geht brauchst Du doch keine Vorabliste aller Dateien, sondern Vergleichst nur auf der jeweiliegen Ebene? Sag uns doch bitte einfach was Du erreichen willst. Aus Deinem Beispiel werd ich da nicht schlau.

Gruß

[Milbret]

@Bert
Es geht nicht um die Anzahl vor und nach dem Sort Aufruf.
Diese Menge bleibt imemr gleich, was ja klar ist.

Es geht hier um die Anzahl der Elemente in der Liste währen der Laufzeit des Programms.
Ich werde heuteabend mal eine Ausgabe erzeugen und dir zeigen was genau ich meine!

Martin

[Bert]

Das liegt daran das Du ja immer auf das 0te Element zugreifst. Was dort liegt ist abhängig von der Sortierung.

Geht um das jsynctool? Ich hab da mal kurz reingeschaut. Ein paar Bemerkungen: Du erfindest das Rad mehrfach neu. Z.B. gibts es schon 1000 und eine logging Lib für java (ich empfehle hier sl4j), generell ist es nicht immer gut alles selber neu zu schreiben.

Les Dich mal in Patterns ein. Anstelle von if(ConfigHelper.useHashing()) im Code zu versteuen lagere das in eine Strategie aus und setzte diese zu beginn. Ähnlich für andere Aspekte. Eclipse ist KEIN build tool. Ich würde z.b. heutezutage nicht mehr die Mühe machen fremde Quellen zu ziehen wenn diese nicht maven (zur Not auch ant) verwenden.

Verwende final wenn möglich [1]. Werfe Exception wenn angebracht. Bestimmt Ereignisse (kein Speicherplatz) sollten schon bis ganz nach oben durchschlagen.

[1] Effektive Java ist ein sehr sehr nützlichen Buch wenn man sich im Javaumfeld weiterbilden will. (http://www.amazon.de/Effective-Java-Pro ... 768&sr=8-1)

Verwende die Tools die Java mitbringt. Zum beispiel hat das java File bereits Funktionen zum Filtern. Kein Grund das nachzubauen, der Code wird dabei schwerer zu lesen und zu warten. Apropo lesen: Ein bisserl JavaDoc ist sehr hilfreich. Sonst wird nur schwer ersichtlich wieso es eine eigne File Klasse gibt. (wird mir leider auch aus dem code nicht klar..)

Ich hoffe ich hab jetzt nicht zu viel gemeckert..

[Milbret]

@Bert
Dank für das Feedback.
Ich werde mal schauen was ich davon umsetzen kann.

Der aktuelle Ablauf funktioniert zwar an sich schon gut aber trotzdem bin ich nicht ganz zu frieden.
Ich selbe komme auch dem C# und .NET Bereich was ich auch beruflich mache und dort bin ich nun eine, ganz böse gesagt, schönere API gewohnt.
Java hat hier und da noch viele Altlasten und Depreched Methoden/Kassen die manchmal für Kopfschmerzen bei mir sorgen.

Da ich die aktuelle Logging Funktionalität ersetzen möchte, wird diese auch erst einmal drin bleiben.
Ich werde mir aber die Lib mal anschauen.

Eclipse ist zwar kein Build Tool trotzdem ist es komfortabel damit Java Programme zu entwickeln.
Daran möchte ich auch erst einmal nichts ändern.

Trotzdem danke für die Hinweise.
Ich habe bisher schon ein paar gute Bücher zum Thema Java, auch die Insel .
Trotzdem habe ich das Gefühl noch nicht alles zu kennen.

Martin