Programm stürzt beim Aufruf der Funktion ab? Text ausgeben

[Alex_99]

Hallo,
Ziel ist es den Changelog des Programms, welcher in einer Textdatei steht auf dem Bildschirm (der Konsole) ausgeben zu lassen.
Der Changelog liegt im gleichen Ordner wie das Programm selbst.
Beim Aufruf der Funktion stürzt das Programm ab.
Folgendes ist mein Code:

import java.io.*;

public class Changelog {
        public static void changelog(){
            FileReader fr = null;
            try {
                fr = new FileReader("./Changelog.txt");
            } catch (FileNotFoundException e) {
                System.out.println("File not found!");
                Main.main(null);
            }
            BufferedReader br = new BufferedReader(fr);

            String ausgabe = null;
            try {
                ausgabe = br.readLine();
            } catch (IOException e) {
                System.out.println("Fehler!");
                Main.main(null);
            }
            System.out.println(ausgabe);
    }}

Bin noch absoluter Anfänger in der Java Programmierung.

 

[Alex_99]

Nächste Frage wäre wie ich das bei Windows, Linux und Macos einheitlich hinbekomme, dass er im gleichen Ordner wie das Programm die Textdatei sucht.. Der ./ Befehl ist ja eher Windows spezifisch. In Macos bedeutet er ja "suche im Root Verzeichnis".

 

[Robert Zenz]

Der Changelog liegt im gleichen Ordner wie das Programm selbst.
Beim Aufruf der Funktion stürzt das Programm ab.

Naja, was ist denn die Idee dahinter bei einem Fehler rekursiv das gleiche Programm nochmal aufzurufen?

Der ./ Befehl ist ja eher Windows spezifisch. In Macos bedeutet er ja "suche im Root Verzeichnis".

Was? Nein. Wie kommst du da d'rauf?

 

[KonradN]

./ ist Unix (und damit auch Mac OS) typisch. Windows kann das eigentlich gar nicht. Aber damit Entwickler in Java einheitliche Pfade angeben können, können Entwickler generell den / statt dem \ verwenden.

Das Changelog.txt kann man als Ressource mitgeben und dann über den Classloader laden. Denn mit dem Zugriff als ./xxxx greifst Du auf die Datei im aktuellen Arbeitsverzeichnis zu und das muss nicht das Verzeichnis sein, in dem Dein Programm liegt.

Es gibt auch noch Alternativen wie den Speicherort abzufragen. Das muss aber nicht gesetzt sein.

Was den Absturz angeht: Starte das Programm mit Konsole so dass Du Fehlermeldungen zu sehen bekommst. Und gib mehr Informationen aus als einfach nur "Fehler!" auszugeben. Du solltest die Exception mit dem Stacktrace ausgeben, damit man dann auch gezielter nach dem Problem schauen kann.

 

[Robert Zenz]

Windows kann das eigentlich gar nicht.

Doch, zumindest an einigen Stellen, daran kann ich mich erinnern. Ob es sich ueber die gesamte API erstreckt, oder nur ein Windows Explorer/CMD Ding ist, weisz ich aber nicht mehr. Ich meinte als Pfadtrenner, oder meintest du root? Dann habe ich nichts gesagt...

 

[Alex_99]

Habe es hin bekommen.
Er ist sofort aus dem Programm rausgegangen weshalb es natürlich geschlossen wurde..

Hier der korrigierte Code:

import java.io.*;
import java.util.Scanner;

public class Changelog {
        public static void changelog(){
            FileReader fr = null;
            try {
                fr = new FileReader("./Changelog.txt");
            } catch (FileNotFoundException e) {
                System.out.println("File not found!");
                Main.main(null);
            }
            BufferedReader br = new BufferedReader(fr);

            String ausgabe = null;
            try {
                ausgabe = br.readLine();
            } catch (IOException e) {
                e.printStackTrace();
                System.out.println("Fehler!");
                Main.main(null);
            }
            System.out.println(ausgabe);
            change();
    }
public static void change(){
    Scanner sc = new Scanner(System.in);
    String wahl;
    System.out.println("1 - Menue");
    System.out.println("2 - Beenden");
    wahl = sc.next();
    switch (wahl){
        case "1":
            Main.main(null);
        case "2":
            System.exit(1);
        default:
            System.out.println("Nochmal versuchen!");
            change();
    }
}
}

Problem ist jetzt nur das er nur die erste Zeile des Textdokuments anzeigt.
Könnte man das mit einer while Schleife hinbekommen?

 

[KonradN]

Doch, zumindest an einigen Stellen, daran kann ich mich erinnern. Ob es sich ueber die gesamte API erstreckt, oder nur ein Windows Explorer/CMD Ding ist, weisz ich aber nicht mehr. Ich meinte als Pfadtrenner, oder meintest du root? Dann habe ich nichts gesagt...

Also es mag sein, dass es mehr und mehr Windows Applikationen gibt, die den / jetzt auch kennen, aber ich wäre da sehr vorsichtig. Zumindest bei windows 7 war das kein durchgehendes Verhalten.

Problem ist jetzt nur das er nur die erste Zeile des Textdokuments anzeigt.

Ja, Du liest derzeit ja nur eine Zeile ein. Du kannst das über eine while Schleife laufen lassen oder Du nutzt Files.readAllLines oder Du nutzt einen (File)Reader mit der Methode transferTo (Ab Java 11 oder so), oder ....

Es gibt also prinzipiell recht viele Wege das zu erreichen.

 

[Alex_99]

