Den Dateipfad einer Java Datei durch Code in Selbiger finden?

[berndoa]

Hallo,
ich habe in meinen Programmen öfters mal eine Zeile wie

File datei=new File("C//blabliblu//sido.ods");

Wo also anhand des Pfades einer Dates, naja, ein File Object erzeugt wird.

Sagen wir, ich hätte eine java Datei (sowie ihre kompilierte .class Datei)
sowie die oben erwähnte sido.ods Datei Alles in einem Ordner.

Da es bei mir vorkommt, dass ich öfter mal Ordner anderswohin verschiebe, müsste ich jedes Mal in der Datei den absoluten Dateipfad oben ändern;
was auf Dauer ärgerlich ist.

Daher würde ich in der Java Datei selbst gerne sowas umsetzen wie "Guck in welchem Ordner(pfad) diese java Datei ist, knall an diesen Ordnerpfad ein "//sido.ods" ran (im Sinne von Stringkonkatenation) und übergib diesen Gesamtstring einem new File(...) Aufruf, um eben ein entsprechendes File zu erzeugen".

Lässt sich das umsetzen?
Dass ich mir von einer .java bzw. deren .class Datei letztlich im programmcoe sebst zurückgeben lasse wo die Datei leigt und damit dann halt arbeit mit diesem Pfad?

Geht das?


Ich bin schon über die Path Bibliothek gestoßen, aber dort geht es augenscheinlich ja immer darum, aus einem gegebenen Pfad den Elternordner zu extrahieren und Ähnliches, zumindest wirkt es nach erstem lesen mal so.

Gibts da eine Möglichkeit, dass eine java Datei ihren eigenen Dateipfad ermittelt?

 

[mihe7]

Nachdem der Quelltext bei der Ausführung nicht mehr relevant ist, kann das nicht funktionieren.

