Skip to content

Ärger mit Java

Also eigentlich bin ich ja großer Fan von Java, aber in letzter Zeit gab es so einiges was mich fast zur Weißglut getrieben hätte.
Da wäre zum einen ein Problem mit dem Classpath: denn normalerweise kann man selbigen bequem mit der Option "-cp" oder "-classpath" setzen. Ich hab absichtlich das Wort "normalerweise" gewählt, weil es eben doch nicht immer geht.
Denn wenn man ein Programm in ein jar packt und das dann mit "java -cp lib/other.jar -jar bla.jar" ausführen will, dann wird er mit einer wunderschönen NoClassDefFoundException auf die Schnauze fallen. Denn, was ich nach langer Suche im Internet erfahren musste: bei jar-Dateien wird die Option -cp bzw. -classpath immer ignoriert. Stattdessen wird als Classpath nur das genommen, was auch im Manifest definiert ist.
Nicht, das man das dem Benutzer mitteilen könnte - nein! Wo ist denn das verdammte Problem, bei gleichzeitiger Verwendung der Option "-jar" und "-cp" eine Warnung auszugeben, das diese Verwendung unzulässig ist? Ich meine, selbst mit verbose Ausgabe erhält man keinerlei Hinweis darauf.
Usability: 6 - setzen!

Ach ja: wie man das Problem umgeht: die Option "-jar" weglassen, das betreffende jar in den classpath mit aufnehmen und dann den vollen Pfad zur Klasse mit der main-methode angeben. Etwa so: "java -cp lib/other.jar:bla.jar de.leckmich.Main"

Aber da ist noch ein Thema, was noch viel mehr zum Kotzen ist, weil es nämlich dafür keinen Workaround gibt: Mit Java 6 funktioniert das Drucken unter Linux nicht mehr! Gar nicht!!!!
Zum einen, weil seit Cups 1.2 als Host ein Socket angegeben ist mit dem Java nicht umgehen kann (was nicht ganz so schlimm ist, weil man das in der Config, oder per Umgebungsvariable auf localhost ändern kann), zum anderen aber, weil seit Java 6 kein valides Postscript mehr erzeugt wird (d.h. valide soll es angeblich schon sein - es wird nur von keinem Programm unterstützt). Das führt dann dazu, das sich GhostScript mit einem "Error: /configurationerror in --setpagedevice-" verabschiedet.
Und was dem ganzen noch die Krone aufsetzt: der Fehler ist seit über einem halben Jahr bekannt und noch immer nicht behoben!!

Die einzige Möglichkeit das zu Umgehen, wäre: auf Java 5 zurück zu migrieren. Wenn man allerdings eine Swing-Anwendung hat, die auf das neue GroupLayout aufsetzt, dann hat man es schon reichlich schwerer! Wenn man dann noch diverse andere neue Features von Java 6 verwendet, dann hat man völlig die Arschkarte gezogen!

Und wie soll ein Unternehmen, welches Anwendungen auf Java/Swing-Basis verkauft, es seinen Kunden erklären, das sie auf einmal nicht mehr drucken können? Der durchschnittliche Endkunde ist doch froh, wenn er bei seinem Rechner den Knopf zum an- und ausschalten findet. Der wird es niemals verstehen, sondern die Schuld auf das Programm schieben!

In diesem Fall muss man aber wirklich die Schuld auf Sun schieben. Und womit? Mit Recht!

Drachenboot besiegt bash

Nachdem ich nun wochenlang nichts neues zu berichten wusste, ist es nun mal wieder Zeit für einen neuen Eintrag.
Am Wochenende, genauer gesagt am Samstag, war das Drachenboot-rennen im Medienhafen. Unsere Firma hatte dieses Jahr zum ersten mal daran Teil genommen, und angesichts der Tatsache, das wir quasi noch Anfänger waren und auch das Wetter gegen uns war, kann man unsere Platzierung auf dem 15. Platz (bei 40 Teilnehmern) durchaus als Erfolg werten!

Das Wetter an sich war eigentlich nicht schlecht - nur dumm, dass es immer genau dann geregnet hat wenn wir am paddeln waren. Und um das ganze noch zu toppen, hat es natürlich pünktlich wenn wir fertig waren wieder aufgehört. Das ganze erinnerte mich an diverse Cartoons, wenn die kleine Regenwolke genau über dem Kojoten steht und ihn verfolgt.
Wir haben schon mit dem Gedanken gespielt, den Namen unseres Teams nächstes Jahr in "Gewitterfront" zu ändern.

So und um dem Thema dieses Blogs noch gerecht zu werden: ein kleiner Exkurs darüber, das auch die bash beschissen sein kann!
Die Problemstellung war diesmal: alle Verzeichnisse in einem bestimmten Verzeichnis durchgehen und gucken ob eine Datei mit einem bestimmten Namen darin liegt.
Klingt einfach? Im Grunde ja, aber... nun gut, gehen wir der Reihe nach.
Mein erster Ansatz war natürlich jener hier:
for g in `ls -1b ${directoryName}`
do
  # Verzeichnis checken
done

Zur Erläuterung: die optionen -1 und -b von ls bewirken, das jede Datei auf einer extra Zeile ausgegeben wird, und das Leerzeichen escaped werden. Man sollte annehmen, dass das funktioniert - tut es aber nicht!
Wenn man in ${directoryName} ein Verzeichnis "ein verzeichnis" hat (man beachte das Leerzeichen), dann wird er die Schleife einmal für "ein" und einmal für "verzeichnis" durchlaufen! Auch wenn man dem ls die Option "-Q" übergibt, welche dafür sorgt das die Ergebnisse gequoted werden, ändert das nichts daran.

Es gibt auch keine Möglichkeit in irgendeiner Form zu definieren, das die for-schleife nur noch linebreaks und keine Leerzeichen als Separator benutzen soll.
Und so blieb mir nur die Möglichkeit mich zu ärgern, und das ganze wie folgt um zu schreiben:
`ls -1b {directoryName} > temporaryList.txt`
while read g
do
  # das selbe wie oben
done < temporaryList.txt

Das ist natürlich reichlich unschön, weil man hier eine temporäre Datei anlegen muss, aber scheinbar der einzige Weg.

Nachtrag
Wie ich später heraus fand, ist das durchaus nicht der einzige Weg.
Mit einem Kniff geht es auch ohne temporäre Datei:
while read g
do
  echo "$g";
done < <(ls -1b /path/to/target)

Wichtig ist dabei das Leerzeichen zwischen den beiden '<' - das sorgt dafür, dass man quasi eine Art virtuelle, temporäre Datei hat, von der aus gelesen wird.