Ich habe es jetzt mal umgeschrieben und jetzt liest er auch das ganze Dokument ein.

import java.io.*;
import java.util.Scanner;

public class Changelog {
        public static void changelog() {
            FileReader fr = null;
            try {
                fr = new FileReader("./Changelog.txt");
            } catch (FileNotFoundException e) {
                throw new RuntimeException(e);
            }
            BufferedReader br = new BufferedReader(fr);

            String zeile = null;
            try {
                zeile = br.readLine();
            } catch (IOException e) {
                throw new RuntimeException(e);
            }

            while( zeile != null )
            {
                System.out.println(zeile);
                try {
                    zeile = br.readLine();
                } catch (IOException e) {
                    throw new RuntimeException(e);
                }
            }

            try {
                br.close();
            } catch (IOException e) {
                throw new RuntimeException(e);
            }
            change();
        }
public static void change(){
    Scanner sc = new Scanner(System.in);
    String wahl;
    System.out.println("1 - Menue");
    System.out.println("2 - Beenden");
    wahl = sc.next();
    switch (wahl){
        case "1":
            Main.clrscr();
            Main.main(null);
        case "2":
            System.exit(1);
        default:
            Main.clrscr();
            System.out.println("Nochmal versuchen!");
            change();
    }
}
}

Quelle: http://www.javaschubla.de/2007/javaerst0250.html

 

[Alex_99]

Jetzt ist aber das Problem mit dem Filesuchen unter Linux und Macos noch nicht gelöst.
Unter Macos zeigt er mir die Ausgabe nur dann an wenn ich die Datei im Root Verzeichnis sichere.

 

[KonradN]

Nur als kleiner Vorschlag mal eine leicht umgeschriebene Variante, die
a) try with resources nutzt (Damit wird der reader automatisch geschlossen.
b) Nicht so viele try / catch geschrieben werden müssen.

    public static void changelog() {
        try ( BufferedReader br = new BufferedReader(new FileReader("./Changelog.txt"))) {
            String zeile = null;
            zeile = br.readLine();
            while( zeile != null )
            {
                System.out.println(zeile);                 
                zeile = br.readLine();
            }

        } catch (IOException e) {
            throw new RuntimeException(e);
        }

        change();
    }

 

[Alex_99]

Danke

 

[KonradN]

Jetzt ist aber das Problem mit dem Filesuchen unter Linux und Macos noch nicht gelöst.
Unter Macos zeigt er mir die Ausgabe nur dann an wenn ich die Datei im Root Verzeichnis sichere.

Da ist jetzt die Frage erst einmal, wie Du es startest. Du versuchst halt, die Datei im aktuellen Arbeitsverzeichnis zu öffnen. Das sollte man so in der Regel nicht machen.

Die Datei wird ja zur Entwicklungszeit bereit gestellt. Damit sollte diese Datei als Ressource eingebunden werden. Dann wäre das Lesen dieser z.B. so denkbar:

    public static void changelog() {
        try ( BufferedReader br = new BufferedReader(new InputStreamReader(Changelog.class.getResourceAsStream("/Changelog.txt")))) {
            String zeile = null;
            zeile = br.readLine();
            while( zeile != null )
            {
                System.out.println(zeile);                
                zeile = br.readLine();
            }

        } catch (IOException e) {
            throw new RuntimeException(e);
        }

        change();
    }

Edit: Natürlich noch den . bei ./Changelog.txt entfernt!

 

[Alex_99]

Was macht dies anders als meine Lösung?

 

[KonradN]

- Die Datei wird bestandteil Deines Programmes. Damit liegt diese nicht mehr direkt im Dateisystem sondern z.B. Bestandteil vom JAR File
- Es wird nicht auf dem Dateisystem direkt geschaut (und dort im Arbeitsverzeichnis) sondern der Classloader schaut im Classpath nach der Datei. Und da es so wie Deine Klassen ein Bestandteil Deines Programmes ist, wird die Datei auch direkt gefunden.

 

[Alex_99]

Wow! Vielen Dank.
Funktioniert wunderbar!

 

[Alex_99]

Klappt das auch umgekehrt (Daten in Datei schreiben)?

 

[KonradN]

Nein, die Ressourcen sind nur zum lesen. Wenn Du etwas schreiben willst, dann solltest Du das an einem geeigneten Ort machen. Sehr gerne wird dazu z.B. das Userverzeichnis genommen. Dieses kannst Du per System Property user.home bekommen:

System Properties (The Java™ Tutorials > Essential Java Classes > The Platform Environment)

 

[Alex_99]

Hintergrund ist, dass ich eine Rechnerhistory erstelle und diese momentan ebenfalls am Mac im Root Verzeichnis erstellt wird.
Wenn man die so integrieren könnte wie die Datei, die gelesen wird wäre das super.
Ich könnte ja die Funktion zum lesen wiederverwenden sodass er dann die geschriebene History liest und ausgibt wenn ich das anfordere.
Quasi also die Datei in die Jar integrieren und nur bei Bedarf abfragen mit einer Kopie der Klasse changelog, die ich dann so ändere, dass Sie auf die History zeigt.

Folgendes ist der Code der momentan die History anlegt:

import java.io.File;
import java.io.FileWriter;
import java.io.IOException;

