Mit einem JColorChooser lassen sich Farben über drei unterschiedliche Reiter auswählen. Der Benutzer hat die Auswahl zwischen vordefinierten Farben, HSB-Werten und RGB-Werten. Um den Farbauswahldialog auf den Bildschirm zu bekommen, genügt ein Aufruf von JColorChooser.showDialog(Component, String, Color) mit drei Argumenten: einem Component-Objekt (dem Vater des Dialogs), dem Titel und einer Anfangsfarbe. Beendet der Benutzer den Dialog, wird als Rückgabewert die ausgewählte Farbe geliefert. Wird der Dialog abgebrochen, so ist der Rückgabewert null:

JFrame f = new JFrame();
 f.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
 JButton b = new JButton( "Farbe ändern" );
 f.add( b );
 b.addActionListener( new ActionListener() {
   @Override public void actionPerformed( ActionEvent e ) {
    Component comp = (Component) e.getSource();
    Color newColor = JColorChooser.showDialog( null,
                                               "Wähle neue Farbe",
                                               comp.getBackground() );
    comp.setBackground( newColor );
  }
 } );
 f.pack();
 f.setVisible( true );

Den Aufruf mit showDialog(…) einzuleiten, ist nicht der einzige Weg. Wir können auch den Konstruktor nutzen und dieses Exemplar später mit JColorChooser.createDialog(…) übergeben und anzeigen.

class javax.swing.JColorChooser
extends JComponent implements Accessible

• JColorChooser()
  Erzeugt einen neuen Farbauswahldialog.
• JColorChooser(Colorc)
  Erzeugt einen neuen Farbauswahldialog mit einer vordefinierten Farbe.
• staticColorshowDialog(Componentc,Stringtitle,ColorinitialColor)
  Zeigt einen modalen Farbauswahldialog.
• staticJDialogcreateDialog(Componentc,Stringtitle,booleanmodal,
  JColorChooser chooserPane, ActionListener okLis, ActionListener cancelLis)
  Erzeugt einen neuen Dialog aufgrund des JColorChooser-Objekts mit Standardschaltflächen zum Bestätigen und Abbrechen.

JColorChooser-Objekte als spezielle Komponenten

Neben der statischen Methode showDialog(…) lässt sich auch der Konstruktor nutzen, um ein JColorChooser als spezielles JComponent-Objekt aufzubauen. Das bringt den Vorteil mit sich, dass die Farbauswahl nicht zwingend in einem eigenständigen Dialog stattfinden muss, sondern dass im Fall einer Komponente diese zusammen mit anderen Komponenten auf einen Container gesetzt werden kann. Änderungen an der Auswahl registriert ein ChangeListener, der etwa so angewendet wird:

chooser.getSelectionModel().addChangeListener( new ChangeListener() {
   @Override public void stateChanged( ChangeEvent e ) {
     Color c = ((ColorSelectionModel) e.getSource()).getSelectedColor();
   }
 } );

Weitere Beispiele finden sich unter http://www.java2s.com/Code/Java/Swing-JFC/Color-Chooser.htm. Wie ein neuer Reiter mit über 50 Schattierungen in der Graustufenanzeige eingebracht wird, zeigt etwa http://www.java2s.com/Code/Java/Swing-JFC/JColorChooserdialogwiththecustomGrayScalePanelpickertab.htm.

Gute Benutzerschnittstellen zeichnen sich dadurch aus, dass dem Benutzer Fehler unterlaufen dürfen. Die Änderungen müssen jedoch wieder zurückgenommen werden können. Um dies in Java zu realisieren, gibt es Unterstützung durch ein Paket javax.swing.undo. Mit ihm lassen sich Undo- und Redo-Operationen mit relativ wenig Aufwand realisieren. Unser Beispiel soll ein Textfeld zeigen, dessen Änderungen auf Knopfdruck rückgängig gemacht werden. Zentrales Objekt ist dabei ein UndoManager. Dieser sammelt einzelne Aktionen, im Fall von Benutzereingaben jedes Zeichen. Die Anzahl der zu speichernden Aktionen ist beschränkt, lässt sich aber anpassen. Wir wollen in einem Beispiel ein JTextField mit einem Standardtext erzeugen. Anschließend wird ein UndoManager mit dem Document-Objekt des Textfeldes verbunden. Das Document informiert den UndoManager über Änderungen, der UndoManager speichert diese. Wenn eine Schaltfläche aktiviert ist, wird dem UndoManager befohlen, die Aktion rückgängig zu machen. Sichtbar wird dann wieder der Text, so wie er am Anfang in der Textbox stand:

package com.tutego.insel.ui.undo;
 
 import java.awt.BorderLayout;
 import java.awt.event.*;
 import javax.swing.*;
 import javax.swing.event.UndoableEditEvent;
 import javax.swing.undo.*;
 
 public class IComeUndone {
   public static void main( String[] args ) {
     JFrame f = new JFrame();
     f.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
 
     final JTextArea textarea = new JTextArea( 20, 40 );
     textarea.setText( "Hier zurück" );
     f.add( new JScrollPane(textarea) );
 
     //    final UndoManager undomanager = new MyUndoManager();
     final UndoManager undomanager = new UndoManager();
     textarea.getDocument().addUndoableEditListener( undomanager );
     undomanager.setLimit( 1000 );
 
     JButton undoB = new JButton( "Undo" );
     undoB.addActionListener( new ActionListener() {
       @Override public void actionPerformed( ActionEvent e ) {
         undomanager.end();
 
         if ( undomanager.canUndo() )
           undomanager.undo();
         textarea.requestFocus();
       }
     } );
 
     f.add( undoB, BorderLayout.PAGE_END );
     f.pack();
     f.setVisible( true );
   }
 }

Um genauer zu sehen, was das UndoManager-Objekt rückgängig macht, schreiben wir eine Unterklasse von UndoManager und überschreiben die Methode undoableEditHappened(UndoableEdit-Event) (diese Methode implementiert UndoManager von der Schnittstelle UndoableEditListener). Geben wir in unserer Realisierung auf dem Bildschirm aus, was bei jeder Aktion in den UndoManager kommt:

class MyUndoManager extends UndoManager {
   @Override
   public void undoableEditHappened( UndoableEditEvent e ) {
     UndoableEdit ue = e.getEdit();
     System.out.println( ue );
     addEdit( ue );
   }
 }

Die Methode undoableEditHappened(UndoableEditEvent) bekommt ein Ereignisobjekt, in dem der Verweis auf eine zurücknehmbare Operation abgelegt ist. An diese kommen wir mit get-Edit(). Die Rückgabe ist ein UndoableEdit-Objekt, also genau eine Operation, die zu einem Undo und Redo fähig ist. Der UndoManager speichert diese mit dem Aufruf von addEdit() in einer Datenstruktur ab. Wenn wir das UndoableEdit-Objekt auf dem Bildschirm ausgeben, sehen wir unsere durchgeführte Operation, zum Beispiel bei einem Einfügen:

[javax.swing.text.GapContent$InsertUndo@497934 hasBeenDone: true alive: true]

Beim Löschen erkennen wir ein:

[javax.swing.text.GapContent$RemoveUndo@ca470 hasBeenDone: true alive: true]

Obwohl OpenJDK unter der GPL stand, enthielt es doch Teile wie den Font-Renderer, Sound-Unterstützung, Farbmanagement oder SNMP-Code, die als binäre Pakete beigelegt wurden, weil etwa die Rechte zur Veröffentlichung fehlten. Sun nennt diese Teile, die etwa 4 % vom JDK 6 ausmachen, belasteten Code (engl. encumbered code)[1]. Das hinderte puristische Linux-Distributoren daran, OpenJDK auszuliefern. RedHat startete im Juni 2007 das Projekt IcedTea, um diese binären Teile auf der Basis des OpenJDK durch GPL-Software zu ersetzen. So basiert der Font-Renderer zum Beispiel auf FreeType[2] und das Farbmanagement auf little CMS[3]. Mit diesen Ersetzungen erfüllte das OpenJDK mit IcedTea im Juni 2008 die Anforderungen des Technology Compatibility Kit (TCK) von Sun und ist in der Öffentlichkeit seither unter dem Namen OpenJDK 6 bekannt. Daraufhin floss das OpenJDK 6 plus der Ersetzungen unter der GPLv2 in Linux-Distributionen wie Fedora und Debian ein.

