Applets oder Anwendung

[Axel_Janssen]

Hi,

folgende Fragen und Feststellungen:
- Ich kann in Applets in Notes-Corba Klassen einbauen und so auf Domino Objekte auf dem Server zugreifen.
Mit Applets gibt es keine Corba-Abkürzungen über die Klassen des lokalen Clients, oder??? (Ralf, bitte nicht böse sein, wenn du das schon gesagt hast, mir ist durch dich einiges klar geworden)


Ich müsste in einem semi-kommerziellen Projekt
- auf eine Notes-Collection zugreifen (gut die collection selbst hole ich mir im init() und cache die dann in einer class-property) und dann ein getAllDocumentsByKey() auf die Collection.  
- da dann über so ca. 2-7 Dokumente (denke ich) iterieren
- pro Dokument 4 Feldwerte auslesen (letzteres kann ich zur Not auch zu einem remote-call zusammenfassen und dann mit Trennzeichen und String).
- Das ganze nicht 1x in init(), sondern mehrmals (wenn der User eine andere KW in der Combo-Box verändert).
(macht etwa 10 remote calls).

Weiss ich sicher von EJB, was so ähnlich wie Corba ist:
Remote-calls sollten natürlich immer minimiert werden, weil Methoden Parameter, Rückgabewerte nicht einfach mit den Standard-Java-Methode (by copy-of-reference, by copy) übertragen werden, sondern serialisiert, über die Leitung geschickt und deresialisiert werden müssen (hört mir noch einer zu?)


---> In der grossen Not kann ich natürlich jede Information verdichten/aggregieren indem ich einfach in zeitgesteuerten Agenten Zwischendokumente erzeuge (hört mir einer zu?). Also die ganzen Informationen aller MAs aus KW 27 in ein Dokument schreiben und dann mit Trennzeichen sowie das dann in Java wieder auslesen.
Das wären dann 2 remote calls (bei in init initialisierter View).
View.getDocumentByKey() und Doc.getItemValueString().  

