Projektvorstellung: CFileSystem

Guten Morgen,

Wie gestern schon angekündigt wollte ich jetzt mal mein aktuelles Nebenbeiprojekt vorstellen.

Das CFileSystem
Vorweg: Mit Filesystem ist nicht sowas wie NTFS, FAT32 usw. gemeint.

Zunächst mal etwas zur Idee dahinter. Im Prinzip haben mich 2 Gründe zu diesem Projekt getrieben. Einmal wollte ich für ein anderes Projekt bestimmten Teilen (PlugIns :D) eine Möglichkeit bieten Dateien zu speichern, ohne zu viele Fehlerquellen was Sicherheit angeht zuzulassen. Der andere Grund war, dass ich Häufig solche oder ähnliche Konstrukte hatte

File f=new File(SOME_PATH);
File parent=f.getParent();
if(!f.exists())
{
   if(!parent.exists())
   {
      parent.mkDirs();
   }
   f.createNewFile();
}

(und das ganze noch nichtmal ohne Fehlerbehandlung)
Natürlich könnte man das ganze in eine Methode auslagern, aber am Ende will man hier und da doch vllt was anderes haben.
Also habe ich mir überlegt ich erstelle eine Abstraktionsschicht zu basteln, die diese Aufgaben übernehmen kann und eine einfach zu benutzende Schnittstelle bietet.
Gesagt getan, so ist das CFileSystem entstanden (das C steht für Clayn ;)).

Aber worum geht es eigentlich? Im Prinzip gibt es 3 wichtige Komponenten: CFileSystem, Directory und SimpleFile.

Das CFileSystem ist die Grundlage um an Directories und Files zu kommen. Jedes Filesystem besitzt ein Root-Directory.
Ein Directory ist, wie der Name schon sagt, ein Ordner und beinhaltet entweder Dateien oder weiter Ordner.
Die SimpleFile stellt eine Datei dar. Der Name ist einerseits zur Abtrennung von java.io.File aber auch zum deutlich machen, dass es einfach sein soll.

Diese drei Komponenten sind alles Interfaces und dienen dazu beliebige Implementationen zuzulassen.
Für den Anfang habe ich schon 2 davon erstellt. Eine Implementation arbeitet auf dem lokalen Filesystem, die andere über SQL auf einer Datenbank.
Für den Benutzer ist es am Ende egal welche Implementation man nimmt.

Was kann man nun mit den Komponenten machen?
Sowohl Directory als auch SimpleFile bieten im Grunde die wichtigsten Funktionen an: Erstellen, Löschen, Lesen und Schreiben.
Mal ein kleines Beispiel

CFileSystem cfs=new FancyFileSystem(); 
Directory root=cfs.getRoot();
SimpleFile file=root.getFile("SomeFile.txt");

Jetzt hat man zunächst das Root Directory (welches immer erstellt sein sollte [wird durch Tests „verifiziert“]) und eine Datei. Die Datei existiert zunächst nicht „wirklich“
Man hat jetzt 2 Möglichkeiten die Datei zu erstellen. Entweder file.create(); oder file.createSafe();

Der Unterschied zwischen den beiden Methoden ist, dass createSafe keine Exception wirft, falls die Datei vorhanden ist und alle nötigen Verzeichnisse erstellt.
Jetzt existiert die Datei dauerhaft und kann gelesen und geschrieben werden.

Noch etwas Allgemeines zum Schluss:
Das gesamte Projekt besteht aus 5 Projekten.
API - Liefert die Schnittstellen und verschiedene Utility Sachen
Local - Eine Implementation die auf dem lokalen Filesystem arbeitet
SQL - Eine Implementation die auf einer SQL Datenbank arbeitet
Impl - Sammelt einfach alle von mir erstellten Implementationen
Test - Liefert allgemeine Tests die nur ein CFileSystem benötigen und es Implementationen ermöglichen einfach getestet zu werden

So und jetzt… reißt mir den Kopf ab :smiley:

P.S.
Was ich vergessen hatte zu erwähnen, es handelt sich um NetBeans bzw. Maven Projekte und benötigen Java 1.8.

Ich glaube, der Thread ist ein bißchen untergegangen. Zumindest sagt der Titel nichts aus. Ich dachte erst: Ah, irgendeine höchst unspezifische Frage nach irgendeinem Filesystem-Ding aus C# :rolleyes:

Ein „reißerischer“ Titel wie „CFileSystem - die bessere Alternative zu java.nio.FileSystem“ würde vielleicht schon helfen (Clickbait! Marketing! Self-Promotion!!! :smiley: )

Und… da würde ich auch einhaken: Beim bisherigen Überfliegen würde sich zuerst die Frage nach der Abgrenzung zu FileSystem (Java Platform SE 8 ) oder auch Apache Commons VFS – Commons Virtual File System aufdrängen, aber … den Code habe ich noch nicht gelesen.

Ja Titel ist sone Sache aber kann ich jetzt schlecht ändern (oder?^^).
Naja Unterschiede. Wie schon in dem Vorstellungsthread festgestellt, gibt es die meisten Sachen schon in irgendeiner Form da ist sowas schwer.

Was mir jetzt als ersten Unterschied aufgefallen ist das sowohl java.nio.Filesystem und common-vfs keinen direkten Unterschied zwischen File und Directory machen. Man also immer vorher prüfen muss was man jetzt eigentlich hat. Mir war diese Trennung sehr wichtig.
Auch wollte ich z.b. die Handhabung mit dem Watchservice vereinfachen/abstrahieren

“Edit Post” und dann “Go Advanced” sollte gehen, um den Titel zu ändern

