Seitdem JDBC 2.0 die SQL3-Datentypen unterstützt, sind weitere Spaltentypen über Java-Programme zugänglich:

• ARRAY. Der Datentyp erlaubt eine Aufzählung mehrerer Werte wie ein Feld in einer Spalte.
• STRUCT. Neue benutzerdefinierte Typen – auch UDTs (user-defined types) genannt –, die auf der Datenbankseite mit der SQL-Anweisung CREATE TYPE angelegt werden.
• REF. Verweise auf strukturierte Typen.

Am Nützlichsten ist das Feld.

ARRAY

SQL-Felder werden in JDBC durch die Schnittstelle java.sql.Array behandelt. Nehmen wir in einer Tabelle eine Spalte Aktienverlauf an, die eine Liste (Array) von Zahlen enthält. Aus dem ResultSet gibt dann getArray() Zugriff auf die Informationen:

Array verlauf = rs.getArray( "Aktienverlauf" );

Die Variable verlauf verweist jetzt auf das Array-Objekt, was dem SQL ARRAY entspricht. Die Werte können nun entnommen werden, doch nicht mit einem Iterator, und auch nicht mit get(index) Funktionen, sondern wieder mit einem Aufruf getArray(). Es liefert ein Feld genau des passenden Typs zurück.

String[] verläufe = (String[]) verlauf.getArray();
for ( int i = 0; i < verläufe.length; i++ )
  ...

Neben dem lesenden getArray() setzt setArray() ein Feld, und updateArray() aktualisiert die Werte.

Bei eigenen Java-Programmen ist es wichtig, dass diese sich so perfekt wie möglich in die Reihe der anderen Client-Programme einordnen, ohne großartig aufzufallen. Dafür muss ein Fenster die globalen Einstellungen wie den Zeichensatz und die Farben kennen. Für die Systemfarben gibt es die Klasse SystemColor, die alle Farben einer grafischen Oberfläche auf symbolische Konstanten abbildet. So ist SystemColor.text[1] die Hintergrundfarbe von Texteingabefeldern. Besonders praktisch ist dies bei Änderungen von Farben während der Laufzeit. Über diese Klasse können immer die aktuellen Werte eingeholt werden, denn ändert sich beispielsweise die Hintergrundfarbe der Laufleisten, ändert sich damit auch der RGB-Wert.

Die Systemfarben sind Konstanten von Typ SystemColor, was eine Unterklasse von Color ist. Damit lassen sich sich direkt nutzen, etwa über setColor(Color) oder über getRGB() der RGB-Anteil erfragen. Die Klasse SystemColor hat keine eigenen öffentlichen Methoden, sondern überschreibt nur toString().

Die Klasse deklariert die folgenden statischen finalen Variablen:

class java.awt.SystemColor extends Color implements Serializable

Konstanten der Systemfarben

Hinweis: Die Klasse javax.swing.UIManager ist ein großer Assoziativspeicher, bei dem sich weitere Belegungen erfragen lassen. Es erfragt zum Beispiel UIManager.getColor("Table.background") die Tabellen-Hintergrundfarbe vom gerade eingestellen Look and Feel.[2]

[1] Sun verstößt mal wieder gegen die eigenen Namenskonventionen. Die finalen Variablen – Konstanten – sollten großgeschrieben werden. Das funktioniert bei den SystemColor-Objekten aber nicht, da es alle Bezeichnernamen schon in Großbuchstaben gibt, und zwar für Variablen vom Typ Byte, die Verweise in eine interne Tabelle darstellen.

[2] Die Seite http://www.devdaily.com/java/java-uimanager-color-keys-list liefert eine Auflistung der Schlüssel und ein Programm zur Anzeige.

