@Target Annotation seit Java 8

Die Meta-Annotation @java.lang.annotation.Target beschreibt, wo eine Annotation angeheftet werden kann. Ist kein ausdrückliches @Target gewählt, gilt es für alle Elemente, die Annotation kann also etwa an Klassen stehen, aber auch an lokalen Variablen. In der Regel gibt es bei @Target ein Element, und das ist von der Aufzählung java.lang.annotation.ElementType; es deklariert die folgenden Ziele:

ElementType

Erlaubt Annotationen …

ANNOTATION_TYPE

nur an anderen Annotationstypen, was @Target(ANNOTATION_TYPE) somit zu einer Meta-Annotation macht.

TYPE

an allen Typdeklarationen, also Klassen, Schnittstellen, Annotationstypen, Aufzählungen.

CONSTRUCTOR

an Konstruktor-Deklarationen

METHOD

an Deklarationen von statischen und nicht-statischen Methoden.

FIELD

an Deklarationen von statischen Variablen und Objekt-Variablen.

PARAMETER

an Parametervariablen von Methoden.

LOCAL_VARIABLE

an lokalen Variablen.

PACKAGE

an package-Deklarationen.

TYPE_PARAMETER

an der Deklaration einer Typ-Variablen für generische Typ-Parameter. Neu in Java 8. Wenn es etwa heißt class List<@AnAnnotation T>.

TYPE_USE

an allen Stellen, wo Typen eingesetzt werden, adressiert also Typ-Annotationen. Ebenfalls neu in Java 8. So etwas wie @NonNull (keine Annotation aus der Java SE!) ist ein Beispiel

Tabelle 1.3: ElementType bestimmt Orte, an denen Annotationen erlaubt sind.

Orte für Annotationen

Annotationen lasen sich setzen an allen Deklarationen und bei Typnutzungen (ab Java 8).

Deklarationen

Typnutzung

Typendeklarationen (Klassen, Schnittstellen, Aufzählungen, anderen Annotationtypen)

new-Operator

Eigenschaften (Konstruktoren, Methoden, Attributen)

Typ-Anpassung

 

implements-Klausel

 

throws-Klausel bei Methoden

Wo Annotationen möglich sind

Die Annotationen bei der Typnutzung nennen sich kurz Typ-Annotationen.

Java bringt einige Annotationstypen mit, doch die werden bisher ausschließlich für Deklarationen eingesetzt, wie das gekannte @Override. Vordefinierte Typ-Annotationen sind bisher in der Java SE nicht zu finden.

Was sind Markierungsschnittstellen (Marker-Interfaces)?

Markierungsschnittstellen kann man als Design-Pattern ansehen. Sie tauchen zwar nicht so häufig auf, doch Java kennt mit Serializable und Remote zwei prominente Vertreter.

Es anderes Beispiel soll hergestellt werden: Eine Textverarbeitung speichert in erster Linie Text. Dazu kommen noch weitere Datentypen wie Tabellen, Grafiken oder Formeln, aber wie der Name Textverarbeitung zeigt, ist der Datentyp im Kern Text. Etwas genauer betrachtet besteht der Text aus Seiten, Absätzen, Zeilen und Zeichen.

Frage: Nehmen wir an, dass die Textverarbeitung für jedes Zeichen ein Objekt vorsieht, welches in einer langen verketteten Liste gespeichert ist. Beim Eintippen neuer Buchstaben werden neue Objekte in die Liste eingefügt und beim Löschen entfernt. Stellt die Textverarbeitung eine Seite dar, wird die Liste sequentiell abgelaufen und jedes Element auf dem Bildschirm ausgegeben. Jedes ausgegebene Zeichen bekommt eine Position und diese wird laufend angepasst.

Zu den normalen druckbaren Zeichen wie Buchstaben und Ziffern kommen Sonderzeichen hinzu. Ein Objektmodell kann dann so aussehen, dass eine Schnittstelle notwendiges für alle Zeichen vorschreibt. Nennen wir die Schnittstelle WordCharacter und geben wir ihr die Methoden getChar(), getCharWidth(), getCharHeight() und drawChar(). Als Unterklassen könnte dann OrdinaryCharacter die druckbaren Zeichen behandeln und MetaCharacter die Sonderzeichen wie Tabulator, Leerzeichen, Return. Läuft ein Algorithmus zur Visualisierung durch die Datenstruktur, besorgt er sich jedes Zeichen, fragt wie lang es ist und ob es mit dem Wort noch in die Zeile passt. Wenn ja, wird die Zeichenposition auf der x-Achse um die Breite des Zeichens erweitert und das nächste Zeichen wird ausgegeben.

Ein Leerzeichen nimmt unter den Sonderzeichen eine besondere Stelle ein. Das liegt auch daran, dass der Leerraum unter Umständen noch erweitert wird, etwa beim Blocksatz. Dann kommt zu jeder Breite eines Leerzeichens noch zusätzlicher Weißraum dazu.

Wie wird die Textverarbeitung normale Zeichen und Leerzeichen verarbeiten, wenn eine Zeile ausgeben wird? Da Leerzeichen nichts auf dem Bildschirm ausgehen, sollen sie besonders behandelt werden.

Eine Lösung: Wenn in der Datenstruktur die Zeichen der Reihe nach vorliegen, wird man in einer Fallunterscheidung feststellen können, ob es sich um ein Leerzeichen handelt oder um anderes Zeichen.

für alle Zeichen einer Zeile
  Character c ist das aktuelle Element
  ist c.getChar() != ' '
    dann verarbeite das Element weiter

Problem: Falls es nun weitere Elemente gibt, die eine ähnliche Sonderbehandlung haben wie das Leerzeichen, wird die Fallunterscheidung immer länger werden. Das wird sie auch, denn es gibt neben dem Standard-Leerzeichen noch weitere Zeichen, die für die Weißraum zuständig sind. Dazu zählt der Tabulator oder das nicht-trennende Leerzeichen. Wenn diese Fallunterscheidung auch noch an anderen Stellen eingesetzt wird, etwa beim Export der Daten in HTML, PDF, müssen die Entwickler darauf achten, Änderungen an der if-Anweisung auch konsistent an den anderen Stellen anzuwenden.

Pattern: Unsere bisherige Unterscheidung war nur auf Grund des Zeichencodes. Interessant ist, wenn das Leerzeichen noch einen weiteren Typ besitzt, denn wenn ein Weißraum-Objekt etwa den Typ WhitespaceChracter haben würde, ließe sich wiederum instanceof einsetzen, um herauszufinden, ob ein Zeichen-Objekt ein Leerzeichen ist oder nicht. Eine Fallunterscheidung mit vielen if-Anfragen fäll raus und es bleibt eine einfache instanceof-Abfrage. Alle Weißraum-Objekte legen wir dann so aus, dass sie einen speziellen Typ haben. Dazu kann ein Leerzeichen-Objekt eine Schnittstelle implementieren, die keine Funktionen vorschreibt.

Eine leere Schnittstelle nennt sich Marker-Interface oder Tag-Interface. Sie markiert ein Objekt mit einem Typ, der anschließend mit instanceof überprüft werden kann. In Java. Es gibt ein Java Marker-Interfaces an einigen Stellen. Die interessanteste Schnittstelle ist java.io.Serializable. Sie markiert alle Objekte, die über die Standardserialisierung automatisch geschrieben werden können. Eine Klasse, die nicht Serializabe ist, die aber trotzdem geschrieben werden soll, wird bei dem Serialisierungs-Vorgang einen Ausnahme melden.

Ein zweites Beispiel ist die Schnittstelle Remote. Sie wird benötigt, wenn Objekte über RMI verteilt angeboten werden sollen. Nur Objekte, die Remote implementieren werden RMI-fähig sein. Eine weitere Schnittstelle ist Clonable. Sie ermöglichst erst das Klonen von Objekten mit einer clone()-Funktion.

Seit Java 5 sind Annotationen eine Alternative zu Markierungsschnittstellen und daher seltener zu finden.

Das oberste Stack-Element duplizieren

Die Klasse Stack besitzt zwar die Basisfunktionalität, die ein Stapel besitzen sollte, aber auch nicht mehr. Hin und wieder wünschen wir uns aber eine Funktion, die das oberste Stack-Element dupliziert, kurz dup(). Allerdings ist das schwerer als gedacht, und das erklärt auch, warum es so eine Methode nicht gibt.

Bei der Implementierung treten zwei Fragen auf, mit denen zwei völlig unterschiedliche Lösungsansätze verbunden sind. Da die Klasse Stack wie die anderen Datenstrukturen auf Objekte ausgelegt ist, müssen wir uns darüber Klarheit verschaffen, wie das obere Objekt dupliziert werden soll. Soll eine Kopie der Objekt-Referenz neu auf den Stapel gelegt werden oder etwa das gesamte Objekt geklont werden?

Die einfache Lösung

Die einfachste Lösung besteht darin, das oberste Objekt einfach mittels der schon vorhandenen Stack-Methoden push() und peek() draufzulegen. Nehmen wir an, wir haben eine Unterklasse DupStack, dann sieht die erste Variante zum Clonen so aus:

void dup() /* throws EmptyStackException */
{
  push( peek() );
}

peek() gibt aber lediglich eine Referenz auf das Objekt zurück. Und das anschließende push() speichert diese Referenz dann auf dem Stapel. Nehmen wir an, wir haben zwei StringBuffer-Objekte auf dem Stapel. Wenn wir nun dup() aufrufen und den String ändern, der oben auf dem Stapel liegt, so ändern wir automatisch das zweite Element gleich mit. Dies ist aber nicht unbedingt beabsichtigt, und wir müssen uns Gedanken über eine alternative Lösung machen. Wir sehen, dass dup() in der Klasse Stack fehlt, weil seine Implementierung davon abhängt, ob eine Referenz- oder eine Wertsemantik für Kellerelemente gewünscht ist.

Die kompliziertere Lösung mit Klonen

Um das oberste Stack-Element zu kopieren, bietet sich die clone()-Methode von Object an. All die Objekte, die sich klonen lassen, und das sind längst nicht alle, implementieren das Interface Cloneable. Nun ließe sich einfach folgern: Wenn das zu duplizierende Objekt ein Exemplar von Cloneable ist, dann können wir einfach die clone()-Methoden aufrufen und das zurückgegebene Objekt mittels push() auf den Stapel bringen.

void dup2() throws CloneNotSupportedException
{
  try
  {
    Object top = peek();

    if ( top instanceof Cloneable )
      push( top.clone() );

  }
  catch ( EmptyStackException e ) { }
}

Beziehungsweise

