java.io-Änderungen zwischen java 1.4 und 1.6

[Andreas29]

Hi Leute,

ich habe eine kurze Frage:
Hat sun etwas an den Standard java.io-Klassen von Version 1.4 nach Version 1.6 geändert? Ich habe hier ein Programm, das mit java 1.4 problemlos läuft und nach einem Java Update auf 1.6 Fehler schmeißt. Jemand eine Idee, was sich da geändert hat?

Danke für eure Hilfe und Grüße,
Andreas

 

[ARadauer]

http://java.sun.com/javase/6/webnotes/ReleaseNotes.html

wie lauten den die fehler? die sind meist sehr hilfreich...

 

[Andreas29]

Der Fehler ist eine IOException, die geworfen wird, wenn mein Applet über File.createTempFile(String, String) eine neue Datei anlegen soll. Das Applet ist signiert und darf somit auf die Festplatte des Benutzers zugreifen. Woher kommt dann die IOException?
Trace:
java.io.IOException: Das System kann den angegebenen Pfad nicht finden
at java.io.WinNTFileSystem.createFileExclusively(Native Method)
at java.io.File.checkAndCreate(Unknown Source)
at java.io.File.createTempFile(Unknown Source)

Diese kommt wirklich nur, wenn ich den Code unter java 1.5 oder höher ausführe...

Grüße,
Andreas

 

[tuxedo]

Wäre natürlich interessant zu sehen wie der Pfad aussieht und ob es diesen wirklich gibt?!

Kannst du das mal an der stelle debuggen oder eine Ausgabe in der Console machen?!

- Alex

 

[Andreas29]

Hi Leute,

die Pfade sind verfügbar. Sonst könnte dasselbe Programm unter Java 1.4 die Pfade auch nicht verwenden... Das ist sichergestellt.

Aber danke für deine Hilfe.

Grüße,
Andreas

 

[tuxedo]

Vielleicht wird ja, aus welchen Gründen auch immer, der Pfad falsch zusammengesetzt?
Debuggen hat, im Vergleich zu Tipps/Vorschläge von vornherein ausschließen, noch nie geschadet ...

- Alex

 

[Andreas29]

Hi,

okay, wenn ich es prüfen soll, erkläre mir bitte, wieso das Programm mit nicht vorhandenen Pfaden unter Java 1.4.2 ohne Probleme läuft und bei Verwendung von java 5 oder höher zusammenbricht. Wie gesagt, das Applet wurde nicht geändert, nicht neu kompiliert gar nichts damit gemacht. Es wurde lediglich die Javaumgebung, die das Applet ausführt, aktualisiert. Dies schließt für mich fehlerhafte Pfade oder ähnliches aus, weil kein Programm und keine Javaversion eine Datei in einem nicht vorhandenen Verzeichnis erstellen kann. Hoffe du bist mir nicht böse, wenn ich das so schreibe, aber ich war davon ausgegangen, dass eigentlich klar sein sollte, das solche Fehler nicht in Frage kommen, da ich schon geschrieben habe, das sich nur die Javaumgebung und sonst nichts geändert hat.

Grüße,
Andreas

 

[tuxedo]

>> wenn ich es prüfen soll

Du musst nix prüfen. War nur ein Ratschlag. Mach es, oder lass es. Mir völlig Schnuppe.

>> Hoffe du bist mir nicht böse ...

Nö, wärst nicht der erste der ohne zu debuggen gleich alles ausschließen will ...

>> das solche Fehler nicht in Frage kommen

Wie? Jetzt entscheidest du ob Fehler in Frage kommen oder nicht? Weiß das die JVM auch? Wenn nicht solltest du ihr Bescheid sagen. Vielleicht handelt es sich um ein Kommunikationsproblem?

>> das sich nur die Javaumgebung und sonst nichts geändert hat

Und genau da liegt der Hund begraben. Ich denke es ist nicht allzuweit phantasiert, dass die Möglichkeit besteht, dass durch irgend welche Seiteneffekte ein String nicht der ist, der er sein sollte. Weil: Die JVM sagt ja nicht zum Spass "java.io.IOException: Das System kann den angegebenen Pfad nicht finden"