Um herauszufinden, welche Zeichensätze auf einem System installiert sind, liefert getAvailableFontFamilyNames() auf einem GraphicsEnvironment ein Feld mit Font-Objekten. Ein Objekt vom Typ GraphicsEnvironment beschreibt die Zeichensätze des Systems und liefert GraphicsDevice-Objekte. Ein GraphicsDevice ist eine Malfläche, also das, worauf das System zeichnen kann. Das kann der Bildschirm sein, aber auch ein Drucker oder eine Hintergrundgrafik. Die statische Fabrikmethode getLocalGraphicsEnvironment() liefert ein solches GraphicsEnvironment-Objekt.

Beispiel: Im folgenden Codesegment gibt eine Schleife alle Zeichensatznamen aus:

for ( String fonts : GraphicsEnvironment.
        getLocalGraphicsEnvironment().getAvailableFontFamilyNames() )
  System.out.println( fonts );

Auf meinem System liefert die Schleife die folgenden Ausgaben:

Arial

Arial Black

Arial Narrow

…

Wingdings

Wingdings 2

Wingdings 3

Zur API:

abstract class java.awt.GraphicsEnvironment

• static GraphicsEnvironment getLocalGraphicsEnvironment()
  Liefert das aktuelle GraphicsEnvironment-Objekt.
• abstract Font[] getAllFonts()
  Liefert ein Feld mit allen verfügbaren Font-Objekten in einer Größe von einem Punkt.
• abstract String[] getAvailableFontFamilyNames()
  Liefert ein Feld mit allen verfügbaren Zeichensatzfamilien.
• abstract String[] getAvailableFontFamilyNames(Locale l)
  Liefert ein Feld mit verfügbaren Zeichensatzfamilien, die zu einer Sprache l gehören.

In der Graphics-Klasse gibt es keine Methode, um regelmäßige n-Ecken zu zeichnen. Eine solche Methode ist aber leicht und schnell programmiert: Wir teilen dazu einfach einen Kreis in n Teile auf und berechnen die x- und y-Koordinaten der Punkte auf dem Kreis. Diese Punkte fügen wir einem Polygon-Objekt mittels der addPoint(…)-Methode hinzu. Eine eigene statische Methode drawVertex(…) übernimmt diese Polygon-Erstellung. Der letzte Parameter der Methode ist ein Wahrheitswert, der bestimmt, ob das n-Eck gefüllt werden soll oder nicht:

package com.tutego.insel.ui.graphics;

import java.awt.*;
import javax.swing.*;

public class N_Vertex extends JPanel {

  private static final long serialVersionUID = -6314283966378303073L;