Das OpenJDK bildet die Basis von Java 8, und jeder Entwickler kann sein eigenes Java zusammenstellen und beliebige Erweiterungen veröffentlichen. Damit ist der Schritt vollzogen, dass auch Java auf Linux-Distributionen Platz finden darf, die Java vorher aus Lizenzgründen nicht integrieren wollten.

Auch wenn es sich so anhört, als ob das Oracle JDK bzw. OpenJDK das Gleiche sei, ist das nicht ganz richtig: Zwar basieren Oracle JDK und OpenJDK auf den gleichen Quellen (bei der Version 7 etwa zu 95 %), doch sind beim Oracle JDK immer noch proprietäre Dinge enthalten, und nicht alles ist hundertprozentig quelloffen und GPL. Das gilt für die Version 7 wie für die Version 6. Das Oracle JDK steht unter der Binary Code License; genau die muss jeder abnicken, der das JDK von der Webseite laden möchte.

Bei der 6er-Reihe kommt noch eine Besonderheit dazu, wie es die Versionsnummern[4] ganz gut zeigen. Während das Oracle JDK zum Beispiel im Juni 2011 bei Versionsnummer 1.6.0_26-b03 steht, ist das OpenJDK bei Version 6 b22. Die Versionsnummern sind deshalb völlig unabhängig, weil beide Projekte auch unabhängig voneinander laufen. Das hat mit der Geschichte zu tun. Nach der Entwicklung des JDK 6, das nicht unter der GPL steht, ging es mit dem JDK 7 logisch weiter. Aus dem JDK 7 (Build 10) entstand dann OpenJDK, das heute mit der Versionsnummer OpenJDK 7 genannt wird. OpenJDK 7 und JDK 7 entwickeln sich Hand in Hand, und Code-Änderungen gehen mal in die eine Richtung und mal in die andere.

Jetzt kommt die Besonderheit: Das OpenJDK 6 entstand nicht, wie vermutet werden könnte, aus dem Oracle JDK 1.6, sondern aus dem OpenJDK 7 (Build 20). Es wurden nur Java 7-Eigenschaften entfernt. So läuft das auch bis heute: Die meisten Änderungen am OpenJDK 6 sind Backports von OpenJDK 7. Änderungen am OpenJDK 7 stammen überwiegend von Oracle, und häufig ist es die Firma RedHat, die diese Änderungen in OpenJDK 6 portiert. Zwischen dem OpenJDK 6 und dem JDK 1.6 gibt es einen Quellcodeaustausch bei Bug-Fixes, doch die Codebasis ist unterschiedlich. Oracle JDK 6 ist im Wartungsmodus, und großartige Veränderungen passieren bis auf Fehlerbereinigungen nicht.

Oracle JDK 8 ist die Version, die die Download-Seite von Oracle anbietet; das OpenJDK 8 liegt auf einem eigenen Server http://openjdk.java.net/projects/jdk8/. Das OpenJDK bildet die Referenzimplementierung für Java SE, nicht das Oracle JDK.

^[1]  http://www.sun.com/software/opensource/java/faq.jsp#h

^[2]  http://www.freetype.org/

^[3]  http://www.littlecms.com/

^[4]  http://gist.github.com/925323

http://www.heise.de/newsticker/meldung/Programmiersprachen-Ranking-Ungeahnte-Hoehen-fuer-Java-im-TIOBE-Index-2807581.html, Quelle: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

https://github.com/blog/2047-language-trends-on-GitHub:

http://www.informit.com/articles/article.aspx?p=2425867

Auch interessant für Java, und erstmalig für mich ein offizieller Hinweis, das C# Dinge von Java geerbt hat, was MS immer verneint. Eric ist:

During his sixteen years at Microsoft he was a developer of the Visual Basic, VBScript, JScript and C# compilers and a member of the C# language design committee; he is now a C# MVP.