Wenn du den Fehler finden willst, dann wirf deinen Debugger an. Wenn nicht, mutmaße halt weiter bis die Lösung vom Himmel fällt. Schneller bist du vermutlich wenn du selbst nachschaust. Frei nach dem Motto: Wenn man nicht alles selber macht *seufz*

Ich klink' mich dann mal aus bis weitere Details auftauchen und nicht noch mehr "kategorisch ausgeschlossen wird", von dem die JVM nix weiß ...

Gruß
Alex

 

[Landei]

Ich klink mich dann mal aus bis weitere Details auftauchen und nich nochmehr "kategorisch ausgeschlossen wird", von dem die JVM nix weiß ...

Der kategorische Exklusiv - Kant wäre begeistert!

 

[Andreas29]

Hi Leute,

ich entscheide nicht, ob ein Fehler kommt oder nicht oder irgendwelchen anderen Schwachsinn. Ich habe nur ein simples Applet, das erstens signiert ist und zweitens eine Datei anlegen soll. Um nicht vorhandene Pfade auszuschließen, habe ich die Verzeichnisse im Explorer angelegt und den Pfad aus der Adressleiste des explorers über die Zwischenablage in die zwei Anführungszeichen meines ersten Parameters der createFile() Methode kopiert. Dies sollte nach besten Wissen und Gewissen das nicht vorhandensein von Verzeichnissen ausschließen.
Soviel dazu.
So, was ich eigentlich nur wissen möchte, ist folgendes:
Gibt es seid der Java-Version 1.4.2 betreffens der io-Packages irgendwelche Änderungen (vielleicht im SecurityManager oder sonst wo), die es einer Java 1.4.2 Umgebung (in der diese Änderung noch nicht drin ist) erlauben, die Datei anzulegen und es einer neueren Java-Version (in der diese Änderung enthalten ist) dies eben verbieten. Nicht mehr und nicht weniger.

Grüße,
Andreas

PS: Wieso ist es eigentlich zuviel verlangt, zu glauben, das die Pfade vorhanden sind, wenn ich als der Thread-Erzeuger und einziger hier, der das wirklich beurteilen kann, sage? Oder anders ausgedrückt:
Was bringt es mir, über die Zeile:
File myXmlFile = File.createTempFile("TestFileName",".xml", new File("C:/temp/")); rüberzudebuggen, wenn ich im explorer sehe, das das Verzeichnis C:/temp vorhanden ist?

 

[musiKk]

Die IOException sagt nicht, dass der Pfad nicht existiert, sondern dass das File nicht erstellt werden konnte. Ich weiß jetzt nicht, obs was bringt, da weiter in den Stacktrace zu gehn. Bei mir funktioniert diese Zeile an sich jedoch tadellos.

Ich kenne mich mit Applets signieren nicht im Geringsten aus, darum rate ich mal ins Blaue, dass man beim Versionssprung neu signieren muss. Bitte ignorieren, wenns nicht passt.

 

[Wildcard]

Wo ein temp file angelegt wird, hängt vom Property java.io.tmpdir ab. Wenn das in deiner Installation/Programm verbogen ist, wäre die angegebene Exception eine mögliche Folge.

 

[musiKk]

Das Property wird aber nur verwendet, wenn man kein Verzeichnis angibt, was hier aber geschieht.

 

[FArt]

PS: Wieso ist es eigentlich zuviel verlangt, zu glauben, das die Pfade vorhanden sind, wenn ich als der Thread-Erzeuger und einziger hier, der das wirklich beurteilen kann, sage? Oder anders ausgedrückt:
Was bringt es mir, über die Zeile:
File myXmlFile = File.createTempFile("TestFileName",".xml", new File("C:/temp/")); rüberzudebuggen, wenn ich im explorer sehe, das das Verzeichnis C:/temp vorhanden ist?

Bei dieser Art von Fehlern ist die Wahrscheinlichkeit hoch, dass der Fehler davor sitzt. Die meisten unerklärlichen Probleme kommen durch falsche Annahmen. Warum ist es vom Forum zu viel verlangt, wenn der Fragende vorher alle übernatürlichen Probleme wie "Inkompatibilitäten in der JRE" durch Debugging ausschließt, schließlich ist der der einzige, der das beurteilen und durchführen kann.