public class Log {
    FileWriter writer;
    File file;
    public void schreiben(){
        // File anlegen
        file = new File("./history.txt");
        if (Main.clearhistory == true || Main.historyprozent == true || Main.historyrechner==true || Rechner.weiterrechnen == true){
        try {
            // new FileWriter(file ,true) - falls die Datei bereits existiert
            // werden die Bytes an das Ende der Datei geschrieben

            // new FileWriter(file ,false) - falls die Datei bereits existiert
            // wird diese überschrieben
            writer = new FileWriter(file ,true);
            if (Main.clearhistory == true){
                writer = new FileWriter(file ,false);
                writer.write("");
            }

Hatte ich auch schon versucht zu ergooglen, habe aber leider nichts dahingehend gefunden.. :/

 

[KonradN]

Du solltest eben nicht so auf Dateien zugreifen so Du nicht ganz sicher bist, dass das Arbeitsverzeichnis das Verzeichnis ist, in dem Du etwas speichern willst. Daher der Hinweis mit dem Homeverzeichnis. Dort kannst Du ein Verzeichnis anlegen für Deine Applikation, vorzugsweise mit einem . am Anfang. Dann kannst Du einen Pfad aufbauen wie z.B. per
Path directory = Path.of(System.getProperty("path.separator", ".myapp"));

Das Verzeichnis kann man anlegen mit einem Befehl wie:
Files.createDirectory(directory, null);

Den Path vom File hätte man dann z.B. per
Path file = Path.of(System.getProperty("path.separator", ".myapp", "history.txt"));

Und um da einen BufferedReader oder BufferedWriter zu bekommen, könnte man nutzen:
Files.newBufferedReader(file)
oder
Files.newBufferedWriter(file)

 

[KonradN]

Wenn man es ganz gut machen wollte, dann könnte man schauen, ob es evtl. eine Library gibt, die einem den ganz korrekten Ordner gibt. Unter Windows wäre das etwas wie %AppData%, Linux hat oft ein ~/.config/ Ordner mit weiteren Unterordnern und so ... Mac will sowas teilweise in ~/Library/Application Support/ haben oder so. Aber das macht die Logik recht komplex. Und man hat eh immer viele Ordner im Home-Verzeichnis. .m2 von gradle, .p2 von eclipse, .eclipse, .flutter, .vaadin, .... Also da landet so viel - da kann Deine App bestimmt auch noch ein Ordner anlegen

 

[Alex_99]

Hat mit ein wenig Hilfe von "https://www.java-forum.org/thema/java-neue-datei-erstellen.100781/" funktioniert.

public void schreiben(){
        if (!new File(System.getProperty("user.home") + "/Documents").exists()) {
            new File(System.getProperty("user.home") + "/Documents").mkdir();
        }

        if (!new File(System.getProperty("user.home") + "/Documents/Rechner").exists()) {
            new File(System.getProperty("user.home") + "/Documents/Rechner").mkdir();
        }
        // File anlegen
        file = new File(System.getProperty("user.home") + "/Documents/rechner" + "/history.txt");

 

[KonradN]

Achte auf die Gross-/Kleinschreibung! Wenn Du das Verzeichnis Rechner nennen willst, dann sollte es immer mit großem Buchstaben geschrieben werden! Daher zieh so Literale in eine Konstante und verwende diese überall, wo Du es brauchst.

 

[Alex_99]

Wurde angepasst

 

[Neumi5694]

Wurde angepasst

Alternativ immer Variablen verwenden anstatt Strings

File home = new File (System.getProperty("user.home"));
File basedir = new File(home, "Documents");
File myRechner = new File (basedir, "Rechner");

Damit kommt jeder Name genau einmal vor und du hast eindeutige Referenzen.


Und am besten: Auf deine Abfragen komplett verzichten, es gibt da bereits eine geeignete Methode

File targetFile = new File (System.getProperty("user.home"),"Documents/Rechner/myFile.txt");
targetFile.getParentFile().mkDirs();//macht nichts, wenn das Verzeichnis bereits existiert, erstellt ansonsten alles, was notwendig ist

Eventuell noch Zugriffsrechte überprüfen

File targetFile = new File (System.getProperty("user.home"),"Documents/Rechner/myFile.txt");
if (targetFile.canWrite()) {
  targetFile.getParentFile().mkDirs();
  try (Writer writer = new SomeWriter(targetFile)) {
  }
}

Nur als Anmerkung: Windows kann beides, kommt sowohl mit Slash als auch mit Backslash zurecht, sogar in der Eingabeaufforderung und der Powershell, das hat mit Java nichts zu tun. Sogar "//" für Netzwerkadressen klappt. Windows macht beim Parsen eines Dateinamens schlichtweg keinen Unterschied zwischen Slash und Backslash, mehrfach vorkommende werden ausgefiltert, sogar das hier würde funktionieren:

cd /d c:/users\/\//\\MyName/\Documents/\/\/\Rechner

Dies verhindert natürlich recht effizient das Verwenden von Escapezeichen oder anderen Sonderzeichen, weshalb man - um z.B. eine Datei mit problematischem Namen zu löschen oder umzubenennen, am Besten in eine Bash wechselt.
Die CMD würde die Datei oder den Ordner nicht finden, der Textparser würde zu viel wegoptimieren und ist außerdem auf 256 Zeichen begrenzt (das Betriebssystem und Dateisystem kann mehr, aber der Textparser des Win32 Kernel scheitert).
Per Powershell ist das zwar auch möglich, aber per Bash ist es deutlich komfortabler.

Man kann per Java auf eine Datei mit ungültigem Namen natürlich nicht per new File("...") zugreifen, da dieser beim Zugriff ja durch den Parser läuft.
Was man aber machen kann, ist im Parent alle Dateien zu listen. Die File-Objekte in der Liste referenzieren direkt, ohne den Parser anzusprechen. Auch so kann man die Datei z.B. umbenennen oder verschieben.

 

[KonradN]

Windows kann beides, kommt sowohl mit Slash als auch mit Backslash zurecht

Mag sein, dass es da mit Windows 10 keine Probleme mehr gibt, aber ich bin mir sehr sicher, dass es da bei Windows XP und Windows 7 noch einige Probleme gab. Und wenn man im Netz sucht, dann findet man auch einige Quellen, die das belegen, z.B. bin ich eben auf die Schnelle auf

Backslash vs Forward Slash: Difference in Grammar, File Path - MiniTool

What’s the difference between backslash & forward slash? Are they the same in grammar, file path, keyboard, etc.? what’s their function in different systems?

www.minitool.com

gestoßen:

Yet, the automatic correction doesn’t apply everywhere in Windows. If you type a forward slash file path into the Open dialog and press Enter, you will be prompted with an error message saying “this file name is not valid”.

Also ja, Microsoft mag das an immer mehr Stellen ersetzen, so wie es z.B. auch Browser machen. Und eben auch Java! Aber Windows kommt mit extrem viel Altlasten und die packt Microsoft in der Regel eben nicht an. Und übrig bleibt ein System, das in sich extrem inkonsistent ist im Verhalten.

 

[mihe7]

Und übrig bleibt ein System, das in sich extrem inkonsistent ist im Verhalten.

Das dann als Windows vermarktet wird. SCNR. Obwohl... wenn ich da alleine an "mehrsprachige" Verzeichnisnamen denke, dann fragt man sich schon, was die geraucht haben.

 

[KonradN]

Das dann als Windows vermarktet wird. SCNR. Obwohl... wenn ich da alleine an "mehrsprachige" Verzeichnisnamen denke, dann fragt man sich schon, was die geraucht haben.

Microsoft überlegt sich da halt immer irgend etwas cooles, tolles. Damit muss man dann leben

Was ich da schon alles erleben musste weil ich halt beruflich auch in dem Bereich einiges zu tun hatte ... Das heftigste war, dass ein Verzeichnis c:\Program anzulegen den ganzen Windows XP Rechner instabil gemacht hat. Nach einem Softwareversand auf viele Rechner (war also schon 4-stellig) gab es massive Probleme mit den Windows Installationen und man war schon am überlegen, wie da die Systeme schnell wieder betankt werden könnten ... Als wir dann den Fehler gefunden hatten ... ein kleiner Befehl, der das Verzeichnis löschte auf jedem Rechner und es lief wieder alles normal. Ich denke, sowas kann man nicht so schnell toppen

Aber der große Vorteil ist halt, dass wirklich alles noch unterstützt wird. Also nicht wie Apple, die ja wirklich alles weghauen. Ohne wirklichen Grund. Rosetta hätte man doch einfach da lassen können ohne Support oder so. Auf Windows 10 läuft auch heute bestimmt noch eine uralt VB 6 Anwendung ... Das nennt sich Investitionsschutz... Und Windows 10 läuft auch auf alten Rechnern noch gut. Es gibt also immer Vor- und Nachteile. Schimpfen kann ich über jeden Hersteller / Entwickler. Der Vorteil, wenn man in allen Welten unterwegs ist

 

[Neumi5694]

Mag sein, dass es da mit Windows 10 keine Probleme mehr gibt, aber ich bin mir sehr sicher, dass es da bei Windows XP und Windows 7 noch einige Probleme gab. Und wenn man im Netz sucht, dann findet man auch einige Quellen, die das belegen, z.B. bin ich eben auf die Schnelle auf

Backslash vs Forward Slash: Difference in Grammar, File Path - MiniTool

What’s the difference between backslash & forward slash? Are they the same in grammar, file path, keyboard, etc.? what’s their function in different systems?

www.minitool.com

gestoßen:


Also ja, Microsoft mag das an immer mehr Stellen ersetzen, so wie es z.B. auch Browser machen. Und eben auch Java! Aber Windows kommt mit extrem viel Altlasten und die packt Microsoft in der Regel eben nicht an. Und übrig bleibt ein System, das in sich extrem inkonsistent ist im Verhalten.

Bei XP kann ich's nicht mehr sagen, ist zu lange her (muss mal schauen, ob ich noch ein Image davon finde für die VM). Bei 95 ging's jedenfalls noch nicht, bei Windows 7 hingegen hatte - denke ich - ich diesbezüglich keine Probleme, seitdem hat sich ja aber auch nichts Grundlegendes mehr geändert. Seit Windows 8 gibt's damit aber garantiert keine Probleme mehr und das erschien vor mittlerweile 10 Jahren.

Ich hatte auch schon eine 64Bit Version von Windows XP, die englisch installierte und danach ein Sprachpack drauf, MS war sich sehr bewusst, dass die mehrsprachigen Verzeichnisse Blödsinn waren, hatten damit schon erste Schritte unternommen, das wieder in Ordnung zu bringen.

Edit: Zu XP kann ich's doch sagen, hab einen Bericht gefunden, wo's damit eben nicht ging.
"Wenn man im Netz sucht" hat auch ergeben, dass schon DOS2.0 das kann, was Blödsinn ist und einen Bericht hab ich von 2018 gelesen, wo es mit Windows anscheinend nicht ging. Allerdings hatte der eben XP verwendet, ohne das zu erwähnen. Es gibt leider zu viele, die sich auf Altwissen verlassen, ohne es zu überprüfen, wenn sie schreiben.

 

[KonradN]

Die Frage ist, was genau geht? Ich habe auf Windows 10 mit einem aktuellen Excel probiert, in dem Durchsuchen Dialog beim Datei Öffnen als Dateiname Verzeichnis/Datei einzugeben und das ging nicht. Es gab sogar eine explizite Fehlermeldung a.la. Dateiname ungültig.

Mit dem \ liess sich die Datei öffnen.

Das ganze Windows Ecosystem ist sehr umfangreich und ich bestreite nicht, dass gerade aktuelle Bereiche auch mit dem Slash umgehen können. Aber das Problem ist, dass man eben nicht wissen kann, wo es funktioniert und wo eben nicht. Daher eben der explizite Ratschlag, dass man eben immer die korrekten Zeichen verwendet und sich eben nicht auf irgendwelche Korrekturen verlässt.

Das ist schlicht meine Sicht und jeder kann das so handhaben, wie er möchte. Nur eben darf man sich dann nicht wundern, wenn man dann hin und wieder doch Probleme bekommt.

 

[Neumi5694]

Die Frage ist, was genau geht?.

Windows Explorer, Kommandozeile, Ausführen Dialog, Powershell, Bash (wobei die ja 3rd party ist). Hab's auch mit ein paar Programmen versucht wie OpenOffice, Aimp, Notepad++.
In Java nutzen wir auch den nativen Windows Dialog über JNA (wollten die Kunden so haben), auch damit geht's (sprich: Der Dialog akzeptiert so einen Pfad, es geht nicht um die Verwendung hinterher, wo wieder was konvertiert werden könnte).
Warum's in Excel nicht klappt, weiß ich nicht. Wenn, dann würde ich mal vermuten, dass die da noch eine Abfrage drin haben.

 

[Neumi5694]

Wie gesagt, ich denke nicht, dass diese "Konvertierung" von Java ausgeht, vor allem deshalb, weil Java so wie der Windows Explorer und die Eingabeaufforderung an ungültigen Zeichen scheitert, sehr wohl wie oben beschrieben aber eine Datei ansprechen kann, deren Namen ungültige Zeichen enthält.
Wenn jemand noch einen alten '95 Rechner hat, wäre es nett, dort mal ein Java-Programm auzuführen, das auf "c:/windows" zugreifen will. Wenn ich Recht habe, dann geht das daneben.


Kleiner Tip:
Wenn man aber wirklich konsequent die richtigen Slashes verwenden will ...
per File.getCanonicalPath() wird - sofern möglich - der "echte" Dateiname angefordert, also mit korrekter Groß-/Kleinschreibung und formatiert mit Backslashes.
Will man aber schon von Anfang an Backslashes haben, bietet es sich an, sich eine kleine Methode dafür zu schreiben.
Den Konstruktor File(String,String) und File(File,String) kennt man ja, der fügt dann dazwischen File.separator ein.
Bevor ich mir bewusst wurde, dass Windows kein Problem mit Slashes hat, hab ich mir mal eine ähnliche Methode geschrieben.
File generateFile(String base, String...names) {}
Die macht dann genau das Gleiche, halt mit einem Array flexibler Länge.

 

[KonradN]

Nur blöd dass es fast egal ist, an wie vielen Stellen es geht - so lange es Stellen gibt, an denen es nicht geht.

Und wenn ich mir das FileChooser Beispiel von Oracle ansehe, dann sieht mir das nicht nach dem, Windows Dialog aus. Bildschirmfoto man angefügt.

Das muss man aber nicht vertiefen - die Faktenlage bleibt nun einmal: Windows führt extrem viele Altlasten mit und da ist es dann vollkommen normal, dass es weiterhin Stellen geben wird, bei denen es nicht funktionieren wird. Und sei es nur, weil da irgend eine Kontrolle ist (Ich bekam ja auch eine Fehlermeldung von wegen ungültigem Dateinamen - kein File not found oder so!) Es kann also sogar so sein, dass alles funktioniert hätte wenn der Check es nur hätte durchgehen lassen ...

Und ich bestreite in keiner Form, dass es mehr und mehr Stellen gibt, in denen es funktioniert. Nur das spielt (für mich) ebenso keine Rolle wie im Clean Code: Die Tatsache, dass ein Code funktioniert ist eben (für mich) nicht ausreichend. Und wenn jemand seine Variablen i1, i2 und i3 oder in verschachtelten Schleifen i, j und k nennen will: Ja, das geht. Nur eben nicht wundern, wenn es dann Fehler gibt und man diese nicht oder nur schwer findet. (Und ich möchte den Anwender sehen, wenn er dann bei sich doch mal die Stelle findet, wo das c:/windows dann plötzlich nicht geht weil er das ja gar nicht anders kennt )

Ein anderer Fall: Mir hat ein User des Forums Dateien zukommen lassen mit URLs, die \ und keine / hatten. Bei ihm ging es. Bei mir auf meinem Mac nicht. Ich musste die erst manuell umsetzen damit ich die Dateien herunter laden konnte. Daher bitte ruhig immer Daten korrekt angeben und nicht davon ausgehen, dass es schon irgendwie verstanden wird. Das mag oft gehen, aber es ist eben nicht sicher gestellt, dass es immer gehen wird.

Ich hoffe, ich konnte meine Position etwas deutlich machen. Macht alles so, wie ihr es für richtig haltet. Aber meine Position diesbezüglich ist nun einmal etwas anders und die habe ich jetzt hoffentlich deutlich machen können, so dass das Thema "gegessen" sein dürfte.

 

[Neumi5694]

Wie gesagt, ich rede von Windows und nicht von 3rd Party Anwendungen. Was Excel oder andere Dritte nicht können, interessiert mich wenig.

Was willst du mir mir dem Oracle Beispiel sagen? Ich hab doch vorhin ganz klar gesagt, dass ich den nativen von Windows nutze.
Aber der JFileChooser hat auch kein Problem damit.

        JFileChooser fc = new JFileChooser();
        fc.setSelectedFile(new File("C:/Windows/win.ini"));
        fc.showOpenDialog(null);

Auch den Bezug zu for-schleifen verstehe ich bezüglich Dateinamen nicht. Wenn du zeigen willst, dass ein Backslash "cleaner" ist als ein Slash, dann ist ein Beispiel mit schlecht benannten Variablen nicht wirklich hilfreich.
Microsoft unterstützt nunmal seit mindestens 10 Jahren an die geltenden Standards und es spricht nichts dagegen, diese auch zu nutzen.

Dass jeder so arbeiten soll, wie er mag, darin stimmen wir überein. Ob man nun lieber die gültigen Standards nutzt oder was spezielles für Windows schreiben will, das soll jeder selbst für sich entscheiden, das interessiert mich nicht.

In meinem Post ging's darum, was Windows kann und was nicht und nicht darum, eine "richtigere" Vorgangsweise zu propagieren. Das ist meine Position.

edit: Der Java Filechooser schaut mit dem Windows Look and Feel schon viel mehr nach Windows aus, wenn auch noch nicht ganz

 

[KonradN]

Wie gesagt, ich rede von Windows

Also mit dieser Abgrenzung werden wir nicht weit kommen. Selbst wenn ich eine Library finde, in der es das Problem gibt, wirst Du dann sagen: "Das ist ja die C++ Library von MFC" oder so. Wenn Du auf Windows als Anwender unterwegs bist und den / statt \ verwendest, dann kannst Du auf Probleme stoßen. Ganz allgemeines Aussage. Und ich habe ein Beispiel gebracht, das dies aufzeigt.

Ob man nun lieber die gültigen Standards nutzt

Damit implizierst Du einen Standard! Dann zeige mir den Standard, der den / als Pfadtrenner unter Windows spezifiziert bzw. die unter Windows anwendbar ist.

Der Java Filechooser schaut mit dem Windows Look and Feel schon viel mehr nach Windows aus, wenn auch noch nicht ganz

Es geht nicht um das Look and Feel und ob etwas so aussieht. Es geht um die Frage, ob die zugrunde liegende Technik genutzt wurde oder ob etwas eigenes entwickelt wurde.

 

[Neumi5694]

Also mit dieser Abgrenzung werden wir nicht weit kommen. Selbst wenn ich eine Library finde, in der es das Problem gibt, wirst Du dann sagen: "Das ist ja die C++ Library von MFC" oder so. Wenn Du auf Windows als Anwender unterwegs bist und den / statt \ verwendest, dann kannst Du auf Probleme stoßen. Ganz allgemeines Aussage. Und ich habe ein Beispiel gebracht, das dies aufzeigt.


Damit implizierst Du einen Standard! Dann zeige mir den Standard, der den / als Pfadtrenner unter Windows spezifiziert bzw. die unter Windows anwendbar ist.


Es geht nicht um das Look and Feel und ob etwas so aussieht. Es geht um die Frage, ob die zugrunde liegende Technik genutzt wurde oder ob etwas eigenes entwickelt wurde.

Nenn doch eine Library, die du für deine Java-Programme verwendest, in der das nicht geht.
Der eine Punkt ist sicher: Der Kernel von Windows unterstützt diese Schreibweise (kannst du ja mal über JNA ansteuern, wenn du's nicht glaubst). Wer das nun nutzen will und wer nicht, ist mir egal.
Schlimmstenfalls kann man sich ja auch mit getCanonicalPath() die Schreibweise holen, die von Programmen verwendet wird, die das nicht können.
(welche C++ Library kann das denn nicht? Kannst du eine nennen? Ich würd's gerne testen)

Ich könnte dir weder einen echte Standard-Referenz auf "\" für Windows nennen, noch "/". Auch könnte ich dir keinen für MacOS nennen.
Hunderttausende Posts und Forenbeiträge zu dem Thema ... ja - aber keine offizielle Referenz. Das mag jemand tun, der mehr Zeit und Laune hat als ich.

Was das Look & Feel angeht stimmen wir überein, das hab ich nur noch als Edit hinzugefügt, weil du auch einen Screenshot gepostet hast mit den Worten "dann sieht mir das nicht nach dem, Windows Dialog aus". Falls es nicht um die UI ging, was sollte das Ganze dann? Sorry, aber die Kombination aus Screenshot mit den Worten "sieht aus" legt doch nahe, dass es um die Optik geht, meinst du nicht auch?
Ich meine: Dass der JFileChooser in Java programmiert wurde, wissen wir doch beide. Dass es problemlos möglich ist, den nativen Filechooser zu verwenden, wissen wir auch beide (ich bin mir sogar fast sicher, dass JavaFX als Standard den nativen FileChooser verwendet, jedenfalls war das in Java8 so). Was sollte das Ganze also aussagen?

 

[KonradN]

Ich könnte dir weder einen echte Standard-Referenz auf "\" für Windows nennen, noch "/". Auch könnte ich dir keinen für MacOS nennen.
Hunderttausende Posts und Forenbeiträge zu dem Thema ... ja - aber keine offizielle Referenz. Das mag jemand tun, der mehr Zeit und Laune hat als ich.

Dann schau doch einfach mal in die Dokumentation von Microsoft. .Net Code bietet z.B. den DirectorySeparatorChar (in Path). Auf was ist das gesetzt? Und es gibt eine Alternative AltDirectorySeparatorChar: Auf was ist die gesetzt? (Der Hersteller von Windows wäre ja derjenige, der so einen Standard setzen würde).

Damit sind wir aber bei einer relativ neuen Technologie (.Net) - man kann sich aber die Methoden ansehen, die man so nutzen kann. Wir können uns ja eine Methode ansehen, die den Windows Pfad einem gibt:

GetWindowsDirectoryA function (sysinfoapi.h) - Win32 apps

Retrieves the path of the Windows directory. (ANSI)

docs.microsoft.com

Was liefert Windows denn da? Das wäre ja dann etwas, womit Windows intern arbeitet.

Sowas könnte man ggf als "Standard" ansehen.

Bezüglich der Libraries findet man leider nicht ganz so viel alte Dokumentation. Ich habe mir mal die MSVC-140 angesehen und da unterstützt fopen sowohl \ als auch /.

Dieser Hinweis fehlt aber bei einigen anderen Methoden, so dass die Frage ist, wie sich _sopen, remove, ... verhalten. Aber das werde ich nicht tiefer prüfen, denn das ist so in der Tiefe schlich uninteressant.

Es kann unter Windows zu Problemen kommen - und dazu reicht ein einziges Problem, dass ich aufzeigen muss und das ist mir mit einem Microsoft Programm, das weit verbreitet ist, tatsächlich gelungen womit diese Aussage bewiesen ist.

Und bezüglich Standard kann man dann die Dokumentation heran ziehen, was ich getan habe. Soweit sollten diese Punkt an der Stelle dann erledigt sein.

Nenn doch eine Library, die du für deine Java-Programme verwendest, in der das nicht geht.

Und genau um Java ging es hier explizit nicht. In Java empfehle ich selbst, dass ein / benutzt wird. Ebenso kann es ok sein, dies in anderen Umgebungen zu empfehlen. Aber es geht um die generelle Verwendung unter Windows und die ist und bleibt problematisch. Die Fälle mögen immer weniger werden, aber das ändert dennoch nichts daran, dass es gewisse Probleme immer noch gibt bzw. sich diese (immer noch) finden lassen.

 

[Neumi5694]

Funktioniert denn der Aufruf iin .Net mit "/" nicht?

edit: Ich müsst mal schauen, ob die Funktionen in C# oder in C++ geschrieben sind, (ich denke C#) aber von AutoCAD aus geht's.

 

[Neumi5694]

Funktioniert denn der Aufruf iin .Net mit "/" nicht?

edit: Ich müsst mal schauen, ob die Funktionen in C# oder in C++ geschrieben sind, (ich denke C#) aber von AutoCAD aus geht's.

Außerdem hab ich ganz spezifisch nach den Betriebssystemfunktionen gegfragt. Ja, man kann argumentieren, dass .Net mittlerweile Teil davon ist, deshalb die Frage, ob .Net einen "/" Aufruf akzeptiert.


Ja, Excel hat da anscheinend Probleme, das glaub ich einfach mal so, verwende seit Jahren kein Excel mehr. Das hab ich auch nie angezweifelt, es geht einzig und allein um Windows an sich, denn:

[...] Windows kann das eigentlich gar nicht. Aber damit Entwickler in Java einheitliche Pfade angeben können, können Entwickler generell den / statt dem \ verwenden.[...]

Und das ist nunmal schlicht und einfach falsch. Um nichts anderes geht es in meinen Posts. Nicht um Excel, nicht um irgendwelche exotischen Programme, nicht um Runtimes. Nur um diese eine Aussage. Die hab ich korrigiert und sonst nichts.

ps: Wenn man sich nicht sicher ist, dann - wie gesagt - einfach getCanonicalPath() nutzen. Damit braucht man sich nur noch um einen Standard zu kümmern und überlässt dem Rest der Schnittstelle zum Betriebssystem.

 

[KonradN]

Funktioniert denn der Aufruf iin .Net mit "/" nicht?

Die .Net Methoden akzeptieren beides - der / ist ja als Alternative aufgeführt. Das findet sich an diversen Stellen der Dokumentation.

Und das ist nunmal schlicht und einfach falsch.

So lange es Teile von Windows gibt, die damit noch Probleme haben, gilt es eben doch. Excel ist jetzt kein Teil von Windows, aber dann teste mal die alten ODBC Elemente, die es noch gibt. Oder irgend welchen anderen uralt Kram. Der ist Bestandteil vom Produkt Windows und dann hätten wir ein Beispiel, dass es aufzeigt, dass Windows es eben nicht (komplett) kann. Du kannst auch gerne in der API weiter herum probieren, was Du da ggf. noch findest.

Wenn man sagt, dass Windows etwas kann, dann muss es das komplett können und nicht nur in Teilen.

 

[Neumi5694]

Die .Net Methoden akzeptieren beides - der / ist ja als Alternative aufgeführt. Das findet sich an diversen Stellen der Dokumentation.


So lange es Teile von Windows gibt, die damit noch Probleme haben, gilt es eben doch. Excel ist jetzt kein Teil von Windows, aber dann teste mal die alten ODBC Elemente, die es noch gibt. Oder irgend welchen anderen uralt Kram. Der ist Bestandteil vom Produkt Windows und dann hätten wir ein Beispiel, dass es aufzeigt, dass Windows es eben nicht (komplett) kann. Du kannst auch gerne in der API weiter herum probieren, was Du da ggf. noch findest.

Wenn man sagt, dass Windows etwas kann, dann muss es das komplett können und nicht nur in Teilen.

Kannst du denn mit Sicherheit sagen, dass ODBC das nicht kann?
Oder kennst du ganz spezifisch einen Teil des Betriebssystem nennen, der das sicher nicht kann?

Wenn man sagt, dass Windows etwas nicht kann, dann muss es komplett unmöglich sein und nicht nur in wenigen Einzelbeispielen, oder?

Edit: Hab das mit ODBC gerade getestet.
1. Der Dialog akzeptiert die Eingabe, wandelt den Slash dann um.
2. Dann bin ich in die Registry, um den Backslash wieder durch Slash zu ersetzen. Hat auch geklappt, die ODBC-Verbindungsübersicht zeigt jetzt den Slash an. Die Verbindung funktioniert immer noch..
Dacht mir noch, dass ich das schon vor Windows 8 so gemacht hatte.
Direkt (also nicht über eine vorgegebene Verbindung) hatte ich auf diese Weise mal eine FireBird-DB verbunden

 

[Neumi5694]

Dann sagen wir's halt so: Windows kann das nicht, Ausnahme sind fast alle Fälle und Beispiele, mit denen man es jemals zu tun kriegt.

 

[KonradN]

Die Aussage, dass Windows das nicht kann, mag durchaus überspitzt sein. Ich bin etwas überrascht, dass es an so vielen Stellen so funktioniert, denn ich bin mir relativ sicher, dass es da vor nicht zu langer Zeit deutlich mehr Probleme gab.

Aber ich bin auch bisher davon ausgegangen, dass die alten Teile nicht überarbeitet würden und so - aber bei der Dokumentation ist mir aufgefallen, dass da auch bei alten Elementen durchaus aktuelle Zeitstempel zu finden waren. Somit scheint Microsoft da deutlich mehr zu machen als ich dachte.

 

[KonradN]

Edit: Hab das mit ODBC gerade getestet.
1. Der Dialog akzeptiert die Eingabe, wandelt den Slash dann um.
2. Dann bin ich in die Registry, um den Backslash wieder durch Slash zu ersetzen. Hat auch geklappt, die ODBC-Verbindungsübersicht zeigt jetzt den Slash an. Die Verbindung funktioniert immer noch..

Das ist übrigens auch etwas, das mich irritiert: Wozu ersetzen, wenn es doch egal ist? Da muss dann also doch auch auf Microsoft Seite ein Entwickler oder Architekt sein, der sagt: "Wer weiss, ob das nicht doch noch irgendwo zu Problem führt - ersetzen wir den Slash mal lieber durch Backslash." Oder von mir aus auch: Wir wollen den Leuten zeigen, dass es mit \ besser ist oder so. Und da kommt dann halt in mir die Frage; Wieso?

Aber bezüglich dem "Windows kann das nicht" ist Deine Auslegung besser und diese Aussage so in der Form von mir war nicht ok. Da muss ich Dir Recht geben.

 

[Neumi5694]

Das ist übrigens auch etwas, das mich irritiert: Wozu ersetzen, wenn es doch egal ist? Da muss dann also doch auch auf Microsoft Seite ein Entwickler oder Architekt sein, der sagt: "Wer weiss, ob das nicht doch noch irgendwo zu Problem führt - ersetzen wir den Slash mal lieber durch Backslash." Oder von mir aus auch: Wir wollen den Leuten zeigen, dass es mit \ besser ist oder so. Und da kommt dann halt in mir die Frage; Wieso?

Aber bezüglich dem "Windows kann das nicht" ist Deine Auslegung besser und diese Aussage so in der Form von mir war nicht ok. Da muss ich Dir Recht geben.

Früher war es nicht egal, da hast du ja recht (sagen wir mal in der pre 2010 Ära). Es handelt sich hier noch um einen Uralt-Dialog, der heutzutage eigentlich nicht mehr genutzt wird. Aber selbst hier haben sie die Möglichkeit geschaffen, das einzugeben.

Ein weiterer Punkt dürfte das von dir angesprochene Problem mit Excel und eben auch Access sein (dem wohl am häufigsten genutzten DB-System 'kleiner' Programme).
Ich hab mir den Datei Öffnen Dialog von Access 2003 angeschaut. Wenn Slashes verwendet werden, dann wird das Ganze als html interpertiert (edit: denk ich, schaut jedenfalls danach aus, das ist schon ein ziemlicher Murks), Leerzeichen werden z.B. durch %20 ersetzt. Das geht spektakulär in die Hose.

 

[Neumi5694]

Gut, dass wir getCanonicalPath() haben und uns deswegen keine Gedanken mehr machen müssen. Damit ist man immer sicher.

 

[mihe7]

Wenn ich mir die Doku durchlese, dann ist unter https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#paths einzig der Backslash als zulässiges Trennzeichen in einem Pfad angegeben.

Bei CreateFileA/W ist explizit spezifiziert, dass man einen Slash verwenden kann, bei CreateFile2 dagegen nicht. Bei den FindFirstFile-Funktionen wird dagegen explizit genannt, dass der String nicht mit einem Backslash enden darf. Ein Slash wäre demnach entweder am Ende des Strings kein Problem oder er ist dort grundsätzlich nicht erlaubt (invalid string).

Kurz: die Verwendung des Slashs als Trennzeichen erfolgt unter Windows nicht konsistent - und sowas ist einfach Mist, ganz gleich, ob das nun ein Problem des Codes oder der Spezifikation ist.