void dup3() throws CloneNotSupportedException /*, EmptyStackException */
{
  push( peek().clone() );
}

Dies funktioniert für die meisten Objekte, allerdings nicht für Objekte der Klasse Object. Denn clone() der Klasse Object ist protected – wir dürfen also von außen nicht dran, nur eine Unterklasse und die Klasse selbst. Hier haben wir also zwei Probleme.

  • Leider lässt sich nur mit Aufwand überprüfen, ob das Objekt auf dem Stapel auch wirklich ein pures Object ist, denn alle Objekte sind instanceof Object. Glücklicherweise gibt es kaum eine Anwendung, wo reine Object-Elemente gesichert werden müssen.
  • Was machen wir mit Objekten, die nicht klonbar sind? Leider gibt es für diese Frage keine direkte Antwort. Eine universelle Stack-Klasse mit einer uneingeschränkten dup()-Methode gibt es nicht. Wir müssen als Stack-Benutzer festlegen, dass das oberste Element Cloneable ist, um zumindest eine eigene Implementierung nutzen zu können. Oder wir bleiben dabei, bei nicht klonbaren Objekten doch nur die Referenz zu duplizieren. Das wäre zumindest für eineindeutige Objekte mit Wertsemantik die ideale Lösung.

True Type Fonts in Swing/AWT-Anwendungen

Grafische Oberflächen stellen selbstverständlich wie Drucker Zeichensätze dar. Doch der Weg von der Datei bis zur Darstellung ist lang und führt unweigerlich über die Firma Adobe, die erstmalig die standardisierte Zeichendefinition PostScript öffentlich machte. Genauer gesagt, definiert PostScript noch etwas mehr, doch das soll uns hier nicht interessieren. Die erste kommerzielle Zeichensatzrevolution begann 1985, als der Drucker LaserWriter von Apple das Adobe-Format PostScript rastern konnte. Die Definition eines Zeichensatzes lag bis zu dieser Zeit nur in Bitmaps vor, doch die PostScript-Zeichensätze wie auch die TrueType-Zeichensätze, um die es später gehen soll, lagen als Punktbeschreibung vor. Die Rasterung übersetzte diese Punkte in eine Bitmap, die dann entweder auf dem Bildschirm oder auf dem Drucker ausgegeben wurde. Durch die Punktbeschreibung waren also nicht mehr größenabhängige Beschreibungen vorhanden, sondern die Zeichen (auch Glyphs genannt) wurden durch Linien und Kurven in kubischen Bézier-Kurven beschrieben.

Die Visualisierung der Zeichensätze machte Microsoft und Apple Sorgen, weil Adobe mehrere Definitionen der PostScript-Zeichensätze pflegte, darunter Type 1 (PS-1) und Type 3 (PS-3). Type 1 nutzt so genannte Hints (Hinweise), um auch bei unterschiedlichen Größen und grafischen Oberflächen optimale Darstellungen zuzulassen. Diese Definition war jedoch geheim. Zeichensätze des Type 3 sehen zwar auf dem Papier gut aus, nicht aber auf dem Bildschirm mit niedriger Auflösung – hier fehlen die Informationen aus den Hints. Microsoft und Apple wollten nun ihre Zeichensatzausgabe nicht der Firma Adobe überlassen (die natürlich einen Type-1-Rasterer im Programm hatte), sondern definierten ihre eigene Font-Technologie, die nicht mehr auf Bézier-Kurven, sondern auf quadratischen B-Splines basierte. Apple machte dabei den Anfang mit Royal, welches später in TrueType (TT) umgetauft wurde. Dies war sechs Jahre nach den PostScript Fonts. Der einzige Hersteller, der dennoch bei PostScript-Type 1-Zeichensätzen geblieben ist, ist IBM mit dem Betriebssystem OS/2. Daneben nutzte auch NeXtStep diese Zeichensatzdefinitionen, doch das System hallte nicht lange nach.

Nachdem Apple den Anfang mit TT gemacht hatte und es 1991 in MacOS integrierte, übernahm auch Microsoft, wo ein bis dahin wenig lauffähiger PostScript-Clone (»TrueImage«) zum Einsatz gekommen war, die Technologie für Windows 3.1. Adobe erkannte früh die Konsequenz dieser Allianz und öffnete die Spezifikation für PostScript-Type-1-Zeichensätze im März 1990. Mitte des Jahres lieferte Adobe zusätzlich den Adobe Type Manager (ATM) aus, der Type-1-(aber keine Type-3-)PostScript-Zeichensätze für den Bildschirm und für nicht PostScript-fähige Drucker darstellte. Heutzutage existieren beide Definitionen immer noch parallel, und für Drucker ist die Frage, welche nun besser ist, nicht zu beantworten. Moderne Drucker haben auch ein eigenes TrueType-Raster im ROM eingebaut. In Zukunft wird die Unterscheidung wohl auch unwichtiger werden, da Microsoft die »offene« OpenType-Spezifikation (auch »TrueType Open Version 2« genannt) nach vorne bringt. Der Zeichensatz PS-1 oder TrueType wird hier in einer OpenType-Datei gekapselt und dem Rasterer übergeben und berechnet. Dabei übernimmt Adobe, wo eine Zusammenarbeit mit Microsoft unterstützt wird, die PS-1-Rasterung, und Microsoft die TT-Rasterung. In Zukunft möchten Microsoft und Adobe Zeichensätze im OpenType unterstützen und deren Verbreitung fördern.

TTF in Java nutzen

Eine Einschränkung mit den gegeben vordefinierten Standard-Zeichensätzen (Dialog, DialogInput, Monospaced, Serif, SansSerif, Symbol) ist, dass dies zu wenig sind. Doch die Font Kasse bietet die statisch Methode createFont() an, die zu einen Eingabestrom auf ein TrueType Zeichensatz das entsprechende Font-Objekt zurückgibt.

Font f = Font.createFont( Font.TRUETYPE_FONT,
new FileInputStream("f.ttf") );

Der erste Parameter ist die fest vorgeschriebene Konstante Font.TRUETYPE_FONT, andere Parameter sind nicht definiert und führen zu einer IllegalArgumentException("font format not recognized"). Der zweite Parameter ist ein Eingabestrom zu der Binärdatei mit den Zeichensatzinformationen. Die Daten werden ausgelesen und zu einem Font Objekt verarbeitet. Da die Daten intern über einen gepufferten Datenstrom in eine temporäre Datei geschrieben wird, ist eine eigene Pufferung über einen BufferedInputStream nur doppelter Overhead. Waren die Beschreibungsinformationen in der Datei ungültig, so erzeugt die Fontklasse eine FontFormatException("Unable to create font – bad font data"). Dateifehler fallen hier nicht drunter und werden extra über eine IOException angezeigt. Der Datenstrom wird anschließend nicht wieder geschlossen.

Wir wundern uns vielleicht an dieser Stelle, dass die Methode createFont() von der Arbeitsweise mit dem Konstruktor ähnlich sein müsste, aber der Parameterliste die Attribute fehlen. Das liegt daran, dass die Methode automatisch einen Zeichensatz der Größe 1 im Stil PLAIN erzeugt. Um daher einen größeren Zeichensatz zu erzeugen, müssen wie ein zweites Font Objekt anlegen. Dies geschieht am einfachsten mit der Methode deriveFont().

font = f.deriveFont( 20f );

Der Parameter ist ein float und kein double.

AWTEventMulticaster

Löst die Bean AWT-Ereignisse aus, kann sie dafür java.awt.AWTEventMulticaster nutzen. Diese Klasse ist für effizientes Multicast-Benachrichtigen bei AWT-Ereignissen gedacht. Genau genommen verbindet sie dazu nur zwei EventListener miteinander, sodass eine Verkettung entsteht.

protected ActionListener listeners;
public void addActionListener( ActionListener l ) {
  listeners = AWTEventMulticaster.add( l, listeners );
}
public void removeActionListener( ActionListener l ) {
  listeners = AWTEventMulticaster.remove( l, listeners );
}

Da AWTEventMulticaster alle möglichen AWT-Listener implementiert, können wir die Methode actionPerformed(), die die Schnittstelle ActionListener vorschreibt, aufrufen. Wenn wir ACTION_PERFORMED-Nachrichten damit generieren, schreiben wir Folgendes in unsere Bean-Klasse:

protected void fireActionEvent () {
  if ( listeners != null )
    listeners.actionPerformed( new ActionEvent( this, ActionEvent.ACTION_PERFORMED, null) );
}

Die angemeldeten Listener bekommen auf diese Weise ein ActionEvent geliefert. Der letzte Parameter im Konstruktor, der hier mit null belegt ist, kann zusätzlich eine Referenz übermitteln.

class java.awt.event.AWTEventMulticaster

implements ComponentListener, ContainerListener, FocusListener, KeyListener, MouseListener, MouseMotionListener, WindowListener, ActionListener, ItemListener, AdjustmentListener, TextListener, InputMethodListener, HierarchyListener, HierarchyBoundsListener

  • static ActionListener add( ActionListener a, ActionListener b )

    Verbindet Listener a und b und liefert ein neues ActionListener-Objekt zurück.
  • static ActionListener remove( ActionListener l, ActionListener oldl )

    Entfernt Listener oldl von l und liefert den neuen Multicast-Listener zurück.

class java.awt.event.ActionEvent

extends AWTEvent

  • ActionEvent( Object source, int id, String command )

    Erzeugt ein ActionEvent mit einer Quelle, die das Ereignis ausgelöst hat, einem Identifizierer und einem Kommando.

HttpServletRequest und HttpServletResponse und die Header

Sendet der HTTP-Client eine Anfrage an den Server, so sendet er gleichzeitig einige Informationen über sich mit. Sie nennen sich Header und bezeichnen Schlüssel-Werte-Paare, die durch einen Doppelpunkt getrennt sind. Ein Webbrowser kann zum Beispiel Folgendes formulieren:

GET /seminare/index.html HTTP/1.0
Accept-Language: de

Der Browser sendet hier den Header Accept-Language mit dem Wert de. So kann der Server unter Auswertung dieser Parameter optimal reagieren, zum Beispiel bei der Präferenz der Sprache eine lokalisierte Webseite liefern. Um an die Header zu gelangen, müssen wir das HttpServletRequest-Objekt lesen und die Header erfragen.

Header auslesen