Tu was, um dein Problem zu lösen. Lies die Releasenotes und beurteile die Sachlage. Du kannst deine Erkenntnisse gerne hier posten und diskutieren, das hier ist nämlich ein Diskussionsfourm, wenn es sich auch manchmal etwas anders anfühlt. Erwarte keine fertige Lösung. Folge dem Link in meiner Signatur.

 

[tuxedo]

>> Bei dieser Art von Fehlern ist die Wahrscheinlichkeit hoch, dass der Fehler davor sitzt. Die meisten unerklärlichen Probleme kommen durch falsche Annahmen. Warum ist es vom Forum zu viel verlangt, wenn der Fragende vorher alle übernatürlichen Probleme wie "Inkompatibilitäten in der JRE" durch Debugging ausschließt, schließlich ist der der einzige, der das beurteilen und durchführen kann.

Genau das hab ich versucht klar zu machen... ;-) Vielleicht hast du, FArt, die besseren Worte gefunden. Mal sehen ob es diesmal fruchtet.

Gruß
Alex

 

[Guest]

Hi Leute,

ihr habt mir leider immer noch nicht die Frage beantwortet, was es mir bringt, im debugger über die besagte, unter Verwendung von Java 1.5 Fehler verursachende Zeile rüberzulaufen, wenn ich im parallel neben meiner Enticklungsumgebung laufenden Windowsexplorer sehen kann, das das Verzeichnis existiert. Diese Frage möchte ich jetzt unabhängig von Error 40 (The error is placed 40cm in front of the keyboard ) Möglichkeit von euch erklärt haben. Wie kann "c:/temp" im debugger scheinbar anders aussehen oder auf etwas anderes zeigen als auf c:/temp??? Mehr als hard verdrahten kann ich die Werte nicht. Logisch ist, das das spätere Programm diese Werte woanders herbekommt, aber solange es mit den fest verdrahteten Werte nicht funktioniert wird es mit dynamischen Werte auch nicht gehen, denn soviel steht fest:
Der Methode newTempFile ist es scheiß egal, ob die Strings hart verdrahtet übergeben werden, aus einer Propertiesdatei oder Datenbank oder sonst wo her stammen.

Grüße,
Andreas

PS: Eins habe ich jetzt gelernt: Um solche, vollkommen sinnlosen Diskussionen hier in Zukunft zu vermeiden, werde ich einfach schreiben: Habe im Debugger nachgeschaut, der fest zwischen zwei Anführungszeichen stehende String hat tatsächlich den Wert, der zwischen den Anführungszeichen steht... Scheinbar ist es doch ein wenig viel verlangt, zu glauben, das der String "C:/temp" so an eine Funktion übergeben wird...

 

[FArt]

Was hilft der Debugger?
Ganz einfach: ich kann mir das gebildete File-Objekt ansehen. Kann mal schnell so Aufrufe wie isFile(), isDirectory(), canRead(), canWrite(), getCannonicalPath() usw. auf das Objekt aufrufen. Schließlich muss dein "hard verdrahteter" Pfad in eine gültige URI gemappt werden.

Das wird vermutlich den wichtigen Fingerzeig bringen.

Merkst du was? Annahmen und Beweis, das sind zwei Paar Stiefel.

Auch wenn du schreibst "Hab im Debugger nachgeschaut" wird dich das nicht weiter bringen.. denk mal darüber nach wieso...

[EDIT]
Beim Debuggen fallen einem auch oft ganz banale Fehler auf, wie z.B. der Versuch Daten in ein Verzeichnis anstatt in ein File schreiben zu wollen usw.

 

[tuxedo]

Vielleicht ist es auch hilfreich, ein kleines Sample zusammenzustricken, mit dem der Fehler reproduzierbar ist. Dann können noch mehr Leute sich dem Problem detailiert annehmen.

- Alex

 

[Guest]

Mal was anderes...

System.out.println(System.getProperty("os.name"));
System.out.println(System.getProperty("java.version"));
File myXmlFile = File.createTempFile("TestFileName", ".xml", new File("C:/temp/"));
System.out.println(myXmlFile.toString());

gibt bei mir:
Windows XP
1.6.0_03
C:\temp\TestFileName60245.xml

-> der Fehler liegt nicht an Java allgemein, sondern bei dir an was anderem.

Franco