  @Override protected void paintComponent( Graphics g ) {
    VertexDrawer.drawVertex( g, getWidth() / 2, getHeight() / 2, 50, 6, true );
    VertexDrawer.drawVertex( g, getWidth() / 2, getHeight() / 2, 60, 6, false );
  }

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

class VertexDrawer {
  public static void drawVertex( Graphics g, int x, int y, int r, int n, boolean filled ) {
    Polygon p = new Polygon();

    for ( int i = 0; i < n; i++ )
      p.addPoint( (int) (x + r * Math.cos( i * 2 * Math.PI / n )),
                  (int) (y + r * Math.sin( i * 2 * Math.PI / n )) );

    if ( filled )
      g.fillPolygon( p );
    else
      g.drawPolygon( p );
  }
}

Änderungen unter http://java.sun.com/javase/6/webnotes/6u21.html.

Interessantere Dinge:

Support for Customized Loading Progress Indicators

With Java SE 6u21, you can now enhance the loading experience of an application by providing a customized loading progress indicator (sometimes referred to as a progress bar) to better inform the end user of how much of the application has been downloaded during startup. See the following topics for more information:

• Customizing the Rich Internet Application Loading Experience
• Customizing the Loading Experience topic in the Java Tutorials

 

Java VisualVM

Java VisualVM based on VisualVM 1.2.2 is included in Java SE 6u21. This release introduces the following features and enhancements:

• HeapWalker performance improvements
• VisualVM-Sampler performance improvements
• BTrace4VisualVM plugin introduces BTrace 1.1
• Profiling engine bugfixes
• Built on NetBeans Platform 6.8

For more information, refer to the VisualVM releases page.

http://java.sun.com/javase/6/webnotes/BugFixes6u21.html

Kurz nach 19er Update, was einige Verbesserungen mit sich brachte, kommt das Update 20 mit nur 3 kleinen Änderungen nach. Im Wesentlichen handelt es sich um den Fix vom Bug http://www.oracle.com/technology/deploy/security/alerts/alert-cve-2010-0886.html.

• http://java.sun.com/javase/6/webnotes/6u20.html
• http://java.sun.com/javase/6/webnotes/ReleaseNotes.html
• http://java.sun.com/javase/downloads/index.jsp

Die Änderungen http://java.sun.com/javase/6/webnotes/6u18.html sind vielfältig. Zum einen für die Systemkonfigurationen:

• Ubuntu 8.04 LTS Desktop Edition for both JFB and Java SE (x86) in 32-bit
• SLES 11
• Windows 7 support is now available
• Red Hat Enterprise Linux 5.3

Dann:

• VisualVM 1.2 is included in 1.6.0_18. Mehr unter https://visualvm.dev.java.net/relnotes121.html

Im JDK gibt es ein Update der Datenbank

• Java DB 10.5.3.0

Aus dem Bereich XML:

• JSR-173 StAX 1.2 API Upgrade. In erster Linie JavaDoc Korrekturen aber auch Änderungen, da der richtige Klassenlader nun genutzt wird. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6861589

Und vieles mehr im Bereich Tuning und Fehlerbehebung.

Das geht nicht wirklich und wenn, dann nur mit großen Umwegen etwa über die Java Debugging API, mit der man sich an die JVM hängen kann. Auch ein Blick auf den Quellcode von jconsole und jmap/jhat helfen hier, weil die Tools genau das machen und Zahlen geben.

Der Objektgraf verändert sich ständig und so könnte man auch die Objekte stark referenzieren und den GC am Löschen hindern. Das würde zu einer großen Anzahl von Problemen führen. (Schwache Referenzen könnte das Problem abmildern, aber der GC muss hier Zusatzarbeit machen und die Laufzeit würde sich (messbar) verschlechtern.) Die Objekte sind ja immer eine Momentaufnahme. Da kämen ja Millionen von Objekten raus, wenn man etwa nach „Gib mir alle Strings“ fragt. Laufend ändert sich diese Menge.

Wenn der Nutzer diese Instanzen wirklich braucht, kann er sie an einer Objekt-Registry anmelden.

• Von Hand kann man Exemplare etwa in eine Map<Class,List<?>> setzen. Das muss man nicht unbedingt manuell machen, sondern man kann hier einen Aspekt schreiben, der Bytecode in den Konstruktor für solch ein Anmelden einfügt. Dann ist das Abmelden aber noch so eine Sache. Das kann aber eine PhantomReference übernehmen und so meldet man das Objekt an der Registry wieder ab.
• Wenn man Spring benutzt, deklariert ListableBeanFactory (implementiert etwa von XmlBeanFactory) eine Methode Map getBeansOfType(Class type) für genau diesen Fall.
• Sind die Exemplare alle MBeans, ist es einfach, dann sind sie schon an einem Container registriert, und Query liefert sie sogar nach gewissen Kriterien.

Änderungen listet http://java.sun.com/javase/6/webnotes/6u14.html auf. Interessant sind meines Erachtens: Compressed Object Pointers und Garbage First (G1) Garbage Collector, weil diese Dinge sind, die für Java 7 vorgesehen waren. Aber nun kann man die schon mal “in the wild” testen, was eine gute Sache ist. Dann noch JAX WS 2.1.6 and JAXB 2.1.10 und ein Update von JavaDB (wobei Derby schon deutlich weiter ist, komisch).