Apache Pivot – Java GUIs Plattformübergreifend

Programmieren an sich ist ja nicht so schwer, sollen die Programme aber auf verschiedenen Plattformen laufen, muss man einige Dinge beachten. Auf der einen Seite muss die Programmiersprache auf allen gewünschten Plattformen unterstützt werden (sprich es muss einen Compiler/Interpreter geben) und es sollten keine Bibliotheken verwendet werden, welche auf “native code” (Code, welcher für ein spezifisches Betriebssystem/CPU programmiert/compiliert wurde) setzen.

Es gibt diverse solcher Sprachen (Python, Java, Ruby, Mono, etc) und jede hat Vor- und Nachteile. Insbesondere wenn man nicht nur Konsolenprogramme schreiben will wird es meistens kompliziert. Frameworks für GUIs arbeiten meist nur auf einem Betriebsystem, da viel betriebsystemspezifischer Code verwendet wird. Deshalb habe war ich schon seit längerer Zeit auf der Suche nach einem GUI Framework, welches dieses Problem löst. Vor ein paar Wochen entdeckte ich “Apache Pivot”.

Apache Pivot ist ein Framework um GUIs für Java zu implementieren, welche auf verschiedenen Plattformen funktionieren. Das GUI wird in einem XML-File definiert. Grundlegende Elemente können so eingefügt werden. Elemente können auch später mittels Java Code hinzugefügt werden. Das Framework funktioniert für normale Programme, Applets und es sollten sich sogar Web-Applikationen erstellen lassen (Die WebApps habe ich aber noch nicht ausprobiert).

Es gibt ausführliche Demos und einfache Beispiele zu allen Komponenten.

Die Java-Programme funktionieren auf Windows, Mac OS X und Linux (im Grunde überall wo eine grafische Oberfläche vorhanden ist und Java unterstützt wird). Die Performance ist sowohl auf Windows als auch auf Mac OS X gut (Linux habe ich nicht so ausführlich getestet). Wenn nicht so sauber programmiert wird reagieren die Programme speziell unter Windows nicht ganz so schnell. Insbesondere bei Buttons, wenn grössere Aktionen ausgeführt werden sollen, muss diese in einem neuen Thread gestartet werden. Wenn da Fehler passieren, reagiert das GUI träge.

Alles in allem gefällt mir das Framework, es ist schnell, einfach zu benutzen und man kann es in bestehende Programme Integrieren (und so langsam zum Beispiel ein SWING-Interface durch Apache Pivot ersetzen).

 

JNLP – Anwendung kann nicht gestartet werden [Lösung]

Kürzlich hatte ich folgendes Problem:
Ich benutzte eine Java WebStart-Applikation (schon seit längerer Zeit) und von einem Tag auf den anderen konnte das Programm nicht mehr gestartet werden.
Ich erhielt folgende Fehlermeldung:
Anmeldung kann nicht gestartet werden
- Nicht signierte Anwendung fordert uneingeschränkten Zugriff auf das System an
- Nicht signierte Ressource: https://....../asdm.jnlp

Oder Falls man eine englische Anwendung startet:


jnlp: Unable to launch the application
- Unsigned Application requesting unrestricted access to system
- Unsigned resource: https://....../asdm.jnlp

In diesem Fall war es das Konfigurations-Tool einer Cisco Firewall (Cisco ASDM – Adaptive Security Device Manager).
Erstaunlicherweise trat dieses Problem mehr oder weniger zeitgleich auf mehreren PCs auf. Der Grund dafür war ein Problem mit dem Java-Cache (und wahrscheinlich einem Java-Update). Auf jeden Fall löst sich das ganze von alleine wenn man den Java-Cache leert. Eine Anleitung dazu wird auf der Homepage von Java/Oracle zur Verfügung gestellt.

Diese ist allerdings nur für Windows und auf Englisch, deshalb hier eine kurze Zusammenfassung:

Lösung für Windows

  1. Das “Java Control Panel” öffnen.
    • Systemsteuerung -> “Java”
  2. Es sollte sich nun ein Fenster geöffnet haben mit drei Unterteilungen. Bei “Temporäre Internet-Dateien” den Button “Einstellungen…” anklicken
  3. Im neuen Fenster den Button “Dateien löschen” anklicken.
  4. Mit “Ok” bestätigen.

Lösung für Mac

  1. Spotlight: Java-Einstellungen
    • Es öffnet sich nun ein Fenster mit 4 Tabs
  2. Das Tab “Netzwerk” anwählen
  3. Den Button “Dateien löschen” anklicken
  4. Mit “Ok” Bestätigen

 


