Weihnachten mit Debian und Tux

Ganz zufällig beim Essen viel mir heute ein ungewöhnliches Muster auf der dekorativen Weihnachtstischdecke auf. Na, wer entdeckt das Debian Logo? Ich hab direkt noch einen kleinen Schokoladen-Tux-Pinguin dazu gelegt, der auf meinem Weihnachtsteller lag.

Fröhliche Weihnachten mit Linux!

• <name>.jar – ganz klar, das ist die kompilierte gepackte JavaFx-Datei. Überraschend ist, sie unterscheidet sich von der Dateiendung überhaupt nicht von üblichen Java-Dateien – dazu später mehr.
• <name>.html – hier ist schon eine Beispieldatei, die zeigt, wie mans in den Browser einbindet – schön
• <name>.jnlp Auf diese Datei verlinkt man z.B. mit dem orangen Button, den man vielleicht auch schon von Java kennt, wenn man die jar mittels Download einfach starten will. Funktioniert mit JavaFx recht gut (zumindest meine Erfahrung)
• <name>_browser.jnlp – Die wird benutzt, wenn JavaFx direkt embedded im Browser laufen soll.

Netbeans richtet das schon entsprechend ein, wenn man bei project properties auf Run geht. Hier kann man auswählen zwischen:

• standard execution: als normale Desktop-Anwendung
• webstartexecution: Start mit einem Button auf der Webseite
• run in browser: brauch ich nicht weiter kommentieren
• run in mobile emulator: für Mobile Phone Apps und so… (übrigens auch sehr vielseitig in Netbeans)

Außerdem sollte man noch unter application eventuell self signed anklicken und die width und height ändern, falls nötig.

Das war alles? Nein, leider nicht. Wenn man eine ältere Netbeans Version benutzt, kann es passieren, das an mindestens einer Stelle ein / fehlt in der jnlp beim update-tag, es sollte so aussehen:

<update check="background"/>

Keine Ahnung, obs überhaupt Probleme bereitet, aber trotzdem sollte man nach Möglichkeit immer eine aktuelle Version benutzen

Dass man die Dateipfade eventuell in der html-Datei anpassen muss, sobald man die Files uploaded ist natürlich leicht ersichtlich. Leicht vergessen kann man aber Pfade, die noch in den JNLP-Dateien stehen:

<xml version="1.0" encoding="UTF-8"?>
    <jnlp spec="1.0+" codebase="http://meineseite.de/bla/bla/" href="app.jnlp">
    <information>
      <title>Titel</title>
      <vendor>Mein Name</vendor>
      <homepage href="http://meine.seite.de">
      <description>meine tolle App</description>
      <offline-allowed/>
(...)

Hier ist vor allem der Codebase-Tag wichtig, den Homepage-Tag sollte dann gleich mit setzen, und wenn man ordentlich ist über die anderen auch mal drüber schauen (Vendor, Description) – kann nicht schaden.

Vorrausgesetzt man hat das alles erledigt, sollte von der Sever-Seite eigentlich alles funktionieren. Probleme hat man aber trotzdem noch oft genug auf der Client-Seite, was mir so aufgefallen ist:

Windows XP

Normalerweise funktioniert das runterladen des “Browser-Plugins” wie immer recht problemlos, z.B. im Firefox. Wenn man hinter einem Proxy sitzt, siehts aber nicht mehr so gut aus, es wird versucht Zertifikate runterzuladen und lange Zeit passiert nichts, in Java-Konsole findet etwa so etwas:

Reading certificates from 341411 http://dl.javafx.com/javafx-rt-windows-i586__V1.2.0_b233.jar (...)

Dazu gibts auch schon einen Bug-Report.

Linux

Hatte ich auch häufig Probleme, dies bezog sich vor allem auf das Browser-Plugin. Denke das bezieht sich auf alle gängigen Browser. Wenn man Debian oder Ubuntu nutzt, sollte folgendes helfen:

aptitude install sun-java6-plugin

Wem das zu einfach ist, oder wer damit Probleme (verschiedene Java Versionen, Probleme mit 64/32 bit etc.) der kann sich das libjavaplugin_oji.so auch selber zurecht pfuschen, schön dokumentiert bei SUN

OpenSolaris

Ok, saß zufällig an einem OpenSolaris, und dachte mir ich teste es mal. Ich hätte so ziemlich alles erwartet. Aber DAS war echt der Hammer: Nicht mal das Plugin musst ich noch installieren, lief sofort problemlos. Daumen hoch OpenSolaris – ein oft unterschätztes, hochwertiges Betriebssystem. Hoffen wir mal, dass sich das mit Oracle nicht ändert.

java -jar macht ClassNotFoundException

Ja, wie schon oben erwähnt sind die JavaFx-Files ja genau so benannt mit die Java-Files, da ist java -jar aber trotzdem falsch. Am einfachsten ist natürlich die html lokal zu öffnen und dann den Launch dort machen . Richtig desktop-mässig gehts natürlich auch, mit javafx appName.Main – dazu muss natürlich der javafx Path usw. gesetzt sein. Es gibt auch mit ein langes Java-Äquivalent mit java -cp PfadZuJavaFx (…).

deb http://ftp.de.debian.org/debian/ sid main non-free contrib
deb-src http://ftp.de.debian.org/debian/ sid main non-free contrib

Die testing Quellen kann man einfach drin lassen. Als nächstes legt man eine /etc/apt/preferences an (oder editiert sie, falls sie schon existiert):

Package: *
Pin: release a=testing
Pin-Priority: 800
 
Package: *
Pin: release a=unstable
Pin-Priority: 300

Damit sagt man aptitude quasi, dass er Quellen aus Debian testing bevorzugen soll, und nur in Ausnahmefällen aus unstable installiert wird. Also dann noch ein aptitude update und dann den aktuellen Kernel raussuchen, in meinem Fall der 2.6.30er, und installieren. Fertig.
Die sources.lst und so kann man ruhig so lassen. Vielen Dank noch mal an JHR der mir das telefonisch alles so toll erklärt hat!

Mit dieser Release-Politik reagiert man vermutlich auf die immer länger werdenen Releasezyklen. Debian Lenny war ursprünglich für September 2008 geplant, jedoch wurde es erst fast ein halbes Jahr später (Februar 2009)  freigegeben. Schon früher gab es häufiger Kritik, dass Debians stables oft veraltet seien und zu selten neue Releases stattfanden. Hier findet eine Annäherung an die Release Politik von Ubuntu statt, die etwa halbjährlich ein neues Release rausbringen. Debian Anhänger schätzen jedoch im Allgemeinen die längeren Releasezyklen von Debian, wenn hier im Gegenzug Bugs sorgfältiger behoben werden und mehr Stabilität gewährleistet werden kann.

Ich persönlich würde mich zwar freuen, wenn Debian Releases etwas öfter und regelmässiger stattfinden, aber möchte ich dies nicht zum Preis von reduzierter Stabilität haben. Wenn mir die Akutualität so sicher wäre, wäre ich auch schon längst zu Ubununtu gewechselt. Naja, mal sehen was draus wird.

Der Freeze von Debian Lenny wird dann früher stattfinden als geplant, nämlich schon im Dezember diesen Jahres.

EDIT:

In einem Heise Artikel ist inzwischen zu lesen, dass das Debian Team die Mitteilung aufgrund der wachsenden Kritik abgeschwächt hat und die festen Freeze-Zyklen nur noch als Vorschlag versteht, der noch diskutiert werden soll. Naja, irgendwie hab ich mir schon sowas gedacht…