• <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 (…).

Systems and/or methods are described that enable a user to elevate his or her rights. In one embodiment, these systems and/or methods present a user interface identifying an account having a right to permit a task in response to the task being prohibited based on a user’s current account not having that right.

Na… das is doch sudo! Oder sudo mit ner GUI, dann halt kdesu oder gksudo! Hätte ichs nicht selber gesehen, ich würds mal wieder für einen Scherz halt. Aber diese Trivialpatente sind langsam echt nich mehr zu lachen. Sudo benutzt Linux schon seit Jahrzehnten – und Microsoft verkaufts quasi wieder als eigene, neue Idee?

Kurios ist auch, dass (wie ich in auf der zitierten Seite nachlesen konnte) es angeblich früher ein ähnliches Linux-Tool namens runas gegeben hat, und auch genau den gleichen Namen trägt wie das Microsoft-Tool zu dem das Patent gehört.

Tja, wie soll man bei den Trivialpateten  noch glauben können, dass das Patentwesen dazu dient Inventionen zu fördern?

Ports in Windows XP freigeben: Systemsteuerung -> Windows Firewall -> Ausnahmen -> Port TCP 16001 und beliebigen Namen eingeben, fertig.

Nun ist es an der Zeit, auf der neuen ntfs-Partition ganz normal das zweite Windows XP zu installieren. Dadurch wird natürlich die alte Windows-Partition erstmal nicht mehr bootbar. Nachdem man da alles soweit installiert und eventuell upgedated hat, bootet man erneut mit einer Live-CD, der nächste Schritt ist die Installation von grub.

Die folgenden Aktionen sind als root-user bzw. mit sudo durchzuführen. Zunächst wird die ca. 100 MB große ext3-Partition (in diesem Beispiel sda4) gemountet:

mkdir /mnt/tempgrub
mount /dev/sda4 /mnt/tempgrub

und anschließend grub installiert:

grub-install --root-directory=/mnt/tempgrub/ /dev/sda4

Nun muss noch eine menu.lst angelegt werden in /mnt/tempgrub/boot/grub/ – mit Einträgen in etwa so:

timeout 60
default 0
 
title Windows XP - I
unhide (hd0,0)
hide (hd0,1)
rootnoverify (hd0,0)
makeactive
chainloader +1
 
title Windows XP - II
unhide (hd0,1)
hide (hd0,0)
rootnoverify (hd0,1)
makeactive
chainloader +1

Wobei (hd0,x) jeweils für x-te Partition steht (bei sda muss man immer eins dazuzählen). hide und unhide verstecken die jeweilige andere Windows-Partition, die grad nicht genutzt wird. Besonders acht sollte man auf Leerzeichen zwsichen hide und (hda..) geben, sonst gibts Fehler in der Form:

Grub Error 13: "Invalid or unsupported executable format"

Zur Sicherheit noch einmal wiederholen, damit auch grub up to date ist:

grub-install --root-directory=/mnt/tempgrub/ /dev/sda4

Und beim nächsten Reboot sollte man dann in der Lage sein, zwischen den beiden Windows XP Partitionen zu wählen. Das ganze sollte auch mit Windows Vista funktionieren – wobei Vista -afaik- nen eigenen bootloader hat, damit sollte es natürlich auch schon so gehen.