Zum Lesen der Header in einem Servlet bieten sich zwei Lösungen an: Wenn wir einen speziellen Header erfragen wollen, dann holen wir mit getHeader() auf dem HttpServletRequest den passenden Wert zum Schlüssel. Sind wir an allen Schlüsseln interessiert, dann besorgt uns getHeaderNames() eine Enumeration. Die können wir dann durchlaufen und die Werte wiederum mit getHeader() auslesen. Falls ein Schlüssel nicht existiert, liefert die Methode null. Ähnlich wie bei getParameter() können hier auch mehrere Einträge existieren, die mit getHeaders() abgerufen werden können.

<%
java.util.Enumeration headerNames = request.getHeaderNames();
while ( headerNames.hasMoreElements() )
{
String headerNameKey = (String) headerNames.nextElement();
String headerNameValue = request.getHeader( headerNameKey );
%>
<%= headerNameKey %>: <%= headerNameValue %>
<p>
<%
}
%>

Das Servlet erzeugt für eine Anfrage etwa folgende Ausgabe:

accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
accept-language: de
accept-encoding: gzip, deflate
user-agent: Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 5.0)
host: localhost:8080
connection: Keep-Alive
cookie: JSESSIONID=EB9D8DFAB0D0AA1B38D292507983B6B1

Der Anfragetyp (GET, POST und so weiter) wird hier ebenso wenig angezeigt wie der Remote-Host. Dieser findet sich nicht im Header und muss mit anderen Funktionen erfragt werden.

Hilfsfunktion im Umgang mit Headern

Wieder gibt es für oft benutzte Header Abkürzungen.

  • getMethod() liefert eine Zeichenkette wie GET oder POST.
  • Die Methode getRequestURI() liefert die URI der Anfrageseite.
  • getProtocol() liefert das Protokoll von der Statuszeile, also heutzutage entweder HTTP/1.0 oder HTTP/1.1.
  • getCookies() liefert den Inhalt des Cookie-Headers (dazu später mehr).
  • getAuthType() und getRemoteUser() zerteilen die Information im Authorization-Feld in Komponenten.
  • getDateHeader() und getIntHeader() sind wieder Hilfsmethoden.

Übersicht der Browser-Header

Hier eine Übersicht über die üblichen Header, von denen wir manche schon aus dem Beispiel und auch vom Server kennen:

  • Accept. Der vom Browser bevorzugte MIME-Typ.
  • Accept-Charset. Der vom Browser bevorzugte Zeichensatz.
  • Accept-Encoding. Die Kodierung, die der Browser verarbeiten kann, wie etwa gzip oder compress. Unser Servlet-Programm sollte vor dem Komprimieren testen, ob der Browser überhaupt komprimierte Dateien verarbeiten kann.
  • Accept-Language. Die Sprache, die der Browser bevorzugt anzeigt. Mehr als ein Eintrag, wenn der Browser mehr als eine Sprache spricht.
  • Authorization. Information über Autorisierung, die normalerweise eine Antwort auf die WWW-Authenticate-Anfrage des Servers ist.
  • Connection. Informiert, ob persistente Verbindungen genutzt werden. Persistente Übertragungen übermitteln in einer TCP/IP-Verbindung mehrere Dateien, etwa eine HTML-Datei und mehrere Grafiken. Wenn der Wert von Connection »Keep-Alive« heißt, dann lassen sich mit einer Netzwerkverbindung mehrere Seitenteile übermitteln. Wenn die Request-Zeile die http-Version 1.1 anzeigt, sind Keep-Alive-Verbindungen Standard. Unsere Aufgabe bei diesen Verbindungen ist es, den Header ContentLength in die Antwort zu setzen. Server-abhängig wird hier teilweise schon automatisch in einen Puffer geschrieben und die Größe gesetzt. Dies muss aber nicht so sein, daher bietet es sich an, die Informationen in einen ByteArrayOutputStream zu schreiben, um später die Länge und den Inhalt abzufragen.
  • Content-Length. Die Länge des Bytestroms. Hier zählt der Browser die Bytes und informiert den Server, wie viele Daten noch kommen.
  • Cookie. Cookie-Information, die der Browser automatisch mitschickt.
  • From. Ein optionaler Header, der oft von Webrobotern gesetzt wird. Bei Browsern nicht üblich.
  • Host. Rechnername und Host, wie in der Original-URL angegeben.
  • If-Modified-Since. Liefert ein neues Server-Dokument, wenn die im Header angegebene Zeit auf ein neueres Dokument verweist. Ist das Browser-Dokument aktueller, gibt der Server den Antwortcode 304 mit der Nachricht »Not Modified« zurück.
  • Pragma. Gibt Informationen über das automatische Neuladen der Seiten. Der Wert no-cache zeigt an, dass der Server immer eine neue Seite liefern soll, auch wenn der Proxy eine Kopie hält.
  • Referer. Die URL mit dem Verweis, der auf die aktuelle Seite gezeigt hat.
  • User-Agent. Der Browsertyp. Praktisch, wenn unser Servlet JavaScript-Code einbettet, der vom Browser abhängig ist.
  • UA-Pixels, UA-Color, UA-OS, UA-CPU. Von Microsoft eingeführte proprietäre Header für den Internet Explorer, die Bildschirmgröße, Farbtiefe, Betriebssystem und CPU-Typ anzeigen.

Header, die der Server setzt

Bisher kennen wir von der Klasse HttpServletResponse die Methode setHeader() für beliebige Header.

Beispiel: Setze den Header pragma, damit vom Browser keine Daten im Cache gehalten werden:

response.setHeader( "pragma", "no-cache" );

Mit dieser Aufforderung soll der Browser die Seite jedes Mal neu laden. Das ist bei dynamischen Seiten besonders wichtig, da sie bei jedem Aufruf neu generiert werden und sich Werte ändern können, wie es zum Beispiel bei Warenkorbsystemen der Fall ist. Da wir uns als Applikationsentwickler nicht immer mit dem Namen der Header herumärgern wollen, bietet die Bibliothek einige Spezialfunktionen an.

Beispiel: Für den Header Content-Type gibt es die spezielle Methode setContentType():

response.setHeader( "Content-Type", "text/html");
response.setContentType( "text/html" );

Daneben gibt es setContentLength(), die den Header Content-Length setzt. Diese Länge muss nicht gesetzt werden und wird automatisch berechnet. Falsche Längen könnten zu Ausnahmesituationen führen. Der Gebrauch ist jedoch nützlich, wenn vorher die gesamte Webseite in einem StringBuffer sb gesammelt und in einem Rutsch übertragen wird. Dann können wir setContentLength(sb.length()) aufrufen.

Um einen Datums-Header zu setzen, existiert setDateHeader(String, long). Das Argument ist eine beliebige Zeichenkette, die mit einem Datumswert verbunden wird. Das long gibt die Millisekunden seit dem 1.1.1970 an. Die erzeugte Ausgabe schreibt einen UTC-String. Eine weitere Hilfsfunktion ist setIntHeader(), die Zahlenwerte mit Schlüsseln in den Header schreibt. Hier übernimmt die Methode die Konvertierung von String in eine Ganzzahl.

Neben diesen setXXX()-Methoden, die möglicherweise gesetzte Header überschreiben, lässt sich mit containsHeader(String) abfragen, ob Wertepaare schon gesetzt sind. Neben den setXXX()-Methoden gibt es auch entsprechende addXXX()-Methoden, die die Werte nicht überschreiben, sondern hinzufügen. Für Cookies existiert eine zusätzliche Methode namens addCookie(), die einen Cookie im Header setzt.

Mit Locking Dateien sperren

Damit eine Datei gegen konkurrierenden parallelen Zugriff geschützt ist, lässt sie sich über Locking absichern. Um einen Lock für Dateien zu erwerben bietet die Java-API ein FileLock-Objekt. So ein FileLock bekommt ein Programm von der Methode lock() eines FileChannels – ein FileChannel wiederum kommt von getChannel(), einer Methode, die FileInputStream, FileOutputStream oder RandomAccessFile anbieten.

Beispiel: Öffne eine Datei, erzeuge exklusiven Zugriff, und schreibe Daten:

FileOutputStream fos = new FileOutputStream( file );

try ( FileLock fileLock = fos.getChannel().tryLock() ) {

  fos.write( … );

}

Hinweis: Die übliche Schreibweise OutputStream fos funktioniert natürlich nicht, da ein allgemeiner OutputStream keine getChannel()-Methode bietet.

Die lock(…)-Methode liefert als Ergebnis ein FileLock-Objekt. Das wiederum bietet einige Methoden, wobei für uns nur release() bzw. close() interessant sind, die den Lock wieder freigeben. FileLock implementiert die Schnittstelle AutoCloseable, sodass ein FileLock auch auch try-mit-Ressourcen verwendet werden kann, wie im Beispiel geschehen.

Um zu testen, ob eine gegebene Datei gelockt ist, lässt sich tryLock() verwenden – etwa mit der folgenden statischen Hilfsmethode:

public static boolean isLocked( String filename ) {

  try ( RandomAccessFile raf = new RandomAccessFile( filename, "rw" ); FileLock lock = raf.getChannel().tryLock() ) {

    // Nothing to do here

  }

  catch ( IOException e ) {

    return false;

  }

  return true;

}

Die Methoden tryLock(…) und lock(…) liefern FileLock-Objekt und diese Ressource muss immer korrekt geschlossen werden.

Hinweis: Unter Unix-Systemen gibt es kein eindeutig vorgeschriebenes Verfahren zum File-Locking[1], sodass Oracle das Sperren bisher nur so umsetzt, dass zwei Java-Programme sich gegenseitig nicht in die Quere kommen, es aber sein kann, dass ein anderes Unix-Programm diesen Lock nicht respektiert. So kann unter Unix eine Datei von mehreren Seiten gelesen werden, selbst wenn ein Java-Programm sie aktuell beschreibt. Auch kann eine Datei auf dem Dateisystem gelöscht werden, selbst wenn das Java-Programm sie noch offen hält. Das Windows-Betriebssystem unterstützt hingegen Locks. Wenn ein Prozess keinen Lock auf die Datei besitzt, kann der Prozess die Datei auch nicht lesen.


[1] Zum Beispiel mit dem Alleskönner fcntl() aus dem POSIX-Standard oder flock() von 4.2 BSD.

try-mit-Ressourcen auf null-Ressourcen

Das immer zum Abschluss eines try-mit-Ressourcen-Blocks ein close() aufgerufen wird ist nicht ganz korrekt; es gibt nur dann ein Schließversuch, wenn die Ressource ungleich null ist.

Beispiel

Der Codebaustein compiliert und führt zu einer Konsolenausgabe.

try ( Scanner scanner1 = null; Scanner scanner2 = null ) {

  System.out.println( "Ok" );

}