Wir wissen, dass ich über eine Java-Anwendung, die aus Notes heraus gestartet werden kann, über die lokalen Klassen gehen kann, was schneller ist.
Wenn ich nun diese lokalen Klassen automatisiert mit JavaWeb-Start verteilen kann. Was gibt es dann überhaupt noch für Nachteile gegenüber Applets?
[http://www-106.ibm.com/developerworks/java/library/os-jws/?open&ca=dgr-jw17os-jwsLink auf gut wirkenden Artikel zu Webstart

Oder was habe ich für Nachteile, wenn ich eine Swing-Gui über einen Java-Agenten erstelle? (wir reden über 6).

Zumindest hat man Alternativen.

Gruss Axel

ausserdem ist alles immer besser dokumentiert und alle schreiben tutorials und viel besser als ich.
http://www.javablogs.com versetzt mich momentan in einen Zustand der Euphorie.

[Axel_Janssen]

Ha!!!
Für genau diese Aufgabenstellung habe ich mir jetzt doch eine vermutlich lauffähige Design-Strategie mit eingebetteten, single-categorized, treat-content-as-html views Zwischendokumenten, Javascript und Notes-Agenten überlegt.
Das nehme ich natürlich, weil das nahtloser zu integrieren ist.

Trotzdem swing ist schon interessant.
Aber ich geniesse es mit Vorsicht.

[Ralf_M_Petter]

Hallo Axel!

Soll das Applet im Notes Client laufen, oder in einem Webbrowser. Wenn es im Notes Client lauft, oder auch im Browser auf Rechnern wo Domino Designer installiert ist, funktioniert auch der lokale Zugriff. Ich verwende das so ähnlich in unserem CMS und es funktioniert wunderbar. Auch die Performance ist sehr gut. Ich bilde dabei kategorisierte Ansichten mit einem JTree (Swing) nach. Der Jtree hat wenn er ganz aufgeklappt ist ca. 2000 Nodes. Die Antwortzeiten mit dem 5er Client bei eingeschalteten JIT sind ca. 0,5 Sekunden. Also soweit ich das deinen Angaben entnehmen kann, dürfte Geschwindigkeit kein Problem sein.

[Axel_Janssen]

Ich entwickele das Applet weiter.
Gute Literatur hilft ungemein das man die echt komplexe Swing-API richtig beherrscht(Manning Swing 2nd ed. sowie "Graphic Java 2 von Geary", 3rd ed.).
Ich meine hier Dinge wie: Wie bringe ich das häßliche grau im Hintergrund der JTable, die in einer JScrollPane liegt. Geht so:

Code

scrollPaneTable.getViewport().setBackground(table.getBackground());

Aber wie soll man darauf kommen  

Netbeans3.5 ist völlig in Ordnung.
Vermisse folgendes dringend:
- In Eclipse kann ich automatisch getter- und setter-Methoden generieren. Hier muß ich tippen.
- Refactoring Unterstützung fehlt. Umbenennung von Variablen in einem Projekt geht in Eclipse z.B. besser.
- Oft muß ich auf "Compile Project" drücken, damit Änderungen in Helferklassen bei Test da sind. Nervt ein bißchen.
- Eclipse hat auch einfach viele interessante Zusatz-plugins. Nur eben keinen graphichen GUI-Editor, der es mit Netbeans aufnehmen kann.

Mein LayoutManagement ist noch nicht so wie ich will. Irgendwie ende ich immer damit, daß ich GridBagLayout benutzen will.

Ich sehe ein, daß eine Komponente wie JTable komplex sein muß. Mußte aber gestern nacht erst einmal vor AbstractTableModel kapitulieren und habe DefaultTableModel benutzt. Weiß aber jetzt wie es geht.  Hoffentlich.  

Auslagern von bestimmter Funktionalität in helper-Klassen ermöglicht die einfache Einbindung in Notes-Agenten, Notes-Applets und eigentlich allen beliebigen Java-Progs.

Nun muß ich das in Notes einbinden. Denke da über best-practices nach.
- Eine eigene Klasse ist für die Responsabiltiy "mit Notes kommunizieren ist klar". Objekt einfach als 1-1 unidirektionale Association GuiClass has-a NotesClass.  
- werde sicher invokeLater() und invokeAndWait() benutzen. Das gehört wohl in die GUI-Klasse. Hat schon jemand damit gearbeitet?
- Ich zeige Daten aus Domino-Dokumenten in einer JTable an. Wie reagiere ich darauf, wenn sich etwas in den Daten in Notes ändert. Geht da eventuell ein über weite Zeiträume schlafen-gelegter Thread, der sagen wir alle 2 Minuten Notes abfragt? Das wäre nett. Hat jemand Erfahrungen damit?

[Axel_Janssen]

JTable.
Bisher gehts, aber es sind schon eine Menge Objekte, die da mitspielen:
JTable, AbstractTableModel, JTableHeader, TableColumn.

Mit der entsprechenden Literatur gehts.
Bei TableColumns kann nicht einfach so der Header gesetzt werden. ... erst einmal remove und dann wieder add.
Hat wohl was damit zu tun, dass die Columns standardmässig in der Tabelle per drag-and-drop umsortiert werden können.
Mit DefaultTableModel wäre es einfacher, ich brauche aber vermutlich später mehr Flexibilität, als diese Klasse erlaubt.

Bisher gehts. Wenn jetzt der Datenaustausch mit Notes in einer einigermassen akzeptablen Geschwindigkeit vonstatten geht, sind JApplets in Notes für mich absolut einsetzbar.  

Die Buttons und Select-Boxen sind soweit funktional. Der Header der Table passt sich an das entsprechende Datum an.

[Axel_Janssen]

FRAGE AN RALF: Wie stelle ich bei Netbeans ein, daß es die Notes-VM benutzt (vereinfacht das Testen).

Hatte nun die erwartete Begegnung der 3. Art.
In der ComboBox cbWoche tausche ich an einer Stelle alle Items aus (wenn der User ein neues Jahr wählt).
Etwa so:

Code

cbWoche.removeAllItems();
      for (int i=0; i < selectionWeeks.size(); i++) {
            WeekInfoVO temp = (WeekInfoVO) selectionWeeks.get(i);       
            cbWoche.addItem(temp.getFormatedElement());
        }

JComboBox.addItem() ruft intern das entsprechende ActionPerformed-Event auf. Sowas muß man natürlich wissen. Steht nur leider nirgendwo. Dies führte in meinem code dann dazu, daß das Modell der ComboBox während des Item-Wechsels auf einen ItemIndex gesetzt wurde, der nicht existiert.

Die Java14 VM hält diesen unstabilen Zustand aus, ohne einen ArrayIndexOutOfBound-Exception zu werfen. Die 1.3-VM in Notes leider nicht.  Bücher und Newsgroups schwiegen zu diesem speziellen Problem. Habe jetzt einen workaround gefunden. Das Finden der Ursache hat aber jetzt genau 5 Stunden 30 Minuten gedauert.

Erwarte noch weitere solcher Subtilitäten in der komplexen Swing-API.

Vorsätze für Besserung:
- immer die gleiche VM für Entwicklungs- und Targetplattform zu verwenden.
- Log4U einsetzen. Der debugger startet mir einfach zu langsam. Debuggen dauert mir zu lange. Deshalb arbeite ich derzeit mit System.out.println(). Eine vernünftige Strategie mit log4U ist vermutlich das beste.

[Ralf_M_Petter]

Hallo Axel!

Freut mich, dass du dich jetzt doch mit Applets beschäftigst. Leider für dich bin ich derzeit in Urlaub und habe daher nicht Zugriff auf meine Sourcen und Netbeans. Das mit der JVM geht über irgendeine Konfigurationsdatei, Wie man das direkt in Netbeans machen kann weiß ich auswendig nicht. Aber frag mal auf der Netbeans Seite. Das Debuggen langsam ist, kann ich nicht ganz nachvollziehen, wenn ich ein Applet im Debugger starte, startet es nicht langsamer als wenn ich es Normal starte.

Etwas anderes, du musst bei Jtable und Zugriff auf Notes unbedingt ein eigenes Datenmodell verwenden. Sonst wird es für die Zukunft nichts. In den jeweiligen Get Methoden der Zellen, kommt dann der Zugriff auf Notes hinein. Das funktioniert super. Ich habe das selber bereits gemacht. Übrigens so richtig geil wird JTable, wenn du eigens programmierte Renderer und Editor für die Zelle verwendest. Aber auch schon ein Jslider in einer Zelle sieht ziemlich gut aus. Probier es einfach mal aus. Wenn ich nächste Woche wieder in der Firma bin, poste ich mal ein Tablemodell mit Notes Unterstützung.

Grüße

Ralf

[Axel_Janssen]

Hi Ralf,

schönen Urlaub.
Das geht eigentlich ziemlich gut mit dem Applet. Bisher war das auch bedeutend schneller als ich dachte. Sowohl Runtime als auch Entwicklungszeit.

Der Debugger ist nicht schlecht, aber ich meine diesen ganzen Prozess des breakpoint-setzen, Variablen inspizieren, etc.
Mein Ziel ist es so gut planen zu können, dass ich das nur noch in Ausnahmefällen brauche (o.k. ist noch ein weiter Weg). Ich versuche die Klassen auch immer so zu machen, dass ich auch immer Teile testen kann. Hast du dich mal mit JUnit beschäftigt? Da schreibt man zuerst den Test und dann die Klasse. Tendentiell finde ich das nicht schlecht, aber ein bischen zu extrem.
Wenn ich aber eine funktional kohäsive NotesConnection Klasse schreibe, bekommt die eine main und ich teste die direkt. Je kleiner die Einheiten sind, die ich unmittelbar teste, desto weniger benötige ich den debugger.
UML - Skizzen (im Sinne von mies aussehenden Zeichnungen) helfen mir auch dabei.

Ich habe ein eigenes Modell (extends AbstractTableModel), dass auf eine andere Klasse NotesConnection zugreift, um mit Notes zu kommunizieren.
Das geht.

Ich kann mir aber die Daten nicht in einem Schwung holen (könnnen schon, aber es ist vielleicht nicht so sinnvoll). Vielmehr kann der User eine Woche auswählen und das Applet holt sich dann alle Wochen-Daten von Notes.

Nervig ist, dass wenn ich mit sinitThread, stermThread arbeite, eigentlich keine Notes-Objekte in Instanzvariablen der NotesConnection_klasse abgelegt werden können.
Ich dachte erst: Im Konstruktor das (NOtes)Database Objekt initialisieren und dann in der Methode getMAs () dieses wiederverwenden. Das geht aber zumindest mit sinit/stermThread nicht, weil ich eine can't access Object, cause it was recyclet or sonstwas Meldung bekomme.   stermThread() macht die Objekte wohl unbrauchbar. Werde das jetzt nochmal genauer lesen. Es gibt ja auch andere Möglichkeiten NotesThreads zu verwalten. Obwohl... wenn ich genau darüber nachdenke. Vielleicht geht das auch gar nicht. Vielleicht ist diese Notes_Klasse zwangsläufig statuslos. Sonst kann es nämlich sein, dass der User zwischen 2 aufrufen das Applet schliesst und dann werden die Objekte nicht recyclet. Das will ich unter allen Umständen vermeiden.

Editoren kommen später. Sonst kann ich das Applet ja nur angucken und keine Daten dort reinschreiben.

Hier ist Screenshot. Die Personen kommen aus der Notes-Datenbank.  

[Axel_Janssen]

O.k. vielleicht brauche ich das von einem Performance-Standpunkt für diese Applikation nicht. Vielleicht aber schon. Ich habe 768 MB Arbeitsspeicher. Notes-Client und -Server sind auf einer Maschine.

Caching von Notes-Objekten in Instanzvariablen?

Wie wäre es damit (bin mir echt nicht so sicher, ob ich das alles richtig verstehe):
So in der Art, ohne daß ich es jetzt ausprobiere:

Code

package de.aja.db;
import java.util.*;
import lotus.domino.*;

public class NotesConnection extends NotesThread {
    
    Database nDbCurrent;
    Session nSession;
    View nViewMAs;
    String serverName;
    String serverPath;
    
    public static NotesConnection factory(HashMap appletParameters) {
     if (nConnection == null) {             
        nConnection = new NotesConnection(appletParameters);   
     }
     return nConnection;
    }

    /** Creates a new instance of NotesConnection */
    public NotesConnection(HashMap appletParameters) {
         serverName = (String) appletParameters.get("dbServerName");
         serverPath = (String) appletParameters.get("dbPathName");
        this.serverName = serverName;
        this.serverPath = serverPath;
    }


     runNotes () {
       try {
         if (nSession == null) {
              nSession =NotesFactory.createSession();
         }
          if (nDbCurrent == null)  {
                 nDbCurrent.getDatabase(serverName, serverPath);
           }
            if (nViewMAs == null) {
                  nViewsMAs = nDbCurrent.getView("vMAs");
             }
        
            Vector vecMAs = new Vector();
            
            Document nDoc = null;
            
            
            nDoc = nViewMAs.getFirstDocument();
            while (nDoc != null) {
                                        vecMAs.add(nDoc.getItemValueString("userNameAbb"));
                
                nDoc = nViewMAs.getNextDocument(nDoc);   
            }
// do more business logic stuff            
// von hier TableModel über invokeLater()  evtl. invokeAndWait() aktualisieren.
// weil Swing-Komponenten nur so von einem anderen Thread 
// als dem berühmten event dispatch thread sicher aufgerufen 
// werden können
             
        } catch (NotesException e) {
              // do recycle() stuff
               e.printStackTrace();
        } finally { 
        }  
    }
    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
      //
   }    
}

