Java auf dem Desktop? Echt jetzt?

 Java, Swing  Kommentare deaktiviert für Java auf dem Desktop? Echt jetzt?
Jan 142015
 

Wie oft haben wir es gehört – der Desktop ist tot, der Browser ist die Plattform der Zukunft, und Java ist auf dem Client sowieso tot und existiert nur auf dem Server.

JSR 377 heißt die Überraschung offiziell. Mindestens zwei der Beteiligten sind keine Unbekannten in der Java-Welt: Andres Almiray und Hendrik Ebbers. Letzterer hat hier darüber gebloggt.

Ich bin gespannt, ob es gelingt, die Pleiten bei JSR 193 (Client Side Container, anno 2002) und dem Swing Application Framework (JSR 296) vergessen zu machen. Der Umfang scheint mir recht ambitioniert zu sein, und man läuft bei diesem Thema immer Gefahr, vom hundertsten ins tausendste zu kommen. Allein die Zielgruppe zu definieren (kleine und/oder große Anwendungen? Modularisierung selbst oder auf Basis von z.B. OSGi (oder gar Jigsaw)? Nur Entwicklung oder auch Test und Deployment? Für ein spezielles Toolkit oder generisch? Support für Persistency irgendeiner Art und wenn ja welcher Art?) ist eine Kunst. Dann die Abgrenzung gegenüber den Platzhirschen Eclipse RCP und Netbeans Platform.

Ich persönlich denke, dass ein schlankes Framework irgendwo zwischen “Swing/JavaFX von Hand” und Netbeans Platform auf jeden Fall seinen Platz finden würde. Aber das dachte ich auch schon beim (B)SAF. Mal sehen, ob es diesmal klappt.

Die initiale maximale Größe eines JPanels

 Java, Swing  Kommentare deaktiviert für Die initiale maximale Größe eines JPanels
Sep 102014
 

Heute bin ich über ein interessantes Detail bei der Swing-Programmierung gestolpert. Gegeben war eine JLayeredPane, die ein JPanel (leer, nur mit Hintergrundfarbe ausgestattet) und eine Editor-Komponente (basierend auf JTextPane)  beinhaltete. Die Editor-Komponente wurde durch sehr viel Textinhalt nun relativ groß (über 70000 Pixel hoch), und man sah plötzlich, dass das JPanel nicht mehr die komplette Höhe ausfüllte.

Debugging brachte zutage, dass regelmäßig setBounds des JPanels aufgerufen wurde, mit einer Höhe von 32767 Pixeln. Aha, das Maximum eines vorzeichenbehafteten 16bit-Wertes. Aber wo kommt der her?

Des Rätsels Lösung: es ist die maximumSize des JPanels im Initialisierungszustand. Man lernt halt jeden Tag dazu, selbst wenn man seit Swing 1.1 damit Oberflächen baut.

Wer dieses Detail aus dem Stegreif wusste, darf mir gerne mailen.

Besonderer Gruß an THR, mit dem ich zusammen das Problem gedebuggt habe.

Ein Hoch auf die Applet-Technologie

 Java, UI  Kommentare deaktiviert für Ein Hoch auf die Applet-Technologie
Sep 092014
 

Java-Applets waren mal hip. Zu einer Zeit, als das Wort hip noch nicht hip war. Als noch nicht mal Netscape der Browser der Wahl war, sondern gerade HotJava sich anschickte, Mosaic abzulösen.

Seit geraumer Zeit verfolgt die Applet-Technologie jedoch ein schlechter Ruf. Breit publizierte Sicherheitslücken im Java-Plugin, die teilweise fragwürdigen Entscheidungen von Sun und Oracle in punkto Weiterentwicklung, und durchaus auch schlechte Qualität der Plugins in den Anfangsjahren. Inzwischen scheint der allgemeine Konsens zu sein, dass Java eigentlich auf den Server gehört. Maximal ist noch ein FatClient akzeptabel. Aber Applet? Tote Technologie. Wenn Browser-Oberfläche, dann HTML-basiert. Mit Frameworks wie GWT, Vaadin, ZK, Wicket. Oder node.js, AngularJS, jQuery. Auch die ehemals hippen Technologien wie Flash, Silverlight oder Flex sind totgesagt.

Zweifellos gibt es valide Anwendungen für pure Browser-Oberflächen. Google Maps oder Gmail zeigen das eindrucksvoll. Und doch sind die Anwendungen meist nur ein Schatten von “echten” Anwendungen. Word im Browser? Noch nie gescheit gesehen. VisualStudio oder Eclipse im Browser? Wer mal JazzHub probiert hat – wenn sich mal jemand den Spaß am Coden verleiden will, ist das ein probates Mittel.

Doch wenn ich heute eine einigermaßen komplexe Anwendung mit graphischer Oberfläche entwickeln muss, wäre meine erste Wahl immer noch Java mit Swing als Oberflächentechnologie. Erstens ist man flexibel, was das Einsatzszenario angeht – egal ob Anwendung standalone oder als Applet im Browser. Dazu weitgehende Unabhängigkeit vom Betriebssystem und anständige Performance. Für die Entwicklung kann man das leistungsfähige Java-Tooling verwenden. Dazu die Unmengen an Librarys des Java-Ökosystems.

Durch die Flexibilität des Look&Feels von Swing (oder natürlich das neumodische CSS für JavaFX für die, die näher am Hype sein wollen) kann man eine sehr gute Integration in vorhandene Webanwendungen erreichen. Und mit der entsprechenden Konfiguration des Plugins, nur signierte Applets aus vertrauenswürdiger Quelle auszuführen, ist die Security-Problematik ebenfalls stark entschärft.

Bleibt der Nachteil, dass ein Plugin installiert werden muss und der Browser allein nicht ausreicht. Aber ist das ein größeres Problem als die Cross-Browser-Kompatibilität?