Bei Konstruktoren ist ein Objekt ja immer gegeben, aber es gibt auch Fabrikaufrufe, bei denen vielleicht null herauskommen kann, und für diese Fälle ist es ganz praktisch, dass try-mit-Ressourcen dann nichts macht, um eine NullPointerException beim close() zu vermeiden.

Swing-Beschriftungen eine andere Sprache geben

Die Swing-Komponenten sind von Haus aus lokalisiert. So begegnet dem Anwender ein Dateiauswahldialog unter dem deutschen System auch mit deutschen Beschriftungen. Die Sprache lässt sie über das passende Locale-Objekt ändern. So setzt für neue Komponenten folgendes die Sprache auf Arabisch:

JComponent.setDefaultLocale( new Locale("ar") );

Mit der Änderung auf eine Sprache, die von rechts nach links schreibt, ist automatisch eine Umsortierung der Komponenten verbunden, wenn diese zum Beispiel in einem Container mit FlowLayout liegen.

Ändern der Zeichenfolgen

Die Zeichenketten selbst werden aus einer Ressourcen-Datei gelesen und sind im UIManager präsent.

Beispiel: Um die deutsche Beschriftung »Suchen in:« im Dateiauswahldialog zu ersetzen, ist die Eigenschaft FileChooser.lookInLabelText zu setzen:

UIManager.put( "FileChooser.lookInLabelText" ,"Worin'e suchen tust:" );
new JFileChooser().showOpenDialog( null );
System.exit( 0 );

Eine Liste aller zu setzenden Properties ist etwa auf der Webseitehttp://www.rgagnon.com/javadetails/JavaUIDefaults.txt aufgelistet.

Um für alle Programme die Änderungen gültig zu machen, sollten für das verwendete Look and Feel.properties-Dateien angelegt werden. Die Dateien müssen dann im Programmpfad stehen. So sehen die Dateipfade für Windows und Metal folgendermaßen aus:

  • com/sun/java/swing/plaf/windows/resources/windows_de.properties
  • javax/swing/plaf/metal/resources/metal_de.properties

Die Dateien sind die bekannten Ressourcen-Dateien mit den Schlüsseln, die in JavaUIDefaults.txtgenannt sind.

Beispiel: Um unter dem Windows-Look and Feel global einen Bezeichner für den Dateiauswahldialog zu ändern, setzen wir in windows_de.properties:

FileChooser.lookInLabelText=Worin'e suchen tust:

Mit dem MediaTracker arbeiten

Der MediaTracker ist eine sehr alte Java-AWT-Klasse, bietet aber Dinge, über die auch einfachere Bildlademethoden nicht verfügen. Ein paar Details.

Um ein MediaTracker-Objekt zu erzeugen, rufen wir seinen Konstruktor mit einem einzigen Parameter vom Typ Component auf:

MediaTracker tracker = new MediaTracker( this );

Wenn wir Applet oder Frame erweitern, kann dies – so wie im Beispiel – der this-Zeiger sein. Dies zeigt aber schon die Einschränkung der Klasse auf das Laden von Bildern, denn was hat eine Musik schon mit einer Komponente zu tun?

Bilder beobachten

Nachdem ein MediaTracker-Objekt erzeugt ist, fügt die addImage(Image)-Methode ein Bild in eine Warteliste ein. Eine weitere überladene Methode addImage(Image, Gruppe ID) erlaubt die Angabe einer Gruppe. Dieser Identifizierer entspricht gleichzeitig einer Priorität, in der die Bilder geholt werden. Gehören also Bilder zur gleichen Gruppe, ist die Priorität immer dieselbe. Bilder mit einer niedrigeren Gruppennummer werden mit einer niedrigeren Priorität geholt als Bilder mit einer höheren ID. Eine dritte Methode von addImage() erlaubt die Angabe einer Skalierungsgröße. Nach dieser wird das geladene Bild skaliert und eingefügt. Sehen wir uns einmal eine typische Programmsequenz an, die dem Medienüberwacher ein Hintergrundbild sowie einige animierte Bilder überreicht:

Image bg     = getImage( "background.gif" ),
      anim[] = new Image[MAX_ANIM];

MediaTracker tracker = new MediaTracker( this );
tracker.addImage( bg, 0 );

for ( int i = 0; i < MAX_ANIM; i++ ) {
 anim[i] = getImage( getDocumentBase(), "anim" + i + ".gif" );
 tracker.addImage( anim[i], 1 );
}

Das Hintergrundbild wird dem MediaTracker-Objekt hinzugefügt. Die ID, also die Gruppe, ist 0. Das Bild-Array anim[] wird genauso gefüllt und überwacht. Die ID des Felds ist 1. Also gehören alle Bilder dieser Animation zu einer weiteren Gruppe.

Um den Ladeprozess anzustoßen, benutzen wir eine der Methoden waitForAll() oder waitForID(). Die waitForID()-Methode wird benutzt, um Bilder mit einer bestimmten Gruppe zu laden. Die Gruppennummer muss natürlich dieselbe vergebene Nummer sein, die bei der addImage()-Methode verwendet wurde. Beide Methoden arbeiten synchron, bleiben also so lange in der Methode, bis alle Bilder geladen wurden oder ein Fehler beziehungsweise eine Unterbrechung auftrat. Da das also das ganze restliche Programm blockieren würde, werden diese Ladeoperationen gerne in Threads gesetzt. Wie diese Methoden in einem Thread verwendet werden, zeigt das folgende Programmsegment. Der Block ist idealerweise in einer run()-Methode platziert oder, bei einem Applet, in der init()-Methode.

try {
  tracker.waitForID( 0 );
  tracker.waitForID( 1 );
}
catch ( InterruptedException e ) { return; }

Die waitForID()-Methode wirft einen Fehler aus, falls sie beim Ladevorgang unterbrochen wurde. Daher müssen wir unsere Operationen in einen try- und catch-Block setzen.

Während das Bild geladen wird, können wir seinen Ladezustand mit den Methoden checkID()überprüfen. checkID() bekommt als ersten Parameter eine Gruppe zugeordnet und überprüft dann, ob die Bilder, die mit der Gruppe verbunden sind, geladen wurden. Wenn ja, gibt die Methode true zurück, auch dann, wenn der Prozess fehlerhaft ist oder abgebrochen wurde. Ist der Ladeprozess noch nicht gestartet, dann veranlasst checkID(Gruppe) dies nicht. Um dieses Verhalten zu steuern, regt die überladene Funktion checkID(Gruppe, true) das Laden an. Beide geben false zurück, falls der Ladeprozess noch nicht beendet ist.

Eine weitere Überprüfungsfunktion ist checkAll(). Diese arbeitet wie checkID(), nur, dass sie auf alle Bilder in allen Gruppen achtet und nicht auf die ID angewiesen ist. Wie checkID() gibt escheckAll() ebenfalls in zwei Varianten. Die zweite startet den Ladeprozess, falls die Bilder noch nicht geladen wurden.

Die MediaTracker-Klasse verfügt über vier Konstanten, die verschiedene Flags vertreten, um den Status des Objekts zu erfragen. Einige der Methoden geben diese Konstanten ebenso zurück.

Konstante

Bedeutung

LOADING

Ein Medien-Objekt wird gerade geladen

ABORTED

Das Laden eines Objekts wurde unterbrochen

ERRORED

Ein Fehler trat während des Ladens auf

COMPLETE

Das Medien-Objekt wurde erfolgreich geladen

Tabelle: Flags der Klasse MediaTracker

Mit der Methode statusID(), welche ja den Zustand des Ladens überwacht, können wir leicht die Fälle herausfinden, in denen das Bild erfolgreich beziehungsweise nicht erfolgreich geladen werden konnte. Dazu verknüpfen wir einfach durch den Und-Operator die Konstante mit dem Rückgabewert vonstatusAll() oder statusID():

if ( (tracker.statusAll() & MediaTracker.ERRORED) != 0 )

Wie wir sehen, können wir durch solche Zeilen leicht herausfinden, ob bestimmte Bilder schon geladen sind. MediaTracker.COMPLETE sagt uns "ja", und wenn ein Fehler auftritt, dann ist der Rückgabewert MediaTracker.ERRORED. Wir wollen diese Flags nun verwenden, um in einer paint()-Methode das Vorhandensein von Bildern zu überprüfen, und wenn möglich, diese dann anzuzeigen. Erinnern wir uns daran, dass in der Gruppe 0 ein Hintergrundbild lag und in Gruppe 1 die zu animierenden Bilder. Wenn ein Fehler auftritt, zeichnen wir ein rotes Rechteck auf die Zeichenfläche und signalisieren damit, dass etwas nicht funktioniert.

public void paint( Graphics g )
{
  if ( tracker.statusID(0, true) == MediaTracker.ERRORED )
  {
    g.setColor( Color.RED );
    g.fillRect( 0, 0, size().width, size().height );
    return;
  }
  g.drawImage( bg, 0, 0, this );
  if ( tracker.statusID(1) & MediaTracker.COMPLETE) )
    g.drawImage( anim[counter%MAX_ANIM], 50, 50, this );
}

class java.awt.MediaTracker