Was Du machen kannst, ist den Pfad relativ zum aktuellen Arbeitsverzeichnis anzugeben (new File("sido.ods") bzw new File("./sido.ods")) oder aber die Datei als Ressource aus dem Classpath zu öffnen (dazu hatte ich einmal einen Artikel verfasst, https://www.java-forum.org/thema/classpath-ressourcen-ides-und-build-systeme.194131/ - der ist sogar @berndoa-freundlich, also mit Beschreibung auf der Befehlszeile)

 

[Neumi5694]

Vor allem ist der Ansatz Ansatz der falsche. Über einen Umweg lässt sich der absolute Pfad der Java-Datei schon ermitteln, nur ist das sinnlos. Die Java Datei "kennt" ihren relativen Dateipfad, der beim Standard-Klassloader dem Packagenamen entspricht. Wenn man also das root-Verzeichnis des Sources beim Kompilieren mit übergeben würde, würde man so beim Kompilieren den absoluten Pfad der Java-Datei in die Class-Datei übertragen können können, nur ... wozu? Das kompilierte Programm befindet sich zum Ausführungszeitpunkte ja nicht mehr dort, wo die Java-Datei liegt. Ob nun die class-Dateien irgendwo auf der Festplatte rumschwirren oder in einer jar ist egal, in keinem Fall hat der Pfad der Java-Datei irgend eine Bedeutung.

@berndoa
Es wäre vielleicht hilfreich, wenn du mal genau sagen könntest, was du da eigentlich versuchst, also Code posten und Verzeichnisstruktur.
Du machst dir da Probleme, wo keine sind. Im Normalfall reicht ein relativer Dateiname vollkommen aus, den absoluten kannst du - falls gewünscht - ja ermitteln lassen. new File(relativePath).getAbsolutePath()
Als Referenz für den relativen Pfad dient das Ausführungsverzeichnis deines Programms.

 

[berndoa]

Vor allem ist der Ansatz Ansatz der falsche. Über einen Umweg lässt sich der absolute Pfad der Java-Datei schon ermitteln, nur ist das sinnlos. Die Java Datei "kennt" ihren relativen Dateipfad, der beim Standard-Klassloader dem Packagenamen entspricht. Wenn man also das root-Verzeichnis des Sources beim Kompilieren mit übergeben würde, würde man so beim Kompilieren den absoluten Pfad der Java-Datei in die Class-Datei übertragen können können, nur ... wozu? Das kompilierte Programm befindet sich zum Ausführungszeitpunkte ja nicht mehr dort, wo die Java-Datei liegt. Ob nun die class-Dateien irgendwo auf der Festplatte rumschwirren oder in einer jar ist egal, in keinem Fall hat der Pfad der Java-Datei irgend eine Bedeutung.

@berndoa
Es wäre vielleicht hilfreich, wenn du mal genau sagen könntest, was du da eigentlich versuchst, also Code posten und Verzeichnisstruktur.
Du machst dir da Probleme, wo keine sind. Im Normalfall reicht ein relativer Dateiname vollkommen aus, den absoluten kannst du - falls gewünscht - ja ermitteln lassen. new File(relativePath).getAbsolutePath()
Als Referenz für den relativen Pfad dient das Ausführungsverzeichnis deines Programms.

Naja, ich führ den Kram in einem ordner auf meinem Desktop aus.
Da ist auch die konsolendatei drin, die an dem Ort "ausgeführt" wird.


Also bspw. gibts einen Ordner C:/.../Desktop/LeOrdner
und in dem die "Command Prompt" drin ist(bei der in den Eigenschaften bei "Ausführen in" eben C:/.../Desktop/LeOrdner hinterlegt ist, muss also in der Konsole keine Ordner wechseln),
die A.java Datei, später auch die A.class Datei, ggbfls. excel dateien, benutzte jars, etc.
Alles halt.

und IN der A.java Datei kommt eben bspw. eine zeile vor wie

File testfile=new File(" C:/.../Desktop/LeOrdner/DeineMudda.ods");

Mit der ich eben eine Datei, die sich im selben ordner wie die A.java Datei ist, als File Objekt aufnehme und Alles Mögliche damit mache.

Gehe ich nun hin und verschiebe den kompletten Ordner irgendwo anders hin, dann ändert sich natürlich auch der Absolute Pfad der Ods Datei sowie vieler Anderer.
Und ich muss in den Dateien überall, wo ich einen hardgecodeten Absolutpfad (wie im Code oben) benutze, den händisch ändern.

Das will ich mir halt ersparen indem die .java Datei selbst guckt "Yo, in welchem Ordner liege ich (Absolutpfad)" und nimmt diesen Dateipfad als String und werkelt damit.

Als Beispiel soll also die .java Datei rausfinden dass ihr Pfad "C:/.../Desktop/LeOrdner/A.java" ist, eben das A.java abschneiden und DeineMudda.ods hinten anfügen im Sinne von Stringmanipulationen.

Frage ist halt nur, wie findet die java Datei am Einfachsten ihren Dateipfad heraus?

Habe manches gelesen aber da sind die Befehle meist dazu da, den Standort des JDK zu finden, den root Ordern "C:/" zu finden oder Ähnliches.
Nichts um simpel den Standort der Datei selbst zu finden.

Wenns mit relativen pfaden geht, soll es mir auch recht sein.

"Als Referenz für den relativen Pfad dient das Ausführungsverzeichnis deines Programms."
wie lasse ich selbiges Ausführungsverzeichnis wiederum finden?

 

[Neumi5694]

Wie gesagt, falscher Ansatz. Der absolute Pfad bringt dir nichts, wenn du doch den relativen brauchst (passend zum Verschieben des Verzeichnisses).
Falls Dateien in deinem Programmverzeichnis liegen, brauchst du nie absolute Pfade zu verwenden - in keiner Sprache.

Wenn alle deine Datein im selben Ordner liegen, dann reicht es doch, wenn du "./DeineMudda.ods" angibst.
Das ist dann nämlich auch der Ordner, in dem das Programm ausgeführt wird, wenn du die Jar-Datei doppelt anklickst.
Wenn du per Verknüpfung einer Batch-Datei startest, solltest du vorsichtshalber erst mal in das entsprechende Verzeichnis wechseln wechseln (https://stackoverflow.com/questions/5034076/what-does-dp0-mean-and-how-does-it-work) und danach Java starten.

Java-Quellcode-Dateien sollten übrigens NICHT im Runtime-Verzeichnis liegen, dort gehören nur die Jars hin. Sourcecode hat in einer ausführbaren Anwendung nichts verloren.
Beim Kompilieren gibt man den Dist-Ordner an, in welchem die class-Dateien landen sollen, dann wird daraus noch eine Jar erstellt.

Falls du aber aus irgendeinem Grund doch den aktuellen Pfad wissen willst:

System.out.println(new File("./DeineMudda.ods").getAbsolutePath());

File getAbsolutePath() method in Java with Examples - GeeksforGeeks

A Computer Science portal for geeks. It contains well written, well thought and well explained computer science and programming articles, quizzes and practice/competitive programming/company interview Questions.

www.geeksforgeeks.org

 

[Neumi5694]

Die meisten deiner Probleme machst du dir selbst.

Du solltest wirklich mal anfangen, eine IDE zu verwenden. Wenn du dort z.B. ein File-Objekt hast, kannst du dir per Tastendruck (üblicherweise) Ctrl+Space die verfügbaren Methoden samt Dokumentation anzeigen lassen. Dann hättest du die Methode zum Anzeigen des absoluten Pfads einer Datei auch selbst gesehen.

Vor allem würdest nicht in Versuchung geraten, anhand des Speicherorts einer Quelltextdatei irgendwas zur Laufzeit bestimmen zu wollen, deine Ordner wären von Haus aus besser aufgeräumt und voneinander getrennt. Die IDE trennt für dich nach Source-Verzeichnissen, build, dist und Runtime. in src liegen dir Quelltexte, nach dist kommen die Class-Dateien, die gepackte Jar landet im dist (samt libraries). Zum Testen kannst du dann ein Runtime-Verzeichnis festlegen, keine der oben genannten Dateien muss sich darin befinden.
Falls du dich damit nicht beschäftigen willst, kannst du den Deploy im ersten Moment ja auch manuell machen, indem du den Inhalt deines Dist-Verzeichnisses in das endgültige Programm-Verzeichnis kopierst.

Probier mal Netbeans aus. Ignorier die xml-Dateien, die dich so sehr verwirren und erstell einfach mal ein Projekt names FirstSteps, im folgenden Dialog wählst du als Hauptklasse "org.berndoa.firststeps.FirstStepsMain" (org, da nicht kommerziell, danach der Vendor, also du, dann der Projektname. Das ist ein üblicher Standard - gibt natürlich noch andere).
Lass in der erstellten main Methode mal den oben genannten absoluten Pfad ausgeben und lass das Ganze dann mal builden. Tadaa: Im dist-Verzeichnis liegt eine fertige Jar, darin enthalten sind deine Class-Datei(en) in den korrekten Unterverzeichnissen und ein Manifest, in dem die Informationen stehen, die Java zum Starten des Programms benötigt. Die kannst du nun egal wo ausführen mit "java -jar FirstSteps.jar" (natürlich musst du den Pfad zu java.exe kennen oder er muss im PATH drin stehen)

 

[Neumi5694]

Mir ist ein Gedanke gekommen: Kann es sein, dass du bisher (vor Java) nur mit Scriptsprachen wie Python gearbeitet hast? Dann könnte ich deine Denkweise verstehen, das würde die Motivation hinter einiger deiner Fragen erklären.
Da würde der Ort der Script-Datei tatsächlich als Referenz dienen und man würde auf Händen und Knien mit Texteditoren arbeiten.
In höheren Sprachen (auch C# usw.) geht man halt eben einen ganz anderen Weg.

 

[berndoa]

Mir ist ein Gedanke gekommen: Kann es sein, dass du bisher (vor Java) nur mit Scriptsprachen wie Python gearbeitet hast? Dann könnte ich deine Denkweise verstehen, das würde die Motivation hinter einiger deiner Fragen erklären.
Da würde der Ort der Script-Datei tatsächlich als Referenz dienen und man würde auf Händen und Knien mit Texteditoren arbeiten.
In höheren Sprachen (auch C# usw.) geht man halt eben einen ganz anderen Weg.

Hm, gute Frage.
In der Schule gabs nur Python.
Html, php, Mysql und so qurden kruz angerissen, sind ja in dem Sinne aber keine Programmiersprachen.

Und an der Uni nahezu nur Java (wo man die IDEs, den Konsolenquark Linux und viel mehr Script Kiddie Kram für Leute, die Mäuse hassen, aufgedrückt kriegen sollte),
sowie auch mal ein Kurs war mit C (oder C++ oder so; irgendsoeine Sprache wo man zwischen Pointer auf Variable und dem Variablenwert händisch unterscheiden musste, war sehr nervig und Gott sei Dank wird sonst immer Java benutzt)

Ansosnten kenne ich nicht allzu viele Programmiersprachen, wobei die grundlegenden Sachen ja vermutlich überall halbwegs gleich sind.

 

[Neumi5694]

Ich hab damals auf dem Frael Bruch 100 meine ersten Gehversuche mit Basic gemacht, nach etwas Amiga Basic wurde es in der 11. und 12. Klasse dann Turbo-Pascal und Turbo-C (Chat-Programm über serielle Schnittstelle, Statistik-Simulationen, Laut-Erkennung, Aufzugsteuerung), gepaart mit Datenbankdesign, Access und Excel Basic außerhalb der Schule während Sommerjobs. VC hab ich nach der Schule während eines Praktikums in UK programmiert, danach nie wieder. In der Uni wurd's dann Java, dabei bin ich dann geblieben. C++ und C# hab ich mal einen Besuch abgestattet, konnte mich aber nie recht damit anfreunden.

Was Algorithmen angeht, hast du recht, da sind sich die Sprachen tatsächlich ähnlich. Java (und auch C#) hat die Unterscheidung Pointer vs Inhalt genauso wie C++, es ist nur syntaktisch schöner gelöst (du willst nicht wissen, wie's vor Generics und Autoboxing war) und wir sagen halt "Referenz" anstatt "Pointer". Das Handling der "Pointer" ist im Code kaum sichtbar, aber intern funktioniert der Schmuh im Grunde genau gleich.

Der Unterschied in der Denkweise fängt dann an, wenn du eine Anwendung entwickeln willst, die über eine reine Konsoleneingabe hinaus geht. Dann musst du dich mit Resourcen-Dateien (womit du anscheinend gerade anfängst), Builds und Deploy beschäftigen. Hier hat der Quelltext keine Bedeutung mehr und auch nicht, wo er gespeichert ist. Class-Dateien in Unterverzeichnissen? Geschichte, die sind in der Jar-Datei, meistens auch die Resourcen. Zu letzteren gibt's dann auch keinen absoluten Pfad mehr. Man gibt den relativen Resourcen-Pfad an, Java sucht dann in der Jar-Datei danach.

Es ist gut, wenn du das mal gemacht hast, damit du verstehst, wie's funktioniert, aber dieses ganze Micromanagement kannst du dir sparen, wenn du anfängst, mit IDEs zu arbeiten. Diese haben meistens ein recht komplexes Build-Script mit vielen Optionen (normalerweise über Projekteigenschaften einstellbar), das dich erst mal nicht weiter zu interessieren braucht. Du entwickelst einfach nur noch. Wenn du dann irgendwann mal einen Build- und einen oder mehrere Testserver hast, dann wirst du dir die Scripts anschauen müssen, aber rein zum Entwickeln können sie dir egal sein. Du musst aber Willens sein, dich auf ein neues System einzulassen. Wenn du alles auf Druck so machen willst, wie du's gewohnt bist, dann kriegst du genau die Probleme, die man in deinen Posts immer wieder sieht.
Wichtig: Fang früh genug an, mit Packages zu arbeiten, bei Projekten mit mehreren hundert Klassen sind die unerlässlich. Irgendwann wirst du keine Packages mit mehr als 10 Klassen mehr sehen wollen.


Ich für meinen Teil mach den Fehler, mich von Script-Sprachen fernzuhalten. Gerade, wenn man einen Linux-Server per Terminal bedient, ist es durchaus sinnvoll, sich damit zu beschäftigen, aber ich schreib die Sachen immer noch in Java. Python und TypeScript sind für mich noch ein rotes Tuch, aber auf lange Sicht werd ich nicht drum rumkommen, wenn immer mehr als Webservice und ähnliches laufen soll.

 

[berndoa]

Der Unterschied in der Denkweise fängt dann an, wenn du eine Anwendung entwickeln willst, die über eine reine Konsoleneingabe hinaus geht. Dann musst du dich mit Resourcen-Dateien (womit du anscheinend gerade anfängst), Builds und Deploy beschäftigen. Hier hat der Quelltext keine Bedeutung mehr und auch nicht, wo er gespeichert ist.

Öh, keine Ahnung. An Uni und Co. kriegt man seinen Standardkram zu Schleifen, vererbung,. etc. mit.

Und Ich hab e halt manchmal random Ideen (wie das Lotto 3 gewinnt, Baccarat, Blackjack und Co.), die ich mir dann heimisch umsetzen will.
Und zu 90% von vielen Sachen (wie lese ich excel dateien mit java ein, etc.) Null Ahnung habe, kopiere ich mir den Code von irgendwoher zusammen.
Gut, und wenn der Mister von internet mir nur eine blöde .ja Datei statt .java Dateien gibt, muss ich mir eben noch anlesen wie ich dem COmpiler beibringe dass er einfach in dem selben Verzeichnis nach Allem sucht, wo Alles (er selbst inklusive) liegt. Da tuts ja leider im java Code import nicht, mit dem man 99% der Sachen einbinden kann....

Und so weiter.
Ergibt sich dann meist von selber wie ich bei der ergoogelten Lösung für 1 Problem auf 20 Andere stoße

 

[Neumi5694]

Mit Schleifen und so haben sie sich damals an der Uni nicht lange aufgehalten, nur ein paar Primitivbeisipiele am Anfang, dann ging's gleich in die Objektorientierung, erweiterte Klassen mit variablen Typen usw, Stationen und Module z.B. zum Auswerten von Texten (Java war damals noch recht neu, DER große Wurf). Coden gelernt hat man nebenbei.
Such dir mal was einfaches, schreib eine kleine Verwaltung für deine CDs oder mp3s oder sonst irgendwas, das nicht nur aus einem Algorithmus besteht. Ich hab mir z.B. mal eine kleine Drag&Drop-UI geschrieben, in die ich flac-Dateien ziehen kann, die dann per fre;ac nach aac komprimiert werden zur Verwendung auf dem mp3 Player. Was ganz Simples, aber da hast du schon mal ein paar Komponenten drin. UI, Konfiguration (laden/speichern der Einstellungen), Logik (Ausführen des Konverters mit Parametern).

"anlesen wie ich dem OOmpiler beibringe dass er einfach in dem selben Verzeichnis nach Allem sucht, wo Alles". Das ist komplett und vollkommen der falsche Ansatz. Kompilieren ist einfach "javac -cp [classpath] -sourcepath [sourcedir] -d [targetdir]". Mehr ist da eigentlich nciht dran. Im zweiten Moment geht's noch um's Packen der Jar und dem Hinzufügen der Resourcen. Zur Ausführungszeit muss das aber passen, nicht zum Kompilierzeitpunkt. Deshalb: Greif endlich mal zur IDE, damit kannst du alles ordentlich machen, ohne dir irgendwas zusammen suchen zu müssen. Mit dem Kompilieren solltest du dich gar nicht erst aufhalte müssen, das geht per Tastendruck.