Desktop-Api: Problem mit open() und Umlauten

[Daniel_L]

Hallo,

kann es sein, dass die Desktop-Api keine Umlaute kennt? Ich habe folgenden Code (Ausschnitt):

// check whether opening a file is supported or not
if (!desk.isSupported(Desktop.Action.OPEN)) {
  // display error message box
  JOptionPane.showMessageDialog(getFrame(),getResourceMap().getString("errLinkUnsopportedMsg"),
         getResourceMap().getString("errLinkUnsopportedTitle"),JOptionPane.ERROR_MESSAGE);
  return;
  }
desk.open(linkfile);

Wenn ich eine Datei ohne Umlaute habe, öffnet er sie problemlos. Sobald ich aber diese Datei umbenenne und sie einen Umlaut erhält, kommt es beim Versuch, die Datei zu öffnen, zu folgender Fehlermeldung:

Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException:
Non-Java exception raised, not handled!
(Original problem: *** -[NSCFArray initWithObjects:count:]:
attempt to insert nil object at objects[0]) 

at apple.awt.CDesktopPeer._lsOpen(Native Method) 
at apple.awt.CDesktopPeer.lsOpen(CDesktopPeer.java:53) 
at apple.awt.CDesktopPeer.open(CDesktopPeer.java:33) 
at java.awt.Desktop.open(Desktop.java:254) 
at zettelkasten.ZettelkastenView.eventHyperlinkActivated(ZettelkastenView.java:9609) 
at zettelkasten.ZettelkastenView.access$6000(ZettelkastenView.java:119) 
at zettelkasten.ZettelkastenView$14.hyperlinkUpdate(ZettelkastenView.java:7014)