implements Serializable

  • static final int ABORTED

    Flag, welches anzeigt, dass das Medium nicht geladen werden konnte. Rückgabewert von statusAll() oder statusID().
  • static final int ERRORED

    Während des Ladens gab es Fehler. Rückgabewert von statusAll() und statusID().
  • static final int COMPLETE

    Medium konnte geladen werden. Rückgabewert von statusAll() und statusID().
  • MediaTracker( Component comp )

    Erzeugt einen MediaTracker auf einer Komponente, auf der das Bild möglicherweise angezeigt wird.
  • void addImage( Image image, int id )

    Fügt ein Bild nichtskaliert der Ladeliste hinzu. Ruft addImage(image, id, -1, -1) auf.
  • void addImage( Image image, int id, int w, int h )

    Fügt ein skaliertes Bild der Ladeliste hinzu. Soll ein Bild in einer Richtung nicht skaliert werden, ist -1 einzutragen.
  • public boolean checkAll()

    Überprüft, ob alle vom MediaTracker überwachten Medien geladen worden sind. Falls der Ladeprozess noch nicht angestoßen wurde, wird dieser auch nicht initiiert.
  • boolean checkAll( boolean load )

    Überprüft, ob alle vom MediaTracker überwachten Medien geladen worden sind. Falls der Ladeprozess noch nicht angestoßen wurde, wird dieser dazu angeregt.
  • boolean isErrorAny()

    true, wenn eines der überwachten Bilder einen Fehler beim Laden verursachte.
  • Object[] getErrorsAny()

    Liefert eine Liste aller Objekte, die einen Fehler aufweisen. null, wenn alle korrekt geladen wurden.
  • void waitForAll() throws InterruptedException

    Das Laden aller vom MediaTracker überwachten Bilder wird angestoßen, und es wird so lange gewartet, bis alles geladen wurde oder ein Fehler beim Laden oder Skalieren auftritt.
  • boolean waitForAll( long ms ) throws InterruptedException

    Startet den Ladeprozess. Die Funktion kehrt erst dann zurück, wenn alle Bilder geladen wurden oder die Zeit überschritten wurde. true, wenn alle korrekt geladen wurden.
  • int statusAll( boolean load )

    Liefert einen mit Oder verknüpften Wert der Flags LOADING, ABORTED, ERRORED und COMPLETE. Der Ladeprozess wird bei load auf true gestartet.
  • boolean checkID( int id )

    Überprüft, ob alle Bilder, die mit der ID id verbunden sind, geladen wurden. Der Ladeprozess wird mit dieser Methode nicht angestoßen. Liefert true, wenn alle Bilder geladen sind oder ein Fehler auftrat.
  • boolean checkID( int id, boolean load )

    Wie checkID(id). Allerdings werden nur die Bilder geladen, die bisher noch nicht geladen wurden.
  • boolean isErrorID( int id )

    Liefert den Fehlerstatus von allen Bildern mit der ID id. true, wenn eines der Bilder beim Laden einen Fehler aufweist.
  • Object[] getErrorsID( int id )

    Liefert eine Liste aller Medien, die einen Fehler aufweisen.
  • void waitForID( int id ) throws InterruptedException

    Startet den Ladeprozess für die gegebene ID. Die Methode wartet solange, bis alle Bilder geladen sind. Bei einem Fehler oder Abbruch wird angenommen, dass alle Bilder ordentlich geladen wurden.
  • boolean waitForID( int id, long ms ) throws InterruptedException

    Wie waitForID(), nur stoppt der Ladeprozess nach einer festen Anzahl von Millisekunden.
  • int statusID( int id, boolean load )

    Liefert einen mit Oder verknüpften Wert der Flags LOADING, ABORTED, ERRORED und COMPLETE. Ein noch nicht geladenes Bild hat den Status 0. Ist load gleich true, dann werden die Bilder geladen, die bisher nocht nicht geladen wurden.
  • void removeImage( Image image )

    Entfernt ein Bild von der Liste der Medienelemente. Dabei werden alle Objekte, die sich nur in der Skalierung unterscheiden, entfernt.
  • public void removeImage( Image image, int id )

    Entfernt das Bild mit der ID id von der Liste der Medienelemente. Dabei werden auch die Objekte entfernt, bei denen sich die Bilder nur in der Skalierung unterscheiden.
  • public void removeImage( Image image, int id, int width, int height )

    Entfernt ein Bild mit den vorgegebenen Ausmaßen und der ID id von der Liste der Medienelemente. Doppelte Elemente werden ebenso gelöscht.

Alles wird bunt mit Farbmodellen

Ein besonderer Produzent, der sich um alles kümmert, was das Bilderzeugen angeht, ist der Image Producer. Im Gegensatz dazu sind es die Image Consumer, die etwaige Bilddaten benutzen. Bei den Produzenten- und Konsumentenmodell von Image-Objekten stehen die Daten der Pixel immer in einem Byte- oder Integer-Feld zur Verfügung und stehen im Mittelpunkt des Interesses. Oft übersprungen wird das Farbmodell bei MemoryImageSource und einem createImage(). Doch das wollen wir uns nun genauer anschauen.

Die Einträge der Felder sind Pixel, und die Werte standen für Farbinformationen, genauer gesagt für Rot, Grün und Blau. Stillschweigend wird angenommen, dass diese in 24 Bit abgelegt sein müssen. Dies muss jedoch nicht so sein, und die Interpretation der Farbwerte in einem Informationswort bestimmt ein Farbmodell. Für Farbmodelle gibt es in Java die Klasse ColorModel. Mit der Klasse lassen sich dann aus einem Pixel die roten, grünen, blauen und transparenten Anteile bestimmen. Der transparente Teil, auch Alpha-Komponente genannt, bestimmt, in welcher Intensität die Farbinformationen wirken. Alpha-Werte lassen sich nur in Zusammenhang mit Bildern anwenden. Mit der Graphics-Klasse lässt sich ein Alpha-Wert nicht einstellen, der dann alte Zeichenoperationen beeinflusst. Bei den Farbmodellen ist der Anteil der Transparenz genauso lang wie ein Farbwert, nämlich acht Bit. Ein Wert von 255 sagt aus, dass der Farbwert zu 100% sichtbar ist. Ist der Wert 0, so ist die Farbe nicht zu sehen.

Java macht das Programmierleben so plattformunabhängig wie möglich. Bei wenigen oder vielen Farben auf der Zielplattform wird eine optimale Annäherung an unsere Wunschfarben errechnet. So können wir alles in 24 Bit Farbtiefe errechnen, die Dislay-Komponente sucht die wichtigsten Farben heraus und fasst Gruppen ähnlicher Farben zusammen.

Die abstrakte Klasse ColorModel

Die abstrakte Klasse ColorModel beschreibt alle Methoden für konkrete Farbklassen, sodass die Informationen über die Farbwerte und die Transparenz erreichbar sind. Obwohl die Klasse abstrakt ist, besitzt sie zwei Konstruktoren, die von den Unterklassen benutzt werden. Direkte Unterklassen sind ComponentColorModel, IndexColorModel und PackedColorModel.

abstract class java.awt.image.ColorModel
implements Transparency

  • ColorModel( int pixel_bits, int bits[], ColorSpace cspace, boolean hasAlpha, boolean isAlphaPremultiplied, int transparency, int transferType )
  • ColorModel(int bits)

Der zweite Konstruktor ist praktisch, da dieser nur die Farbtiefe in Bits erwartet. Diese abstrakte Klasse besitzt jedoch die statische Fabrik-Methode getRGBdefault(), die ein ColorModel-Objekt zurückliefert. Das Standardfarbmodell, auch sRGB genannt, ist ein Farbmodell, welches die Werte als 24-Bit-Tupel mit den Komponenten Alpha, Rot, Grün und Blau enthält. Dieses Farbmodell lässt sich etwa für ein Memory-Image einsetzen. Der erste Konstruktor ist noch leistungsfähiger und seit Java 1.2 dabei. Mit seiner Hilfe muss ein Farbwert nicht zwingend in einem Integer kodiert sein.

Die Methode getPixelSize() liefert die Farbtiefe eines Farbmodells. Das Standardmodell besitzt eine Tiefe von 32 Bit (24 für die Farben und dann noch den Alpha-Kanal). So gibt auch die folgende Zeile als Anwort auf die Frage nach der Anzahl der Farben im Standardmodell 32 Bit aus:

System.out.println( ColorModel.getRGBdefault().getPixelSize() );

Die Hauptaufgabe einer Farbmodell-Klasse ist die Auswertung der Farbinformationen aus einem Speicherwort. Mit drei Methoden lassen sich die verschiedenen Farben auslesen. getRed(int pixel), getGreen(int pixel) und getBlue(int pixel), hinzu kommt noch getAlpha(int pixel). Jede dieser Methoden ist abstrakt und liefert eine Ganzzahl mit dem Farbwert zurück. Wie wir später sehen werden, ist das einfachste Modell genau jenes, das wir bisher immer benutzt haben. Dieses liest nämlich genau von den Stellen 24, 16 und 8 die Farbwerte aus. Da die Methoden abstrakt sind, müssen Unterklassen dieses Verhalten programmieren.

Eine weitere Methode ist getRGB(), welche ein int mit allen Farben im entsprechenden Farbformat zurückliefert. Die Implementierung basiert auf den Anfrage-Methoden.

public int getRGB(int pixel) {
  return (getAlpha(pixel) << 24) | (getRed(pixel) << 16) | (getGreen(pixel) << 8) | (getBlue(pixel) << 0);
}

Im Folgenden eine Auflistung der wichtigsten Methoden:

abstract class java.awt.image.ColorModel

implements Transparency

  • abstract int getAlpha( int pixel )

    Liefert den Alpha-Wert im Bereich 0 bis 255.
  • abstract int getBlue( int pixel )

    Liefert den Blauanteil des Pixels.
  • ColorSpace getColorSpace()

    Liefert den Farbraum, der mit dem ColorModel verbunden ist.
  • int[] getComponents( int pixel, int components[], int offset )

    Liefert ein Feld mit nicht normalisierter Farb- und Alpha-Komponente für ein Pixel.
  • abstract int getGreen( int pixel )

    Liefert den Grünanteil.
  • int getNumColorComponents()

    Gibt die Anzahl der Farben zurück.
  • int getNumComponents()

    Liefert die Anzahl der Komponenten (mit Alpha).
  • int getPixelSize()

    Wie viele Pixel beschreiben eine Farbe?
  • abstract int getRed( int pixel )

    Liefert den Rotanteil.
  • int getRGB( int pixel )

    Gibt Farb- und Alpha-Komponente des Pixels im sRGB-Farbmodell wieder.
  • static ColorModel getRGBdefault()

    Liefert ein DirectColorModel mit dem sRGB-Modell.
  • int getTransparency()

    Liefert die Art der Transparenz. Dies ist entweder OPAQUE, BITMASK oder TRANSLUCENT. Es sind Konstanten aus der Schnittstelle Transparency. Sie können aber auch über ColorModel verwendet werden, da ColorModel diese Schnittstelle implementiert.
  • boolean hasAlpha()

    Fragt an, ob das Farbmodell Transparenz unterstützt.
  • boolean isCompatibleRaster( Raster raster )

    Liefert true, falls das Raster mit dem Farbmodell kompatibel ist.

Nun lassen sich auf der Basis dieser Klassen verschiedene Farbmodelle entwerfen. Einige sind von den Entwicklern der Java-Bibliotheken schon vorgefertigt, wie etwa eine Farbklasse, die die Informationen gleich im Pixel selbst speichert, wie im Beispiel RGB, oder eine Klasse, die einen Index auf einen Farbwert verwaltet. Als eigene Ergänzung können wir Farbklassen implementieren, die Graustufen direkt unterstützen oder etwa andere Farbräume wie HSB (Hue, Saturation, Brightness). Die einzige Aufgabe, die uns als Implementierer der abstrakten Methoden übrig bleibt, ist, die Farbwerte aus dem Pixelwert zu extrahieren. Im Fall von HSB ist das einfach. Die Methoden getRed(), getGreen() und getBlue() müssen nur aus dem internen HSB-Wert den Anteil liefern.

