Bei invokedynamic sind viel weniger Typinformationen nötig wie bei den anderen vier existierenden Bytecodes für Methodenaufrufe. Generiert wird der Bytecode zum Beispiel von Skriptsprachen, wenn Typinformationen fehlen. Die Compiler der Skriptsprachen nutzen Bytecode-Bibliotheken wie ASM (http://asm.ow2.org/) und umgehen den Java-Compiler zur Erstellung der Klassendateien.

Der neue Bytecode ist die eine Seite. Aber wenn die Typinformationen fehlen, insbesondere der wichtige Empfänger (wie PrintStream bei println()), wie kommt die JVM zur wirklichen Implementierung? Etwa bei unserem Beispiel von isEmpty(s), in dem es ein invokedynamic-Aufruf von s.length() gibt. Der Aufruf muss ja irgendwo landen.

function isEmpty(s) { return s == null || s.length() == 0; }

Zwei Dinge sind hier zusätzlich nötig. Das erste ist, dass es neben dem Aufruf von invokedynamic noch eine zusätzliche Information im Bytecode gibt, nämlich von einer Bootstrap-Methode. Findet die JVM zum ersten Mal ein invokedynamic, dann weiß sie nicht, an wen der Aufruf geht und wendet sich an die Bootstrap-Methode. Zur passenden Auswahl der Zielmethode übergibt die JVM an die Bootstrap-Methode Informationen über Aufrufer und Name, sodass alle wichtigen Informationen zur Auswahl des Ziels vorhanden sind. Hier sind wir nun in der zweiten Hälfte, denn zusätzlich zum neuen Bytecode gibt es ein neues Paket java.lang.invoke. Die Bootstrap-Methode spezifiziert mit der API des neuen Pakets die Zielmethode und gibt diese an die JVM weiter. Wenn das einmal geschehen ist, ist der Aufruf gebunden und die JVM ruft beim dynamischen Aufruf direkt die vom Bootstrap gelieferte Methode auf. Der genaue Ablauf bei den invokedynamic-Aufrufen dokumentiert das Paket.

Der neue Bytecode muss von einer Java 7-JVM unterstützt werden und wird von dynamischen Skriptsprachen generiert, um die Aufrufe schnell von der JVM ausführen zu lassen. Normale Entwickler werden den neuen Bytecode kaum brauchen, und im Quellcode ist er eh nicht sichtbar.

Neben den von Generics kommenden Kennungen rawtype und unchecked gibt es weitere, die allerdings nicht sonderlich gut dokumentiert sind. Das liegt auch daran, dass Meldungen während der Programmübersetzung zur Compilerinfrastruktur gehören und nicht zur Laufzeitumgebung, und damit nicht zur traditionellen Java-API. Der Compiler kann im Prinzip beliebige Codeanalysen beliebiger Komplexität vornehmen und bei vermuteten Fehlern Alarm schlagen. Um wir dürfen auch nicht vergessen, dass es nur Warnungen sind: wer als Programmierer alles richtig macht, wird die Meldungen nicht zu Gesicht bekommen. Dennoch ist es relevant, sie zu kennen, denn der Compiler wird manches Mal etwas anmerken, was Entwickler bewusst nutzen wollen, und dann gilt es, die Meldungen abzuschalten.

Die Macher vom Eclipse-Compiler (JDT) dokumentieren die unterstützten Warnungen unter http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-suppress_warnings.htm. Neben den aufgeführten Meldungen all, rawtype und unchecked sind folgende noch interessant:

@SuppressWarnings	Unterdrückt Meldungen für
deprecation	veraltete Elemente, wie new java.util.Date(2012-1970, 3, 3).
incomplete-switch	ausgelassene Aufzählungen in swich-case-Anweisungen.
resource	ein nicht geschlossenes AutoClosable, wie new java.util.Scanner(System.in).nextLine().
serial	eine serialisierbare Klasse, die keine Serialisierung-ID besitzt.
unused	nicht benutzte Elemente, etwa nicht aufgerufene private Methoden.

Einige Werte von @SuppressWarnings

BridJ verfolgt den gleichen Ansatz wie JNA, kann also auch aus Java heraus nativen Code von C(++) und auch Objective-C ansprechen. Nur steht es als quelloffene Bibliothek nicht unter der LGPL, sondern unter der BSD/Apache-Lizenz. Zudem ist es aktueller, nutzt Generics (was es abhängig von Java 5 macht, JNA benötigt nur 1.4) und diverse Tricks, um noch performantere native Aufrufe zu realisieren. Auch kann es besser mit den Eigenschaften von C++ umgehen, wie virtuellen Methodenaufrufen, Vererbung und Templates „verstehen“. Regelmäßige Updates gibt es für die Systeme Windows (x86, x64), Linux (x86, x64, arm32), Mac OS X (x86, x64, PPC), Solaris 10 (x86, bald x64 und SPARC), Android 3.0 (ARMv5) und experimentell auf jailbroken iOS iPhones (ARM). Ob das ältere JNA oder BridJ besser ist, muss im Einzelfall evaluiert werden. JNAerator unterstützt ebenfalls BidJ zur Generierung der typisierten Schnittstellen und Übergabeobjekten.

Eine Bibliothek zum Ansprechen dynamischer Bibliotheken ohne JNA-Kontakt und damit ohne C(++)-Compiler ist JNA (Java Native Access). Beheimatet ist das Projekt unter https://github.com/twall/jna/  und es steht unter der Lizenzform LGPL. JNA benötigt nur das Archiv jna.jar im Klassenpfad und geht dann fast von selbst zur dynamischen Bibliotheken. Verschiedene Plattformen werden unterstützt, dazu zählen Windows, Linux und Mac OS X.

Zur dem Zugriff müssen allerdings Java-Schnittstellen als typisierte Versionen der nativen Funktionen deklariert werden, damit auch die Datentypen von der Java-Seite automatisch auf Datentypen der nativen Seite gemappt werden können. Die Dokumentation unter https://github.com/twall/jna/blob/master/www/GettingStarted.md  eigt ein Beispiel (hier etwas gekürzt):

import com.sun.jna.*;

public class HelloWorld {
  public interface CLibrary extends Library {
    CLibrary INSTANCE = (CLibrary) Native.loadLibrary( Platform.isWindows() ? "msvcrt" : "c",
                                                       CLibrary.class );
    void printf( String format, Object... args );
  }

  public static void main( String[] args ) {
    CLibrary.INSTANCE.printf( "Hello, World\n" );
    for ( int i = 0; i < args.length; i++ )
      CLibrary.INSTANCE.printf( "Argument %d: %s\n", i, args[ i ] );
  }
}

Die Übertragung der Funktionen von der C-Seite in Java-Schnittstellen – wie CLibrary in dem Beispiel – kann auch mit JNAerator (http://code.google.com/p/jnaerator/) automatisiert werden.

Neben den Unicode-Blöcken gibt es noch ein anderen Konzept, was vielleicht noch wichtiger als die Blöcke selbst sind: Unicode-Skripte. Darunter ist eine Gruppe von Zeichen für eine Sprache (in der Regel) zu verstehen.[1] Um den Unterschied zu Blöcken noch einmal zusammenzufassen:

· Ein Unicode-Block ist ein einfacher von-bis-Bereich, und Stellen können für die spätere Belegung leer sein.

· Ein Unicode-Skript enthält keine freien Positionen.

· Zeichen eines Unicode-Skripts können aus verschiedenen Unicode-Blöcken stammen.

· Zeichen aus einem Block können in verschiedenen Unicode-Skripten auftauchen.

Auch für Skripte bietet Java in der Klasse Character ein öffentliches statische innere Attribut, wobei das erst seit Java 7 existiert und Oracle hier ein moderneres enum gewählt hat. Character.UnicodeScript besteht aus einer Reihe von Konstanten, wobei die Namen nach ISO 15924[2] gewählt sind. Auch gibt es eine of(int) Methode um das Skript für ein Zeichen zu erfragen und ein UnicodeScript-Objekt kann über forName(String) mit einem Namen aufgebaut werden.

Auch wenn die Character und String-Klasse arm an weiteren Methoden zu den Unicode-Blöcken und Unicode-Skripten ist, gibt es doch Unterstützung von ganz anderer Stellen: Von den regulären Ausdrücken. Sie können testen, ob Zeichen in gewissen Skripten oder Blöcken sind und damit Zeichen in Teilstrings aufspüren, sie löschen und entfernen. (Wir springen nun thematisch etwas vor.) Die Syntax in den regulären Ausdrücken ist \p{script=Skriptname} bzw. \p{block=Blockname} (auch der Präfix Is oder In ist erlaubt ohne Nutzung vom script=/block=-Konstrukt). Achtung, Nicht alle Unicode-Skripts werden unterstützt!

Beispiel

Teste drei Zeichen, ob sie arabisch sind:

System.out.println( "ح".matches( "\\p{script=Arabic}" ) ); // true

System.out.println( "ح".matches( "\\p{IsArabic}" ) ); // true

System.out.println( "ש".matches( "\\p{IsArabic}" ) ); // false

System.out.println( "1".matches( "\\p{IsArabic}" ) ); // false

---

[1] Siehe auch http://www.unicode.org/reports/tr24/.

[2] http://unicode.org/iso15924/iso15924-codes.html

Unicode-Zeichen gehören immer Blöcken an und bei denen ist teilweise immer etwa Platz, um nachrückende Zeichen noch aufnehmen zu können. Beim lateinischen Alphabet ist das nicht so wichtig, wohl aber bei mathematischen Sonderzeichen oder anderen Symbolen.

Die Klasse Character deklariert eine öffentliche statische finale Klasse UnicodeBlock mit einer Vielzahl von Unicode-Blöcken, die als öffentliche statische Variablen in UnicodeBlock deklariert sind und selbst vom Typ UnicodeBlock sind. Character.UnicodeBlock.BASIC_LATIN ergibt zum Beispiel so einen Block, allerdings ist der Typ nicht so ausdrucksstark, nur der Name kommt bei einem toString() dabei raus, aber nicht etwa in welchem Bereich die Zeichen liegen. Auch fehlt die Möglichkeit alle Zeichen aufzuzählen oder zu testen, ob ein Zeichen im Block liegt. Was jedoch der Typ UnicodeBlock bietet sind zwei statische Methoden of(int) und of(char), die als Fabrikfunktionen einen UnicodeBlock für ein gewisses Zeichen geben. Der ist-ein-Element-von-Test lässt sich also damit indirekt realisieren.

Beispiel. Gib die Namen der Unicode-Blöcke für einige Zeichen aus:

UnicodeBlock basicLatin = Character.UnicodeBlock.BASIC_LATIN;

System.out.println( basicLatin );

System.out.println( Character.UnicodeBlock.of( ‚ß‘ ) );

System.out.println( Character.UnicodeBlock.of( ‚\u263A‘ ) );

System.out.println( Character.UnicodeBlock.of( ‚\u20ac‘ ) );

System.out.println( Character.UnicodeBlock.of( 0x1D15E ) );

Das liefert BASIC_LATIN LATIN_1_SUPPLEMENT MISCELLANEOUS_SYMBOLS

CURRENCY_SYMBOLS MUSICAL_SYMBOLS.

Das Wissen um den Bereich ist immer hilfreich dann, wenn ein unbekannter Text zugeordnet werden soll, denn auf diese Weise lässt sich erahnen, ob der Text zum Beispiel auf lateinischen Buchstaben basiert, er arabisch, chinesisch oder japanisch (Kanji/Kana) ist.