Ansonsten … (da ich es immernoch nicht gelesen habe, und auch mit dem WatchService und vielem anderen aus dem NIO noch nicht wirklich was gemacht habe): Vielleicht in der “Readme.md” ein paar suggestive Beispiele

// So geht's mit den Bordmitteln

// 20 Zeilen kryptisch-Konfuster Code

// So geht's mit CFileSystem:

// 2 Zeilen klarer Code

(aber zu viel “impact” würde ich bei sowas nicht erwarten. Jemand, der ernsthaft eine FileSystem-Abstraktion braucht, wird dem Namen “Apache” eher vertrauen, als irgendeiner x-beliebigen GitHub-Lib - selbst für den Fall, dass letztere für irgendwas “besser” ist…)

Ist nur blöd dass man nach ner Zeit nicht mehr editieren kann^^

Ja das mit den Erklärungen. Ich bin da immer relativ unkreativ bzw. weiß nie genau was eigentlich wirklich interessant ist und was nicht.
Aber ja Beispiele können definitiv rein. Auch wenn mir ja im Laufe der Zeit aufgefallen ist, dass ich z.T. viel zu viel Aufwand in bestimmte Bereiche gesteckt habe bzw. man sich entscheiden müsste wie man es genau haben will.

Das mit dem impact ist mir bewusst und ich hab mir da auch keine Illusionen gemacht. Aber ich mach ja persönlich Dinge lieber selbst als für alles -meistens dann- was von Apache zu nehmen. Wenn es denn im vertretbaren Umfang selber machbar ist.

Dann sag’ ggf. bescheid, wie der Titel sein soll.

Das „selbst machen“ kenne ich, und ich muss mich auch den Vorwurf des Not-invented-here-Syndrom – Wikipedia gefallen lassen. Aber … irgendwann ist mal jemand auf die Idee gekommen, um das althergebrachte „Rad“ einen luftgefüllten Gummi-Mantel zu ziehen, und das ist ja schon weniger holprig als die Steinscheibe mit dem Loch in der Mitte :smiley: Man kann das rechtfertigen, auch (oder gerade) wenn man nicht vorhat, das in irgendeinem „großen“ („Unternehmens-“) Kontext einzusetzen.

Am ehesten käme mir da nur “Projektvorstellung: CFileSystem” in den Sinn^^

Das mit dem selber machen bzw keine Abhänigkeiten haben, geht bei mir sogar soweit das ich oft Sachen mehrfach mache, weil ich (auch wenn das nie der Fall sein wird) anderen nicht zumuten möchte, Sachen zu benötigen die sie vllt eig nicht wollen^^

Ja, darüber hatte ich in https://forum.byte-welt.net/java-forum/allgemeine-themen/15670-abhaengigkeiten-und-der-umgang-damit.html oder auch https://forum.byte-welt.net/java-forum/allgemeine-themen/17880-trade-zwischen-abhaengigkeiten-und-kompaktheit-lesbarkeit.html schon philosophiert. Ich finde, selbst im extremsten Fall, d.h. WENN etwas nur „geekiger Selbstzweck“ ist, („mal schauen, ob ich das hinkriege“ / „wie man das (freigesitig-kreativ auf der grünen Wiese) machen könnte“), hat es immernoch einen Nutzen. Und wenn sich rausstellt, dass es für andere auch nützlich ist, ist das ggf. ja nur ein positiver Kollateraleffekt :smiley:

Es hätte mich auch ehrlich gesagt gewundert, wenn gerade du auf dem Fakt rumreitest, dass es da ja schon was gibt, was mehr bietet etc. Du der des öfteren hier mal Sachen bereitstellt die z.T. einem speziellerem Zweck dienen (t.Z. mit Anmerkung was man denn für mehr Funktionalität eher nehmen sollte :D).

Und letztendlich ist es auch eher ein “Ich hab da für mich was gebastelt, aber es versucht so zu gestalten, dass auch andere was damit anfangen könnten. Hier!”. Wird bei einem anderem Ziel von mir zwar mit Sicherheit zum Einsatz kommen… wenn ich das mal im 3. oder 4. Anlauf auch mal durchziehe

Wenigstens mal ein Projekt das ein bisschen dokumentiert ist. :daumen: Und die Aufteilung in die Unterprojekte finde ich ziemlich gut gelungen. Aber als Ersatz für nio2 würd ichs jetzt glaub doch nicht nutzen, da sehe ich die Vorteile noch nicht (Da fehlt das Marketing :wink: )

Danke erstmal fürs angucken^^ Ja das Marketing ist sone Sache. Kannst mir da ja ein paar Tipps geben :wink:
Wobei ich einen „Vorteil“ sehe, ist die explizite Unterscheidung in Datei und Ordner. Sowohl bei nio als auch common-vfs werden (soweit ich das gesehen habe) Dateien und Ordner durch die selbe Klasse representiert was dazu führt, dass man immer wieder prüfen muss was man nun vor sich hat. Das macht es finde ich bei mir leichter, da man, wenn man eine Datei erwartet, das auch so angeben kann.

Naja vielleicht erzähle ich ja dem grössten Müll - aber der einzige genannte Vorteil war ja unterscheidung ordner und datei - und so eine “abstraktionsschicht” bekommt man doch mal eben mit 2 wrapperklassen über file hin…

Ja und nein. Klar könnte man relativ einfach die Unterscheidung über Klassen umsetzen. Aber mir geht es ja gerade darum nicht zwingend auf File bzw das lokale Dateisystem angewiesen zu sein, sondern auch andere Implementierungen wie z.b. einer Datenbank zuzulassen. Je nach Anwendungszweck eben, was man haben möchte aber mit einer einheitlichen API.