Farbwerte im Pixel mit der Klasse DirectColorModel

Mit Hilfe der Klasse DirectColorModel werden die Farbwerte Rot, Grün, Blau und Alpha direkt aus dem Farbtupel extrahiert. Die Klasse gehört zu einer der größten im Image-Paket. Als Beispiel für das direkte Format kennen wir Standard-RGB. Für dieses gilt, dass die Farben jeweils acht Bit in Anspruch nehmen. Das muss aber nicht so sein, und im Konstruktor von DirectColorModel lässt sich bestimmen, wie und an welcher Stelle die Bits für die Farben sitzen. Wir dürfen dies jedoch nicht damit verwechseln, dass wir die Anzahl der Bits angeben. Nur die Positionen sind möglich. Daraus ergibt sich auch, dass die Werte zusammenhängend sind und nicht etwa Folgendes auftreten kann: 0xrrbgbg. Die Bitanzahl kann aber für die Farben unterschiedlich sein. Auch der Alpha-Wert kann frei gewählt werden. Für das Standardmodell ergibt sich eine einfache Zeile:

DirectColorModel rgbModel = new DirectColorModel(32,
0xff0000, 0x00ff00, 0x0000ff, 0xff000000);

Ist das Objekt einmal angelegt, so sind nun die Anfrage-Methoden wie getRed() möglich, da DirectColorModel als konkrete Klasse, von der auch ein Exemplar erzeugt werden kann, diese abstrakten Methoden alle überschreibt und mit Implementierung versieht. Eine wichtige Eigenschaft dieser Methoden ist, dass sie final sind und ihren Farbwert mit dem Alpha-Wert kombinieren. Da sie final sind, können sie von Unterklassen nicht mehr überschrieben werden. Letzteres verlangt aber die aktuelle Implementierung der AWT-Bibliothek.

Beispiel Implementierung von getRed()

final public int getRed(int pixel) {
  int r = ((pixel & maskArray[0]) >>> maskOffsets[0]);
  if (scaleFactors[0] != 1.)
    r = (int)(r * scaleFactors[0]);
  if (isAlphaPremultiplied) {
    int a = getAlpha(pixel);
    r = (a == 0) ? 0 : (r * 255/a);
  }
  return r;
}

Im Parameter pixel ist die Farbe Rot an einer Bitposition (meistens ab 24 Bit) abgelegt. Damit wir diesen Wert auslesen und mit dem Alpha-Wert kombinieren können, muss er zunächst ausmaskiert werden. Daher wird pixel mit der Maske verknüpft, sodass nur die Bits übrig bleiben, die auch wirklich die Farbe Rot beschreiben. Anschließend verschieben wir die Rot-Pixel so weit nach rechts, dass die Grün- und Blau-Werte verschwinden. Die Felder maskArray und maskOffsets sowie scaleFactors sind in der direkten abstrakten Oberklasse PackedColorModel angelegt. Doch bleiben wir bei getRed(). Hier sehen wir noch deutlich, wie der Alpha-Wert in die Berechnung mit eingeht. Ist der Farbwert 0, so ist auch das Ergebnis 0. Ist er ungleich 0, so wird die Farbe nach dem Apha-Wert gewichtet. Der Skalierungsfaktor skaliert die Werte auf 256. Denn haben wir beispielsweise nur zwei Bits für einen Farbwert, dann müssen wir mit 128 multiplizieren, um wieder eine Acht-Bit-Darstellung zu bekommen.

Die Klasse IndexColorModel

Im Gegensatz zur Klasse DirectColorModel verwaltet ein IndexColorModel die Farben und Transparenzen nicht im Pixel, sondern in einer eigenen Tabelle, die auch Color-Map oder Palette genannt wird. Das Modell ist vergleichbar mit dem Dateiformat GIF. Dort stehen maximal 256 Farben in einer Tabelle zur Verfügung und alle Punkte in einem GIF-Bild müssen einer dieser Farben entsprechen. Eine GIF-Datei mit zwei Farben definiert etwa eine Farbe mit schweinchenrosa und eine zweite Farbe mit hornhautumbra. Der Pixel selbst ist dann nur ein Index auf einen Eintrag. Dieses Verfahren ist sehr speicherschonend, ein Kriterium, das vor ein paar Jahrzehnten noch zählte. An Stelle von 24 Bit für einen Pixel wird der Index etwa zehn Bit breit gemacht und stellt dann bis zu 1.024 Farben dar. Das ist immerhin eine Reduktion des Bildschirmspeichers um die Hälfte. Leider sind damit aber auch hohe Berechnungskosten verbunden. Für eine Verwendung dieser Klasse spricht die Abstraktion von den konkreten Farben. Ein Beispiel dafür wäre ein Fraktalprogramm. Einer berechneten Zahl wird direkt ein Farbwert zugeordnet. Somit lässt sich leicht eine Farbverschiebung programmieren, die sich auf Englisch color-cycle nennt.

Wenn wir ein IndexColorModel verwenden wollen, geben wir im Konstruktor eine Anzahl Bits pro Pixel zusammen mit einer Tabelle an, die die Komponenten Rot, Grün und Blau sowie optional die Transparenzen enthält. Die Farbtabelle, die über einen Index die Farbe verrät, kann maximal 256 Farben aufnehmen. Dies ist leider eine Einschränkung, beschränkt aber den Speicher, da nur ein byte an Stelle eines short belegt wird.

class java.awt.image.IndexColorModel

extends ColorModel

  • IndexColorModel( int bits, int size,

    byte r[], byte g[], byte b[], byte a[] )
  • IndexColorModel( int bits,int size,

    byte r[], byte g[], byte b[], int trans )
  • IndexColorModel( int bits, int size

    byte r[], byte g[], byte b[] )
  • IndexColorModel( int bits, int size, byte cmap[],

    int start, boolean hasalpha, int trans )
  • IndexColorModel( int bits, int size, byte cmap[],

    int start, boolean hasalpha )
  • IndexColorModel( int bits, int size, int cmap[],

    int start,boolean hasalpha, int trans,

    int transferType )

An den Konstruktoren lässt sich ablesen, dass mehrere Wege gegangen werden können. Die Farben können als Einzelfelder einem IndexColorModel übergeben werden oder als zusammengepacktes Feld. Dann erfolgt die Speicherung nach dem Standard-RGB-Modell. Vorsicht ist bei einem Alpha-Wert geboten. Dieser folgt nach dem Blauton. So ist die Reihenfolge bei Transparenz 0xRRGGBBAA. Das ist sehr verwirrend, da wir es gewohnt sind, den Alpha-Wert vor dem Rotwert zu setzen.

Intern werden die Werte in einem Feld gehalten. Der erste Wert gibt die Anzahl der Bits an, die einen Pixel beschreiben. Er darf acht Bit nicht überschreiten, da die Längenbeschränkung 2^8 = 256 maximale Farben vorgibt. Der nächste Wert size ist die Größe der Tabelle. Sie sollte mindestens 2^bits groß sein. Andernfalls werden Farben fehlerhaft zugeordnet. Präziser heißt dies, dass sie Null sind, da ja der new-Operator das Feld automatisch mit Null-Werten belegt. Sind in der Farbtabelle Apha-Werte abgelegt, dann sollte hasalpha den Wert true annehmen. Sind alle Werte in einer Tabelle, berechnet sich der Farbwert zu einem Index wie folgt: Betrachten wir keinen Alpha-Wert und unser Pixel hat den Wert f(arbe),

  • dann ist der Rotwert an der Stelle colorMap[start+3*f] und
  • der Grünwert an der Stelle colorMap[start+3*f+1] und
  • der Blauwert schließlich bei colorMap[start+3*f+2].

Um Informationen über die internen Werte und die Größe der Tabelle zu erhalten, reicht ein toString(). Die Größe der Tabelle liefert die Methode getMapSize().

Mit den finalen Methoden getReds(byte redArray[]), getGreens(byte greenArray[]), getBlues(byte blueArray[]) und getAlphas(byte alphaArray[]), deren Rückgabewert void ist, lassen sich die Farbinformationen auslesen und als Ergebnis in das Feld legen. Die Felder müssen schon die passende Größe haben, die sich jedoch mit final int getMapSize() erfragen lässt. Die Methode getTransparentPixel() liefert den Index des transparenten Pixels. Gibt es keinen, ist der Wert -1.

Werfen wir zur Demonstration noch einen Blick auf die Methode getGreens(). Wir sehen deutlich, dass das Feld eine passende Größe haben muss.

final public void getGreens(byte g[]) {
  for (int i = 0; i < map_size; i++)
  g[i] = (byte) (rgb[i] >> 8);
}

An getRed() sehen wir ebenso, dass der Pixel auch direkt ein Index für das private Feld rgb ist. Wenn der Index über die Feldgröße läuft, müssen wir den Fehler selbst behandeln.

final public int getRed(int pixel) {
  return (rgb[pixel] >> 16) & 0xff;
}

Wenden wir unsere Aufmerksamkeit auf ein Programm, welches ein Bytefeld erzeugt und aus sechs Farben die Pixel in das Feld schreibt. Zum Schluss konvertieren wir das Bytefeld mit einem MemoryImageSource in ein Image-Objekt. Für diese Klasse können wir ein IndexColorModel angeben, das dann folgendes Format hat:

ColorModel cm = IndexColorModel( 8, colorCnt, r, g, b );

Hier handelt es sich um ein Farbmodell mit acht Bits und sechs Farben. Die folgenden Werte zeigen auf die drei Felder mit den Farbwerten. Anschließend erzeugt createImage() mit diesem Farbmodell das Image-Objekt.

Image i = createImage( new MemoryImageSource(w,h,cm,pixels,0,w) );

Zum kompletten Beispiel:

import java.awt.*;
import java.awt.image.*;

public class IndexColorModelDemo extends Frame
{
  Image i;
  private final static int w = 400, h = 400;

  int pixels[] = new int [w*h];

  Color colors[] = {
    Color.red, Color.orange, Color.yellow, Color.green, Color.blue, Color.magenta
  };

  IndexColorModelDemo()
  {
    int colorCnt = colors.length;

    byte r[] = new byte[colorCnt],
    g[] = new byte[colorCnt],
    b[] = new byte[colorCnt];

    for ( int i = 0; i < colorCnt; i++ ) {
      r[i] = (byte) colors[i].getRed();
      g[i] = (byte) colors[i].getGreen();
      b[i] = (byte) colors[i].getBlue();
    }

    int index = 0;
    for ( int y = 0; y < h; y++ )
      for ( int x = 0; x < w; x++ )
        pixels[index++] = (int)(Math.random() * colorCnt);
    i = createImage( new MemoryImageSource( w, h, new IndexColorModel(8, colorCnt, r, g, b), pixels, 0, w) );
  }