Diese Klasse wird von TableModel initialisiert. Von dort wird auch die runNotes-Methode aufgerufen.
Am besten im init() des Applets (erzeugt das TableModel und delegiert zu ihm die Initialisierung des Notes-Thread. Und Notes-Thread in destroy von der Applet-Klasse beenden. Einfach ist das nicht.  

Axel

[Axel_Janssen]

Mit Netbeans für Notes entwickeln.
Sobald man anfängt aus dem Applet auf LoNo zuzugreifen, wird es ein bischen kompliziert.

Da spielt die Sandbox nicht mit, was auch zu erwarten war.
SecurityAccessControlException. JaJa.
Es gibt ja nun seit Java2 Möglichkeiten, die Sandbox policies liberaler zu gestalten. Beschäftige mich damit aber später (Ralf weißt du wie das geht?).

Es erschien mir weniger risikoreich (Donnerstag soll jemand präsentieren) einfach zusätzlich eine standalone gui zusammenzuklicken und damit zu testen. Hat 1 Stunde gedauert. Läuft. Dabei habe ich auch gleich noch den Applet code ein bischen ausgemist ...öhem refaktoriert.

---
Nicht Corba - Applets müssen den Servernamen, Pfad der Datenbank von aussen bekommen? Also nicht wie in Agenten

Code

Database db = AgentContext.getCurrentDatabase() // oder so ähnlich

 
Bin mir da ziemlich sicher. Das kann man aber ganz einfach lösen, da die Appletparameter in der Notes-Maske auch mit Formelsprache geschrieben werden können. @Subset(@dbName; 1); und @Subset(@dbName; -1);  
Die packe ich dann alle in eine HashMap und schicke sie dahin, wo ich sie brauche. Man kann die HashMap dann auch als statisches Property in eine für alle interessierten zugängliche ConfigKlasse legen. Ärgerlich ist nur, daß ich mich gestern nacht genau 4 mal bei den Namen verschrieben habe. Da beginnt einen der jar-Editor von Netbeans zu nerven. Werde glaub ich auf Ant umsteigen. Das hilft aber auch nix in Notes. Da muß man alles von Hand machen. Applet in Ressourcen der db legen. Applet in Seite einbinden. Parameter eintippen (mit Formel).
Vielleicht kann man diesen Notes-Arbeiten auch via Database als xml rausschreiben, xml ändern, aus xml wieder Datenbank machen automatisieren. Ich glaube das ist relativ viel Arbeit.

Btw: Applets in Notes sind wirlich nicht schlecht. In Notes finde ich es oft so nervig, dauernd irgendwelche Dokumente zu öffnen und auf Buttons zu klicken. Mit Applets kann man die GUI eben wesentlich besser auf die wirklichen User-Bedürfnisse customizen.

Swing macht mir auch bedeutend mehr Spaß als vor 1.5 Jahren. Allgemeines Java/OO-Wissen hilft eben für alle Java-Aufgaben .
Außerdem ist das wegen VM-Verbesserungen und so wesentlich schneller geworden.
 
Hier ist eine interessante Diskussion zum Thema Swing vs. SWT:
http://www.logemann.info/day/archives/000008.html
Es existieren eben eine Reihe von Tools/Libraries/Frameworks und alle haben ihre Vor- und Nachteile.
Man kann sich sicher auch noch darüber Gedanken machen, ob man auf Swing noch weitere Helferlein draufsetzt (z.B. existieren frameworks, wo man die GUI als xml Dok beschreibt. Aber da kenne ich mich noch nicht so aus mit.

Axel

[Axel_Janssen]

Habe die große MultiThreading Offensive erst mal vertagt (Wochenende) und konzentriere mich erst einmal auf das Design des JApplets (Präsentationstermin morgen).

Das lief eine Weile super. Ich habe wie von JGoodies.com vorgeschlagen die Farben der Komponenten auf Windows-Typiesche Farben gelegt. Dafür hover ich mit einem Color-Picker über Windows-Guis, notiere die Farben und setze die entsprechenden Methoden. Vielleicht sollte ich besser über Notes hovern, aber das kann ich immer noch ändern, wennn der Prozeß klar ist.

Das lief super, bis ich zu dem Problem kam die Selection Color von ComboBox umzustellen (wenn ich eine ComboBox auswähle, leuchtet das ausgewählte item fröhlich in bissigen Sun-Lila.  

Tja. Und mein Manning Buch meldet dazu folgendes, ohne eine Lösung anzubieten, was ich direkt an die de.comp.lang.java übergeben habe:

class javax.swing.JComboBox
This class represents a basic GUI component which consists of two parts:
- A pop-up menu (an implementation of javax.swing.plaf.basic.ComboPopup). By
default,
this is a JPopupMenu subclass (javax.swing.plaf.basic.BasicCombo-
Popup) that contains a <WICHTIGER_PUNKT>JList in a
JScrollPane</WICHTIGER_PUNKT>.
- A button that acts as a container for an editor or renderer component, and
an arrow button
that is used to display the pop-up menu.

und ein paar Seiten später:
Unfortunately, there is no easy way to access JComboBox's drop-down JList,
which prevents us from assigning new foreground and background colors.
Ideally,
JComboBox would provide this communication with its JList. We hope to see
this functionality in a future version.

Wie kann ich nun die Foreground/Background Colors in einem "auf nicht
einfache Weise" verändern?

HA. Und ein Kollesch namens Tobias Vogele gab genau 11 Minuten später eine Antwort   (Auf Javaranch ist diese Frage nach wie vor unbeantwortet   ) (gestern nacht gepostet).

Du kannst Der ComboBox ja einen Renderer mitgeben, was oft eh nötig ist,
wenn man nicht nur Strings oder ähnliches in der ComboBox hat. Und
dieser Renderer muß natürlich nicht die Farben der JList übernehmen,
sondern kann beliebige Farben benutzen.

Oder anders ausgedrückt:
Die Farben der JList sind nur ein höfliches Angebot an den Renderer,
diese zu benutzen. Was letztendlich angezeigt wird, ist allein Aufgabe
des Renderers. Und den kann man mit JComboBox#setRenderer setzen.

Grüße,

tobi

ich Tölpel. Hoffentlich krieg ich da jetzt nicht Haue.In der Api-Doc findet sich unter Interface ListCellRenderer (Link von getRenderer() auf JComboBox):

Identifies components that can be used as "rubber stamps" to paint the cells in a JList. For example, to use a JLabel as a ListCellRenderer, you would write something like this:

 class MyCellRenderer extends JLabel implements ListCellRenderer {
     public MyCellRenderer() {
         setOpaque(true);
     }
     public Component getListCellRendererComponent(
         JList list,
         Object value,
         int index,
         boolean isSelected,
         boolean cellHasFocus)
     {
         setText(value.toString());
         setBackground(isSelected ? Color.red : Color.white);
         setForeground(isSelected ? Color.white : Color.black);
         return this;
     }
 }

Probier das jetzt mal aus. (mit vernünftigen Farben).

[Axel_Janssen]

Es funktioniert. Nur ist jetzt der Schieberegeler der JComboBox immer noch LILA. JComboBox ist wirklich eine Sch..ß-Komponente.

[Axel_Janssen]

Scheint, wenn ich kein eigenes Look&Feel schreibe, nur über die statische Methode UIManager.put("someStrangeKeyIAmLookingFor", new Color(int r, int g, int b)) zu gehen.

Ziemlich Low Level für meinen Geschmack.
JComboBox sucks.


Axel

[Axel_Janssen]

Ich kann alles relativ tirival verändern. Ausser die kleinen Pfeile zum hoch-/runter-scrollen der Scrollbar.
Die werden in der Klasse MetalScrollBarUI definiert.

in MetalScrollBarUI gibt es die Methoden
#createDecreaseButton und #createIncreaseButton
die jeweils einen MetalScrollButton extends BasicArrowButton
erzeugen. Und dort wird dann alles händisch im paint gemalt.

Tja. Könnte jetzt meinen eigenes Look and Feel entwickeln...


Fazit: Ich kann aus der Swing-API nicht diese Pfeile ändern, es sei denn ich verwende ein anderes Look-And-Feel.
Das Windows Look And Feel in Swing ist auch nicht so toll (ComboBoxen zu groß und läuft nur auf windows).

Es gibt aber Look & Feels als Komponenten zu kaufen. Z.B. auf JGoodies.com.
Der heavyweight components Ansatz von ibm-swt&Jface benutzt native OS-widgets. Da hat man diese Probleme nicht. Swing bastelt eigene, die dann auf allen OSes ungefähr gleich aussehen. Wenn man die dann nicht über die api manipulieren kann, ist das natürlich Mist.  

Es gab vor 10 Jahren in der Small-Talk Welt angeblich eine heftige Diskussion, ob LightWeight oder Heavyweight Components besser sind. Dort hat sich heavyweight durchgesetzt.

Also: zukaufen, selbst entwickeln oder mit dem vorhandenen Kompromisse in Kauf nehmen.

Gruß Axel

[Axel_Janssen]

Look and Feel von Applets zusammengefaßt:

- Das default look and feel mit dem Sun-Lila und dem TU-dunkelgrau als dominierende Farben, ist IMHO auf Dauer eine schlechte Idee. Es paßt einfach nicht zu den sonstigen Windows-Anwendungen.
Da springt dem Sachbearbeiter der Kaffeelöffel auf der Tasse, wenn er das sieht!!!

- Das in Sun jdk mitgelieferte Windows-L&F ist auch nicht gut. Es funktioniert nur unter Windows und sieht noch nicht mal gut aus. Die ComboBoxen sind riesig.

- Man kann das L&F bis zu einem gewissen (und relativ hohen) Grade Windows-Liker machen.
Ein einfacher Trick ist sowas, bevor die Komponenten gepainted werden.

Code

javax.swing.UIManager.put("ScrollBar.thumb", new Color(204, 204, 204));

Man kann sich die keys herausgeben lassen.

Code

UIDefaults uiDefaults = UIManager.getDefaults();
        Enumeration e = uiDefaults.keys();
        
        TreeSet s = new TreeSet();
        while (e.hasMoreElements()) {
            String val = e.nextElement().toString();
            s.add(val);
        }
        Iterator it = s.iterator();
        while (it.hasNext()) {
            System.out.println(it.next());    
        }

Man kann aber auch mit dem Trick nicht die Farben aller lightweight components verändern (z.B. die ArrayButtons von JComboBox nicht). Dafür muß man wohl ein eigenes L&F schreiben (wohl nicht so trivial).

- Als Icons sind die von Eclipse super (Eclipse runterladen, nach*.gif suchen, und dann hat man den Ordner). Man hat keine Lizenzprobleme.

- Man kann sich ein wirklich professionelles L&F von JGoodies kaufen. Preis schätzungsweise 500 Euro, bin mir aber noch nicht 100% sicher. Diese Lösung eines unabhängigen deutschen Entwicklers wird auch international in blogs gelobt.

After some technical talks and some more researching and testing with the JGoodies LooksPro Suite, i ve come to the conclusion that a lot of stuff inside this package is coded very well and the idea behind is just good. Its not only the look&feel which makes JGoodies apps look like sophisticated Windows applications, but also the way of handling things like layouts and dispatching best practices.

Also damn interessting were the tech talks with Karsten Lentzsch, the author of the jgoodies packages. He seems to be one of the most dedicated Frontend developers around. Hopefully he will be more involved with J2SE/Swing in the future, i think even the Swing team at sun could use some insights from karsten.

BTW my very own application is beginning to see the ray of lights and using JGoodies makes it look very pretty.

Als Alternative kann man SWT & JFace von IBM nehmen. Das benutzt Standard-Widgets des OS (heavyweight-component Ansatz). Für SWT & JFace existiert aber z. Zt. wenig Toolunterstützung und die Dokumentation ist auch deutlich schlechter als für swing. Es wird aber besser. Leute die beides kennen, sagen das swing vom Entwicklerstandpunkt aus komfortabler ist.

Gruß Axel

[Axel_Janssen]

Ich habe mir eine primitive Profiling-Klasse für Performance-Messungen gebaut. Dies ist zwar nicht sonderlich komfortabel, aber einfach.

Code

/*
 * SimplePerfChecker.java
 *
 * 
 */

package de.aja.system;

/**
 *
 * @author  Axel Janssen
 */

import java.text.*;

public class SimplePerfChecker {
    
    
    public static long startTime;
    public static String nameTest;
    /** Creates a new instance of SimplePerfChecker */
    public SimplePerfChecker() {
    }
    
    public static void start(String name) {
        nameTest = name;
        startTime = System.currentTimeMillis();
    }
    
    public static String stop() {
        
        if (startTime == 0) return "Error SimplePerfChecker: start wurde nicht aufgerufen";
        long endTime = System.currentTimeMillis();
        double deltaTime = endTime - startTime;
        return nameTest + " dauerte " + DecimalFormat.getInstance().format(deltaTime/1000.) + " Sekunden";
    }
    
}

Das kann aus jeder Java-Anwendung aufgerufen werden (auch von Notes-Agenten).
Wird wie folgt aufgerufen:

Code

SimplePerfChecker.start("namensBezeichner");
// [...] code der gemessen werden soll. 
System.out.println(SimplePerfChecker.stop());

Wird dann auf die Konsole geschrieben.

[Axel_Janssen]

Multi-Threading aus Swing auf Notes scheint zu funktionieren.
GEIL!
Das war der erwartete Performance-Booster: Zugreifszeiten liegen jetzt auf 10%!!! der vorherigen Werte.

Schon unheimlich. Eigentlich ist das nicht mehr ein sequentieller Ablauf sondern 4 Threads die parallel laufen und miteinander kommunizieren. 2 der Threads laufen immer. Der Notes-Thread und der GUI-Thread. Wenn ich mir das genau anschaue, erinnert mich das stark an Client-Server-Infrastrukturen. Das MultiThreading.

Dies war eine meiner interessantesten Programmierwochen meines Lebens. Hoffentlich kommen nicht jetzt irgendwelche Scheissen-Probleme, die ich nicht brauche. Aber hey. Es wirkt verdammt stabil.


Axel