Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
ich habe mein Debian Jessie wegen HW-Schaden auf neuer Maschine neuinstalliert. Und ich habe generell von allen Einstellungen, Dateien Backups, so dass das generell kein Problem stellt.
Jetzt zeigt aber ein Java-Projekt, das vorher diesen Fehler in der IDE Intellj nicht zeigte, folgende Meldung:
"cannot resolve constructor 'FileInputStream(java.io.FileInputStream, java.lang.String)'"
Code:
public String readSettings(String key) {
Properties properties = new Properties();
FileInputStream in;
try {
if (new File(System.getProperties().getProperty("user.home")+File.separator+directory+File.separator+setting).exists()) {
final FileInputStream fis = new FileInputStream(new File(System.getProperties().getProperty("user.home")+File.separator+directory+File.separator+setting));
in = new FileInputStream(fis, "UTF-8");
properties.load(in);
in.close();
} else {
in = new FileInputStream(defaultFile, Charset.forName( "UTF-8" ));
properties.load(in);
in.close();
}
} catch (IOException e) {
e.printStackTrace();
}
return properties.getProperty(key);
}
Könnt Ihr mir hierbei weiterhelfen? java.io.FileInputStream ist importiert.
Also ich finde Deinen Code sehr unleserlich. Im if prüfst Du ein file um dann das file erneut innerhalb des ifs aufzubauen. Das ist z.B. doppelter Code. Und du hast dann extrem viel in einer Zeile, die eine Fehlersuche auch extrem erschwert.
Und welchen Konstruktor willst Du denn aufrufen? Ich sehe auf https://docs.oracle.com/javase/8/docs/api/java/io/FileInputStream.html keinen Konstruktor der mehrere Parameter nimmt. Daherstellt sich mir die Frage, was Du da genau machen willst. Ich bezweifle aber, dass dies jemals lief.
Und ich frage mich, wieso Du ganze Files liest nur um dann eine Property zu lesen. Wenn Du mehrere Properties liest, dann liest Du mehrfach die Datei ein. Halte ich auch für sehr unglücklich gelöst.
Sorry,
ich wollte jetzt keine schlecht machende Kritik, sondern nur eine Antwort zu meiner Frage. Das Programm, zu dem der Codeschnippsel gehört, ist lauffähig. Mal abgesehen davon, dass Deine Codes wahrscheinlich ebenso unleserlich sein werden, bei Deiner Rechtschreibung.
Das sollte kein "schlecht machen" sein sondern lediglich ein paar Hinweise. Diese kannst Du natürlich gerne ignorieren. Und den Link zur Dokumentation der FileInputStream Klasse kannst Du trotz allen anderen Hinweisen einmal folgen. Vielleicht zeigst Du uns dann einfach den Konstruktor dort, den Du gerne aufrufen möchtest.
Somit gebe ich Deine IDE Recht, die meint, dass es keinen Konstuktor FileInputStream(java.io.FileInputStream, java.lang.String) gibt.
Ja, das funktioniert auch. Das Programm nutze ich ja auch tagtäglich. Nur durch die Neuinstallation des OS kann es sein, dass ich etwas bei Java vergessen habe nachzuinstallieren.
Und wenn ich das so, wie gezeigt, gelöst habe, dann ist mein Programmierstil, egal ob der nun Anderen gefällt. Solange diese Anderen nicht nicht glasklar mit nachvollziehbaren "besseren" Programmcode ihre Kritik untermauern und das auch begründen können, bitte ich solche Posts zu unterlassen.
Mir geht es darum, den Fehler zu finden, warum unter Debian Jessie mit Oracle SDK 8 FileInputStream Probleme macht, wenn es vor der Neuinstallation noch in der gezeigt Konstellation funktioiniert hatte.
Mir geht es nicht um Änderung oder Verbesserung meines Codes. Das Problem liegt weiter vorne.
Also nur durch "etwas vergessen" oder "falsch installiert" verliert java.io.FileInputStream keinen Konstruktor. An FileInputStream hat sich über die Versionen bezüglich Konstruktoren auch nichts geändert, also wenn Du vorher Java 7 und jetzt Java 8 nutzen würdest, würde das keinen Unterschied machen. Daher ist meine Vermutung, dass es da Änderungen an dem Code gab, die jetzt evtl. nicht mehr da sind.
Und wenn man Code anschaut um nach einen Fehler zu suchen, dann sind gewisse Dinge hilfreich. Eine Sache wäre die genaue Zeile, in der der Fehler auftritt.
Und ich freue mich über jeden Hinweis bezüglich Clean Code. Die gibt es bei meinem Code auch (Wenn vielleicht auch auf einem anderen Level) und das sind immer Dinge, die zumindest ich gerne annehme weil ich so auch immer wieder dazu lernen.
Daher kommen dann auch Vorschläge von meiner Seite. Die mögen nicht immer ganz freundlich vorgebracht sein, aber dennoch sind dies sachliche Punkte. Wenn Du nicht weißt, wie die umgesetzt werden könnten, dann ist das etwas, das man anmerken kann. Eine Verpflichtung zu "besserem Programmcode" gibt es da nicht - Du kannst Vorschläge umsetzen oder es sein lassen. In Deinem Fall waren es ein paar einfache Dinge, die ich angemerkt habe.
a) Doppelter Code - das Beispiel war hier der Code im if und dann innerhalb des ifs:
Code:
if (new File(System.getProperties().getProperty("user.home")+File.separator+directory+File.separator+setting).exists()) {
final FileInputStream fis = new FileInputStream(new File(System.getProperties().getProperty("user.home")+File.separator+directory+File.separator+setting));
Du erzeugst hier zwei Mal ein identisches File Objekt, die Zeile ist recht lang und daher unübersichtlich.
Optimierung: Doppelten Code eliminieren:
Code:
File propertyFile = new File(System.getProperties().getProperty("user.home")+File.separator+directory+File.separator+setting);
if (propertyFile.exists()) {
final FileInputStream fis = new FileInputStream(propertyFile);
Wieso? Weil bei Änderungen nicht an mehreren Stellen geändert werden muss wäre ein wichtiges Argument aber generell werde ich es nicht diskutieren.
Bezüglich der Properties und laden von mehreren Werten. Da wäre das Refactoring ganz einfach. private Properties properties = null; als Instanzvariable. In der Funktion dann prüfen, ob properties null ist und dann laden. Und dann am Ende einfach den gewünschten Wert zurück geben.
Und wo ich gerade ein Refactoring mache: Try with resources statt eines close am Ende - wenn eine Exception auftritt, wird sonst nicht close aufgerufen. Daher sind die Pattern hier:
a) try with resources
b) try { ... } finally { if (in!=null) in.close(); }
Zusammen mit der Änderung hin zum InputStreamReader ergibt sich dann folgender Code:
Code:
private Properties properties = null;
public String readSettings(String key) {
if (properties == null) {
properties = new Properties();
try {
File propertyFile = new File(System.getProperties().getProperty("user.home")+File.separator+directory+File.separator+setting);
if (propertyFile.exists()) {
final FileInputStream fis = new FileInputStream(propertyFile);
try (InputStreamReader in = new InputStreamReader(fis, "UTF-8")) {
properties.load(in);
}
} else {
try (InputStreamReader in = new InputStreamReader(defaultFile, Charset.forName( "UTF-8" ))) {
properties.load(in);
}
}
} catch (IOException e) {
properties = null; // We was unable to load the properties.
e.printStackTrace();
}
}
return properties.getProperty(key);
}
Der dann jetzt auch kompilierbar ist, so es die Instanzvariablen directory und defaultFile gibt.
Und natürlich war das jetzt kein vollständiger Code-Review. Aber auf mehr Punkte gehe ich jetzt nicht ein, da dies ja explizit nicht gewünscht ist und ich somit nur die schon erwähnten Punkte zusammen mit der Anpassung hin zum InputStreamReader gemacht habe (Und das try-with-resources ist nur gekommen, weil ich da halt Hand anlegen musste und da hat meine Gewohnheit zugeschlagen sowas gleich so zu machen. Sorry dafür!).
Dann würde ich mit dir um 1000 EUR wetten, dass das Programm bereits läuft. Und die Wette würdest Du verlieren, da das Programm wie gesagt lauffähig und vor allem im Einsatz ist.
Wie stellst du dir denn die Modalitäten vor, insbesondere den Nachweis, dass deine lauffähige Version aus obigem Code stammt?
Ich sehe nur eine theoretische Möglichkeit wie das mal funktioniert haben kann, nämlich dass du nicht den originalen FileInputStream aus java.io verwendet hast, sondern einen anderen evtl. selbst programmierten. Dann müsstest du den natürlich importieren und nicht java.io.FileInputStream. Das würdest du dann aber wissen, es ist also ziemlich unrealistisch.
Ich glaube dir dass das Programm laeuft und im Einsatz ist. Aber nicht mit diesem Code-Stand. Auf deinem alten Rechner der jetzt im Nirwana ist war garantiert ein anderer Stand
Ich glaube dir dass das Programm laeuft und im Einsatz ist. Aber nicht mit diesem Code-Stand. Auf deinem alten Rechner der jetzt im Nirwana ist war garantiert ein anderer Stand
Du gibst aber auch nicht auf, oder? Ist das jetzt hier ein Besserwisser-Forum oder ein ganz neutrales Java-Forum. Offen gesagt, mich kotzen solche Talks regelrecht an. Der Einzige, der hier in diesem Thread im Sinne eines Java-Forums einen nachvollziehbaren und brauchbaren Beitrag geliefert hat, ist Kneitzel. Alles Andere, was geliefert wurde, ist so typischer Nerd-Bullshit.
Sorry, das musste jetzt einach mal gesagt werden.
Der dir aber auch das gleiche gesagt hat wie ich: so wie dein Code gerade ist kann es nicht funktioniert haben. Und lange Antworten wolltest du ja keine.
Jeder bekommt mal sein Fett weg, aber gehen wir ganz chronologisch vor:
Du stellst eine Frage,
du bekommst konstruktive Kritik,
damit kannst du nicht so richtig umgehen,
du fängst an, die Hilfestellenden zu "beleidigen",
sie regieren darauf mit freundlicher, nüchterner, neutraler Kritik,
du beleidigst sie weiter, und dein Umgangston wird noch "beleidigender",
usw.
Ich gebe zu, ich hab selber deinen Quelltext noch nicht getestet, kann das aber tun, aber ich glaube, das führt zu nix.
Du hast ein Problem und ich habe Dir sogar (vermutlich) eine Lösung gepostet. Wenn es Dir um Sachlichkeit gehen würde, dann würdest Du die Hilfe annehmen und die Lösung einfach einmal ausprobieren.
Aber statt dessen wirst Du beleidigend. Rechtschreibung bringst du an (Zwei mal "file" also f statt F und einmal ein fehlendes Leerzeichen waren wohl die großen Probleme von dir, oder?) und bringst so Dinge wie "Nerd Bullshit".
Und dann erzählst Du hier den größten Bullshit. Etwas, das nicht funktioniert haben kann, soll angeblich gelaufen sein. Den Link zur Dokumentation der Klasse, die dieses Problem aufwirft, hast Du Dir bestimmt auch nicht angesehen, oder?
Es mag sein, dass vieles, was für uns unser täglich Brot ist, für dich nur böhmische Dörfer sind. Clean Code und Co sind für Anfänger schwer zu verstehen. Am Anfang kommt halt doch sehr viel auf einmal auf einen zu. Aber das ändert nichts daran, dass dies auch grundlegende Dinge im Bereich der Softwareentwicklung sind. Diese Hinweise muss man ja aufnehmen. Du kannst weiter so entwickeln, wie Du willst. Das tangiert mich nicht. Du kannst auch im Forum weiter gegen meine Person argumentieren. Das interessiert mich ehrlich gesagt auch nicht. Trotz deiner Art und Weise habe ich Dir dennoch Erläuterungen gepostet und einen alternativen Codevorschlag.
Aber Du solltest einmal genau prüfen, was für Code Du da hast. Es ist sehr wahrscheinlich, dass Du - so der Code wirklich einmal richtig lief - du eine alte Version hast oder so. Und da kann es dann noch ganz andere Probleme geben, die der Compiler evtl. auch nicht anzeigt.
Evtl. schien der Code auch zu laufen - und wenn Du in der IDE den Aufruf gemacht hast, ist die fehlgeschlagen und die IDE hat die letzte kompilierte Version gestartet. Wäre auch noch eine Möglichkeit.
Das sind aber reine Spekulationen und die führen zu nichts. Der Code von Dir wird so NIE gelaufen sein. Glaub es oder nicht. Nimm die Verbesserungen oder oder nicht. Mach es einfach wie Du willst. Aber bitte überleg Dir, ob Deine Art und Weise zielführend ist. Leute, von denen Du Hilfe erwartest dumm anzumachen halte ich für extrem dumm / blöd. Aber das ist auch nur meine Sichtweise.
Also wenns dir hilft kann ich gern auch nochmal bestätigen was hier schon fünfmal gesagt wurde. FileInputStream hatte noch NIE den Konstruktor, den du gesucht hast, da der FileInputStream wirklich nur für das Lesen aus einer Datei verantwortlich ist. Mit Encoding hat der gar nichts am Hut, dafür sind andere Klassen da, wie z.B. die schon erwähnten Reader-Klassen.
Soweit ich weiß wurde auch noch nie eine Funktion aus der Java API entfernt in den letzten 20 Jahren, sondern maximal als "deprecated" markiert.
Du kannst ja gern mal dein kompiliertes, funktionierendes Programm irgendwo hochladen. Wir lassen mal einen Decompiler drüber laufen, dann kann man sehen was du ursprünglich gemacht hast.
Auch den Anmerkungen bezüglich Codequalität kann ich mich nur anschließen. Mag sein, daß das "dein Stil" ist, und du wunderbar mit klar kommst. Aber ich schätze mal du hast auch noch nie in einem größeren Team an einem Projekt gearbeitet. Bei sowas gibts meistens irgendwelche Code-Standards. Denn wenn deine Teammitglieder Zeit verschwenden, deinen Code zu entschlüsseln, kostet sowas bares Geld. Und Dinge wie die erwähnte Redundanz im Code macht dein Programm nicht nur schwerer lesbar, sondern auch fehleranfälliger.
Ich denke mal die meisten die hier geantwortet haben, sind lange genug Entwickler, um da auch aus eigener Erfahrung zu sprechen.
Hinzufügen möchte ich zu @Baldur , das FileInputStream raw byteweise liest, deswegen Encoding nix am Hut. Die ganze API wurde auch so designed, auf welche Art und Weise, denn nun Daten benötigt werden. Meine Rechtschreibung ist auch nicht die Beste, das gebe ich zu. (Viel ins Detail gegangen bin ich auch nicht.)