  public void paint( Graphics g )
  {
    if ( i != null )
      g.drawImage( i, 0, 0, this );
  }

  public static void main( String args[] )
  {
    IndexColorModelDemo d = new IndexColorModelDemo();
    d.setSize( w, h );
    d.show();
  }
}

Offtopic: Forward Secrecy

Mit den NSA-Enthüllungen nimmt es kein Ende, und so rücken  noch schärfere Algorithmen in den Vordergrund, etwa bei SSL auf Forward Secrecy zu setzen. Kurz gesagt geht es darum, den geheimen Schlüssel, mit dem beide Parteien ihre Daten verschlüsseln, so zu bilden, dass der Schlüssel nach der Verbindung verfällt. Heise weißt unter http://www.heise.de/security/artikel/Zukunftssicher-Verschluesseln-mit-Perfect-Forward-Secrecy-1923800.html etwa darauf hin. Meiner Bank, der 1822direkt, habe ich eine E-Mail geschickt und bin gespannt auf die Antwort, denn die nutzt das laut https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fwww.1822direkt.com%2F nicht. Ich denke jeder solle “seine” Diente einmal abklopfen und die Provider darauf hinweisen FS zu nutzen.

2 Tage, am Sonntag abend, kommt die erste Antwort der Bank:

Leider wird die Klärung des Vorganges noch etwas Zeit in Anspruch nehmen. Sobald wir ein abschließendes Ergebnis vorlegen können, werden wir Sie umgehend informieren

Es dauerte noch ein paar Tage und dann kann die undetailierte Antwort:

Sie haben eine Frage zu unseren Sicherheitszertifikaten gestellt, die wir Ihnen gerne beantworten. Die von Ihnen genannte Situation ist uns bekannt. Die angegebene Prüfseite wird von uns, neben anderen Prüfseiten, regelmäßig verwendet. Momentan müssen wir hierbei zwischen dem Schutz vor mannigfaltigen Attacken sowie Browserunterstützung abwägen. Im unwahrscheinlichen Fall, dass sich ein Angreifer Zugriff verschaffen kann, sind unsere Sicherheitsschlüssel zusätzlich geschützt. Wir bitten um Ihr Verständnis, dass wir Ihnen hierzu aus Sicherheitsgründen keine detaillierteren Informationen erteilen können.

Der Verweis auf den Browser ist natürlich irreführend, denn Server und Browser „verhandeln“ das jeweilige Verfahren auf und wie die SSL-Lab-Seite schön zeigt, bietet der Server gewisse Verfahren an da kann Foward Secrecy natürlich noch dazukommen.

Ziemliches fettes Java-Problem….

… wenn man die Systemzeit im laufenden Java-Betrieb ändert. In den letzten Tagen kam die Diskussion auf der Java-Champ-Liste auf, hier noch einmal zusammengefasst: http://bbossola.wordpress.com/2013/09/04/jvm-issue-concurrency-is-affected-by-changing-the-date-of-the-system/, http://bbossola.wordpress.com/2013/09/05/jvm-issue-concurrency-is-affected-by-changing-the-date-of-the-system-part-2/

Tiefe Objektkopien (Deep Copy)

Die clone() Methode liefert nur flache Kopien eines Objektes. Mit Hilfe der Serialisierung kommt man schnell auch zu tiefen Kopien. Klassen können die clone() Methode von Object überschreiben und so eine Kopie der Werte liefern. Die Standardimplementierung ist jedoch so angelegt, dass diese Kopie flach ist, was bedeutet, Referenzen auf Objekte die von dem zu klonenden Objekt ausgehen, werden beibehalten und diese Objekte nicht extra kopiert. Als Beispiel kann die einfache Datenstruktur eines Feldes genügen, welches auf Vector Objekte verweiset. Eine Klon dieses Feldes ist lediglich ein zweites Feld, dessen Elemente auf die gleichen Vektoren zeigen. Eine Änderung wird also beiden Felder bewusst.

Möchten wir das Verhalten ändern und eine tiefe Kopie anfertigen, so haben wir mit einem kleinen Trick keine Mühe damit. Die Idee ist, dass wir das zu klonende Objekt einfach Serialisieren und dann wieder auspacken. Die zu klonenden Objekte müssen dann nur das Serializable Interface implementieren.

public static Object deepCopy( Object o ) throws Exception
{
  ByteArrayOutputStream baos = new ByteArrayOutputStream();
  new ObjectOutputStream( baos ).writeObject( o );

  ByteArrayInputStream bais = new ByteArrayInputStream( baos.toByteArray() );

  return new ObjectInputStream(bais).readObject();
}

Das einzige was wir zum Gelingen der Methode deepCopy() machen müssen, ist das Objekt in ein Bytefeld zu serialisieren und dann wieder auszulesen und zu einem Objekt konvertieren. Den Einsatz eines ByteArrayOutputStream haben wir schon gesehen, als wir die Länge eines Objektes herausfinden wollten. Nur fügen wir nun das Feld wieder einem ByteArrayInputStream zu, aus dessen Daten dann der ObjectInputStream wieder das Objekt rekreieren kann.

Überzeugen wir uns an Hand eines kleines Programms, dass die tiefe Kopie tatsächlich etwas anderes als ein clone() ist. (Verwendet werden Raw-Types um das Bsp. kurz zu halten.)

public static void main( String args[] ) throws Exception
{
  Map map = new HashMap() {{
    put( "Cul de Paris", "hinten unter dem Kleid getragenes Gestell oder Polster" );
  }};

  LinkedList l1 = new LinkedList(); 
  l1.add( map );

  List l2 = (List) l1.clone();

  List l3 = (List) deepCopy( l1 );

  map.clear();

  System.out.println( l1 );
  System.out.println( l2 );
  System.out.println( l3 );
}

Zunächst erstellen wir eine Map, die wie anschießend in eine Liste packen. Die Map enthält ein Pärchen. Klonen wir mit clone() die Liste, so wird zwar die Liste selbst kopiert, aber nicht die Map. Die tiefe Kopie kopiert neben der Liste auch gleich die Map mit. Das sehen wir dann, wenn wir den Eintrag aus dem Map löschen. Dann ergibt l1 genauso wie l2 eine leere Liste, da l2 zur die Verweise auf die Map gespeichert hat, die dann aber geleert ist. Anders ist dies bei l3, der tiefen Kopie; hier ist das Paar noch vorhanden. Die Ausgabe ist dann:

[{}]
[{}]
[{Cul de Paris=hinten unter dem Kleid getragenes Gestell...}]

An diesem Beispiel sehen wir, wie wunderbar die Stream-Klassen zusammenarbeiten. Einzige Voraussetzung zum Gelingen ist die Implementierung der Schnittstelle Serializable. Da aber die zu klonenden Klassen auch clone() implementieren müssen, gilt in der Regel, dass sie serialisierbar sind. Daher steht in der implements Zeile die Schnittstelle Clonable und Serializable direkt nebeneinander.

Doppelpufferung (Double-Buffering)

Stellt eine paint()-Methode (und damit paintComponent()) komplexe Zeichnungen dar, die zum Beispiel aus hunderten kleiner Linien und Bögen besteht, so braucht das seine Zeit. Zeichnen wir in paint() immer alles neu, so haben wir große Zeitverzögerungen, wenn sich etwa die Größe des Zeichenbereichs ändert und der Repaint-Manager über ein repaint() wieder zum paint() führt und alles wieder neu gezeichnet wird, ohne dass sich wirklich etwas an der Grafik geändert hat.

Eine einfache und elegante Methode, diesem Problem zu entkommen, ist die Technik der Doppelpufferung (engl. double-buffering). Eine zweite Zeichenebene, so groß wie das Original, wird angelegt und alle Grafikoperationen finden auf diesem Hintergrundbild statt. Immer wenn das zu zeichnende Bild komplett ist, kopieren wir es zur passenden Zeit in den sichtbaren Bereich. Kommt ein Repaint-Ereignis, und hat sich die Grafik bis dahin nicht aktualisiert, so muss nur der entsprechende Teil der Hintergrundgrafik neu gezeichnet werden.

Um ein Programm auf die neue Technik umzustellen, muss zuerst die paint()-Methode umgebaut werden, die direkt die Zeichenbefehle erteilt. Nehmen wir folgende Implementierung an:

private void bigPaint( Graphics g )
{
 Random r = new Random();

 for ( int i = 0; i < 1000; i++ )
 {
  g.drawOval( r.nextInt(getWidth()-100), r.nextInt(getHeight()-100), 100, 100 );
  g.setColor( new Color(r.nextInt(255), r.nextInt(255), r.nextInt(255), r.nextInt(255)) );
 }
}

@Override protected void paintComponent( Graphics g )
{
 bigPaint( g );
}

Um das Programm schon etwas zu vereinfachen, enthält paintComponent() nun schon keine direkten Zeichenbefehle mehr, sondern delegiert an das eigene bigPaint(). Im nächsten Schritt müssen wir das Programm so umbauen, dass es auf das Graphics-Objekt unseres Hintergrundbildes geht. Dazu ist zuerst ein Hintergrundbild nötig. Eine Variante ist, die den Hintergrundpuffer in paintComponent() aufzubauen, denn dann gibt es Zugriff auf die Höhen und Breiten, die sich verändert haben können – natürlich kann auch die Fläche immer gleich groß bleiben.

import java.awt.*;
import java.awt.image.BufferedImage;
import java.util.Random;
import javax.swing.JFrame;
import javax.swing.JPanel;

public class DoubleBuffering extends JPanel
{
 private void bigPaint( Graphics g )
 {
  g.setColor( Color.WHITE ); g.fillRect( 0, 0, getWidth(), getHeight() );

  Random r = new Random();

  for ( int i = 0; i < 1000; i++ )
  {
   g.drawOval( r.nextInt(getWidth()-100), r.nextInt(getHeight()-100), 100, 100 );
   g.setColor( new Color(r.nextInt(255), r.nextInt(255), r.nextInt(255), r.nextInt(255)) );
  }
 }

 private final GraphicsConfiguration gfxConf = GraphicsEnvironment
                         .getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration();

 private BufferedImage offImg;

 @Override protected void paintComponent( Graphics g )
 {
  if ( offImg == null || offImg.getWidth() != getWidth() || offImg.getHeight() != getHeight() )
  {
   offImg = gfxConf.createCompatibleImage( getWidth(), getHeight() );
   bigPaint( offImg.createGraphics() );
  }

  g.drawImage( offImg, 0, 0, this );
  // bigPaint( g );
 }