Den oben geposteten Code-Ausschnitt habe ich mit try/catch umgeben und fange eigentlich alle Exceptions ab:

            catch (IOException e) {
            catch (IllegalArgumentException e) {
            catch (SecurityException e) {
            catch (UnsupportedOperationException e) {
            catch (URISyntaxException e) {

Die Pfadangabe ist ganz sicher nicht falsch, da ich die Datei mit einem FileChooser öffne - außerdem wäre dann ja eine der oben abgefangenen Exceptions aufgetreten.

Das Problem taucht nur auf, wenn ich eine Datei mit Umlaut auswähle...

Ich selber nutze Mac OS X 10.5.5 mit Java 6, aber das Problem tauchte auch schon auf einem Linux-System auf (vermutlich auch da wird es an den Umlauten gelegen haben...)

Weiß jemand Rat?

Vielen Dank und Gruß
Daniel

 

[Ebenius]

Das konnte ich bisher nicht nachvollziehen. Ich gehe davon aus, Du hast die Datei vor "desktop.open(linkfile);" schon einmal ausgeben...

 

[Ebenius]

Jetzt hab ich's probiert und kann es auf meinem Linux nachvollziehen... :cry: Habe in der Shell zwei Dateien angelegt:

cd /home/ebenius
echo "Huhu" > a
echo "Huhu" > ä

Mein Java Code legt diese File-Objekte an:

final File dir = new File("/home/ebenius");
final File file1 = new File(dir, "a");
final File file2 = new File(dir, "doesnt_exist");
final File file3 = new File(dir, "ä");

Folgende Tests hab ich gemacht:

1. :toll: File Browser öffnen funktioniert bestens:

Desktop.getDesktop().open(dir);

2. :toll: File "a" öffnen funktioniert bestens:

Desktop.getDesktop().open(file1);

3. :toll: File "doesnt_exist" öffnen funktioniert nicht; wie erwartet:

Desktop.getDesktop().open(file2);

Exception in thread "main" java.lang.IllegalArgumentException: The file: /home/ebenius/doesnt_exist doesn't exist.
at java.awt.Desktop.checkFileValidation(Desktop.java:191)
at java.awt.Desktop.open(Desktop.java:252)
at com.ebenius.A.main(A.java:263)

4. :bloed: File "ä" öffnen funktioniert nicht:

Desktop.getDesktop().open(file3);

Exception in thread "main" java.io.IOException: Failed to show URI:file:/home/ebenius/ä
at sun.awt.X11.XDesktopPeer.launch(XDesktopPeer.java:75)
at sun.awt.X11.XDesktopPeer.open(XDesktopPeer.java:43)
at java.awt.Desktop.open(Desktop.java:254)
at com.ebenius.A.main(A.java:263)

System-Informationen:
GNU/Linux / SuSE 10.3

$ uname -a
Linux steevie 2.6.22.18-0.2-default #1 SMP 2008-06-09 13:53:20 +0200 x86_64 x86_64 x86_64 GNU/Linux

$ java -version
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)

$ X -version

X Window System Version 7.2.0
Release Date: Tue Jun  3 00:06:06 UTC 2008
X Protocol Version 11, Revision 0, Release 7.2
Build Operating System: openSUSE SUSE LINUX
Current Operating System: Linux steevie 2.6.22.18-0.2-default #1 SMP 2008-06-09 13:53:20 +0200 x86_64
Build Date: 03 June 2008
        Before reporting problems, check [url]http://wiki.x.org[/url]
        to make sure that you have the latest version.
Module Loader present

Habe die Sun Bug Database mit "desktop.open" durchsucht. Gibt ein paar Bugs die in die Richtung gehen. Aber mir scheint's nicht das Problem zu treffen. Machst Du nen Bug Report, bzw. suchst nochmal selber?

Ebenius

 

[Spacerat]

Ganz Gallien? Oh sorry... falscher Film...

Aber mal Scherz beiseite. Du fängst da möglicherweise nur die Exceptions ab, die dir von der IDE her vorgeschlagen werden. Die Exception die dort geworfen wurde ist eine "RuntimeException". Exceptions dieser Art werden eigentlich für die JRE geworfen, wo sie letztenendes auch abgefangen werden. Deswegen benötigen sie auch keine "throws"-Klausel in der Methodendeklaration.
Das Problem mit den Umlauten lässt den schluss zu, das Codepage der Anzeige nicht mit jener des Dateisystems übereinstimmt. Die meisten Betriebssysteme trennen die Codepages der Anzeige von denen der Dateisysteme, um den Import von fremden Dateisystemen zu ermöglichen. Hier kann man für beides auch durchaus verschiedene Werte setzen. Die Vor- und Nachteile der Einbindung eines Dateisystems mit "falscher" Codepage (sprich verschiedene Werte zu setzen) sind aber eher fragwürdig als hilfreich, wie man hier sieht.

mfg Spacerat

 

[Ebenius]

Ganz Gallien? Oh sorry... falscher Film...

Hab alle Einträge gelesen die bei "desktop.open" kommen; ich glaube es waren 14.

Das Problem mit den Umlauten lässt den schluss zu, das Codepage der Anzeige nicht mit jener des Dateisystems übereinstimmt. Die meisten Betriebssysteme trennen die Codepages der Anzeige von denen der Dateisysteme, um den Import von fremden Dateisystemen zu ermöglichen. Hier kann man für beides auch durchaus verschiedene Werte setzen. Die Vor- und Nachteile der Einbindung eines Dateisystems mit "falscher" Codepage (sprich verschiedene Werte zu setzen) sind aber eher fragwürdig als hilfreich, wie man hier sieht.

Mein System ist vollständig UTF-8. Und außerdem muss das egal sein, ich in der Java-Desktop-API ein File-Objekt übergebe, welches per File.exists() existiert.

Ebenius

 

[Daniel_L]

Ich überprüfe vorher bereits, ob die Datei existiert und habe die Methode auch schon Schritt-für-Schritt debugged. File.exists() gibt true zurück, desktop.open() wirft diese Exception.

Unter Linux (KDE) scheint es noch zusätzliche Probleme zu geben:
http://forums.sun.com/thread.jspa?threadID=5336551

Ich werde mal weiter recherchieren und wenn ich nichts finde, einen Bug-Report eröffnen, denke ich...