Hudson – Continiuous Integration

Nachdem wir nun unser “Semester-Projekt Part I” beinahe abgeschlossen haben, habe ich mir “Hudson” nochmals genauer angeschaut und mal ausprobiert. Für Java-Projekte, und insbesondere Web-Projekte (welche mit Java implementiert werden) eigent sich Hudson hervorragend. Hudson wurde selber in Java programmiert und benötigt einen “ServletContainer” (eine Art (Web-)Server, welcher das Java-Webapp ausführt). Ich habe mich für Tomcat entschieden, da wir Tomcat auch für die Entwicklung unseres Projektes verwenden und die Installation von Hudson beinahe null Aufwand mit sich bringt.

Was macht nun dieses “Hudson” genau? Beim Programmieren eines Webprojektes möchte man immer mal wieder testen ob alles funktioniert, ob alte Bugs repariert sind und ob sich evtl. neue Bugs eingeschlichen haben. Vorallem wenn auch Nicht-Programmierer an diesem Prozess beteiligt sind, muss das ganze Projekt auf einem Testserver eingerichtet werden und für die Tester zugänglich sein. Dabei muss bei jeder Änderung das Projekt kompiliert und übertragen werden. Hudson übernimmt nun diesen Teil. Der Quelltext wird von der Versionsverwaltung geholt, kompiliert und alles es keine Fehler gibt eingerichtet. Zusätzlich können Test-Mechanismen wie JUnit oder TestNG eingebunden werden. Entwickler können (falls gewünscht) direkt benachrichtigt werden, falls das Kompilieren fehlschlägt, usw.

Hudson kann auch mit anderen Programmiersprachen als Java umgehen und ist nicht nur auf Webprojekte beschränkt. Die Konfiguration ist sehr flexibel gestaltet und alles ist durch Plugins erweiterbar. Dies führt leider auch zu einer gewissen Komplexität. Für sehr kleine Projekte wird der Aufwand für die Konfiguration wohl beinahe ein bisschen zu gross. Ausserdem muss sich auf dem Server ein Compiler, und alles weitere befinden um das Projekt zu kompilieren und das ist für die Sicherheit des Server nicht unbedingt optimal. Weiter muss man den Beteiligten am Projekt bis zu einem gewissen Grad vertrauen können, denn diese können mit Änderungen am Code relativ viel Unfug anstellen auf dem Server. Meiner Meinung nach fehlt das “Sandboxing” ein wenig. Kann man mit diesen Nachteilen leben, macht Hudson das Leben der Programmierer um einiges leichter und beschleunigt die Arbeitsabläufe.

Viel Spass beim ausprobieren:

Tomcat6, Java, JDBC4, eine MySQL-Datenbank und “Communications link failure”

Damit uns der Einstieg in unser Semester-Projekt nicht so schwer fällt haben wir eine Muster-Anwendung inklusive Anleitung bekommen. Wir benutzen Java und wollen eine Web-Anwendung schreiben. Als Web-Server benutzen wir Tomcat6 und für die Datenbank MySQL.

Soweit so gut. VirtualBox war schon installiert, Ubuntu in ein paar Minuten heruntergeladen und kurze Zeit später lief mein Developpement-System. Tomcat6, JDK, eclipse, MySQL, etc waren schnell installiert und alles lief super. Die Homepage wurde angezeigt… und als ich mich “Registrieren” wollte:

com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.

Vollständige Fehlermeldung: http://bin.esheep.ch/2

Mit dem Befehl:

telnet localhost 3306

Konnte ich zum Server verbinden, Die Datenbank war also erreichbar. Ich prüfte die Konfiguration der Datenbank. Der Benutzer war korrekt eingerichtet, die Tabelle vorhanden (alles korrekt und so wie es in der Anleitung stand). Schlussendlich lag der Fehler daran, dass zwar die Datenbank erreichbar ist, jedoch Tomcat die Registrierungs-Anwendung nicht verbinden lies. TCP-Verbindungen sind mit den Default-Einstellungen vebroten.

Mit folgendem Befehl kann das init-Script geöffnet werden:

sudo EDIT /etc/init.d/tomcat6

Da muss anschliessend die Zeile “TOMCAT6_SECURITY=yes” gesucht und durch “TOMCAT6_SECURITY=no” ersetzt werden. Falls vorhanden, muss das Kommentarzeichen vor der Zeile entfernt werden.

Anschliessend Tomcat neu starten:

sudo /etc/init.d/tomcat6 restart

Viel Spass mit Tomcat, Java und MySQL 😉