 public static void main( String[] args )
 {
  JFrame f = new JFrame();
  f.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
  f.setSize( 800, 600 );
  f.add( new DoubleBuffering() );
  f.setVisible( true );
 }
}

Hinweis: Oft fällt ein Flackern bei Grafikoperationen auf. Das Problem ist, dass die Zeichenoperationen so lange dauern, dass die gesamte Zeichnung nicht im Zyklus einer Bildschirmwiederholfrequenz auf den Schirm kommt. Während Teile gezeichnet werden, sendet die Grafikkarte die Teilbilder zum Display und bei jedem Update sehen wir einen aktualisierten Teil unserer Grafik. Bei aufwändigen Zeichenoperationen sind nun einmal viele Durchläufe nötig, bis das Bild komplett ist.

Kleine Kekse: die Klasse javax.servlet.http.Cookie

Der Server kann den Client veranlassen, diese Information eine bestimmte Zeit lang zu speichern. Betritt der Client die Seite des Anbieters, schickt er dem Server den Cookie als Kennung. Dieser kann anhand der Cookie-Kennung die Sitzung erkennen, sofern er die Information gesichert hat. Name und Technologie der Cookies wurden von Netscape geprägt, als die Firma noch den Browser-Markt revolutionierte. Mittlerweile kümmert sich die HTTP Working Group der Internet Engineering Task Force (IETF) um die Weiterentwicklung.

Das Wort »Cookie« wird gerne mit Keksen assoziiert, was aber nicht beabsichtigt ist. Informatiker kennen den Begriff und meinen damit einfach nur kleine Informationseinheiten. Mehr Informationen rund um Cookies hat David Whalen auf seiner Seite http://www.cookiecentral.com/ gesammelt.

Cookies erzeugen und setzen

Cookies werden für den Benutzer durch die Klasse Cookie verwaltet. Sie bietet Methoden zur Bearbeitung der Informationen, die der Cookie speichert. Damit wir auf der Clientseite Cookies setzen können, müssen wir zunächst ein Cookie-Objekt erzeugen. Dazu bietet die Klasse genau einen Konstruktor mit zwei Parametern an, die dem Cookie einen Namen und einen Wert geben. Der Name muss nach RFC 2109 geformt sein, das heißt vereinfacht aus Buchstaben und Ziffern. Nun muss der Cookie beim Client gesetzt werden. Dies führt die Methode addCookie() auf dem HttpServletResponse-Objekt durch:

Cookie cookie = new Cookie( "key", "value" );
response.addCookie( cookie );

Da es mehrere Einträge geben kann, darf die Methode auch mehrmals aufgerufen werden.

interface javax.servlet.http.HttpServletResponse extends ServletResponse

  • public void addCookie( Cookie cookie )

    Fügt der Antwort einen Cookie-Header zu.

Cookies vom Servlet einlesen

Bei jeder weiteren Kommunikation mit einem Server werden die mit der Server-URL assoziierten Cookie-Daten automatisch mitgeschickt. Um sie zu erfragen, bemühen wir die Methode getCookies() des HttpServletRequest-Objekts. Der Rückgabewert der Methode ist ein Feld von Cookie-Objekten. Jeder Cookie bietet als Objektmethode getName() und getValue() an, um an die Schlüssel-Werte-Paare zu gelangen. Wenn die getCookies()-Methode null liefert, so war noch kein Cookie angelegt, und wir müssen darauf reagieren.

<%@ page import="java.util.*" %>
<%
 String myCookieName = "visited";
 Cookie[] cookies = request.getCookies();
 if ( cookies == null )
 out.println( "Kein Cookie gesetzt!" );
 else {
  boolean visited = false;
  for ( int i = 0; i < cookies.length; i++ ) {
   String cookieName = cookies[i].getName();
   if ( cookieName.equals(myCookieName) )
    visited = true;
%>
Cookie "<%= cookieName %>" hat den Wert "<%= cookies[i].getValue() %>"
<br>
<%
  }
  if ( !visited ) {
   Cookie visCookie = new Cookie( myCookieName, new java.util.Date().toString() );
   response.addCookie( visCookie );
   out.println( "Cookie gesetzt" );
  }
 }
%>

Bekommt der Server eine Anforderung vom Client, kennt der Client natürlich die Server-Adresse. Er schaut in seinem Cookie-Speicher nach, ob mit diesem Server ein Cookie assoziiert ist. Dann schickt er diesen automatisch in einem speziellen Cookie-Feld mit, sodass der Server diesen Wert auslesen kann. Cookies sind für andere Server nicht sichtbar, sodass sie keine direkte Sicherheitslücke darstellen.

Cookie-Status ändern

Im Cookie werden neben einem Namen und dem damit verbundenen Wert noch weitere Informationen gespeichert. Die folgende Aufzählung zeigt die Zugriffsmethoden für Cookies:

class javax.servlet.http.Cookie

implements java.lang.Cloneable

  • void setComment( String purpose )
  • String getComment()

    Eine zusätzliche Beschreibung für einen Cookie, der nicht von jedem Browser unterstützt wird (beispielsweise von Netscape). Bei der Abfragemethode bekommen wir null, falls dem Cookie kein Kommentar zugewiesen wurde.
  • setDomain( String pattern )
  • String getDomain()

    Der Gültigkeitsbereich eines Cookies. Der Domänenname beginnt mit einem Punkt (etwa .kuchenfuerulli.com) und gilt dann für alle direkten Rechner dieser DNS-Adresse, also etwa www.kuchenfuerulli.com, aber nicht a.b.kuchenfuerulli.com.
  • int getMaxAge()
  • setMaxAge() legt fest, wie lange der Cookie existieren soll (in Sekunden). Ist der Wert negativ, wird der Cookie nicht gespeichert, sondern nach der Sitzung, also beim Schließen des Browsers, entfernt. getMaxAge() liefert die Lebensdauer eines Cookies, wobei die oben getätigten Aussagen auch hier zutreffen.
  • void setPath( String uri )
  • public String getPath()

    Der Pfad gibt den Ort für den Client an, an dem der Cookie sichtbar ist. Die Sichtbarkeit gilt für das angegebene Verzeichnis und alle Unterverzeichnisse. Zusätzliche Informationen sind in RFC 2109 abgelegt.
  • void setSecure( boolean flag )
  • public boolean getSecure()

    Mit einer sicheren Verbindung lassen sich Cookies nur über ein sicheres Protokoll wie HTTPS oder SSL übertragen. setSecure(true) sendet den Cookie daher nur, wenn ein sicheres Protokoll verwendet wird. getSecure() liefert false, wenn der Browser den Cookie durch ein beliebiges Protokoll senden kann.
  • void setName( String name )
  • String getName()

    Der Name des Cookies, der nach der Erzeugung nicht mehr geändert werden kann.
  • void setValue( String newValue )
  • String getValue()

    Jeder Cookie speichert einen Wert, der mit setValue() neu gesetzt werden kann, sofern der Cookie existiert. Bei einem binären Wert müssen wir selbstständig eine ASCII-Kodierung finden, zum Beispiel eine BASE64-Kodierung. Mit Cookies der Version 0 sind die Zeichen › ‹, ›(‹, ›)‹, ›[‹, ›]‹, ›=‹, ›,‹, ›’‹, ›"‹, ›\‹, ›?‹, ›@‹, ›:‹, ›;‹ nicht zugelassen. Nicht gesetzte Werte können unterschiedliche Rückgaben des Browsers provozieren.
  • int getVersion()
  • void setVersion( int v )

    Die Version des Cookies, wie in RFC 2109 beschrieben. Version 0 hält sich an die Originalspezifikation von Netscape. Die Version 1 wird in RFC 2109 beschrieben; die Variante ist noch etwas experimentell.

Langlebige Cookies

Für Cookies, die länger als eine Sitzung halten sollen, lässt sich mit setMaxAge() eine Zeit setzen, zu der sie gültig sein sollen. Eine praktische Klasse ist MaxAgeCookie, die im parametrisierten Konstruktor das Alter auf die Höchstzahl von einem Jahr setzt. Dies müssen aber nicht alle Browser so implementieren.

import javax.servlet.http.*;

public class MaxAgeCookie extends Cookie
{
 public MaxAgeCookie( String name, String value )
 {
  super( name, value );
  setMaxAge( 60*60*24*365 );
 }
}

Schnelle Vergleiche mit CollatorKeys

Landestypische Vergleiche können mit der Collator-Klasse gemacht werden. Eine Geschwindigkeitssteigerung ergibt sich durch Collator-Keys. Obwohl sich mit der Collator Klasse sprachspezifische Vergleiche korrekt umsetzen lassen, ist die Geschwindigkeit gegenüber einem normalen String-Vergleich schlechter. Daher bietet die Collator Klasse die Objektmethode getCollationKey() an, die ein CollationKey Objekt liefert, der schnellere Vergleiche zulässt.

Collator col = Collator.getInstance( Locale.GERMAN );
CollationKey key1 = col.getCollationKey( "ätzend" );
CollationKey key2 = col.getCollationKey( "Bremsspur" );

Durch CollationKeys lässt sich die Performance bei Vergleichen zusätzlich verbessern, da der landesspezifische String in einen normalen Javastring umgewandelt wird, der dann schneller verglichen werden kann. Dieses bietet sich zum Beispiel beim Sortieren einer Tabelle an, wo mehrere Vergleiche mit dem gleichen String durchgeführt werden müssen. Der Vergleich wird mit compareTo(CollationKey) durchgeführt. Der Vergleich von key1 und key2 im Beispiel lässt sich demnach durch folgende Zeile ausdrücken:

int comp = key2.compareTo( key1 );

Das Ergebnis ist wie bei der compare() Methode bei Collator Objekten <0, 0 oder >0.

class java.text.CollationKey implements Comparable

  • int compareTo( CollationKey target )

    Vergleicht zwei CollationKey Objekte miteinander.
  • int compareTo( Object o )

    Vergleicht den aktuellen CollationKey mit dem angegeben Objekt. Ruft compareTo((CollationKey)o) auf.
  • boolean equals( Object target )

    Testet die beiden CollationKey Objekte auf Gleichheit.
  • String getSourceString() 
    Liefert den String zum CollationKey.
  • int hashCode()

    Berechnet den Hashcode für den CollationKey.
  • byte[] toByteArray()

    Konvertiert den CollationKey in eine Folge von Bits.

abstract class Collator implements Comparator, Cloneable

  • abstract CollationKey getCollationKey( String source )

    Liefert einen CollationKey für den konkreten String.