Java 7 - Mehr als eine Insel : Das Expertenbuch zu den Java SE Bibliotheken [1., neue Ausg ed.] 3836215071, 9783836215077 [PDF]
150 63 54MB
German Pages 1434 Year 2011
Papiere empfehlen
![Java ist auch eine Insel [10., aktualisierte und überarb. Aufl]
383621802X, 9783836218023](https://vdoc.tips/img/200x200/java-ist-auch-eine-insel-10-aktualisierte-und-uberarb-aufl-383621802x-9783836218023.jpg)
![Java 7 - Mehr als eine Insel : Das Expertenbuch zu den Java SE Bibliotheken [1., neue Ausg ed.]
3836215071, 9783836215077 [PDF]](https://vdoc.tips/img/200x200/java-7-mehr-als-eine-insel-das-expertenbuch-zu-den-java-se-bibliotheken-1-neue-ausgnbsped-3836215071-9783836215077.jpg)
- Author / Uploaded
- Christian Ullenboom
Datei wird geladen, bitte warten...
Zitiervorschau
Christian Ullenboom
Java 7 – Mehr als eine Insel Das Handbuch zu den Java SE-Bibliotheken
Liebe Leserin, lieber Leser, Sie halten die erste Auflage der Insel zu den Java SE-Bibliotheken in den Händen! Ja, es ist ein ganz neues Buch, das es hoffentlich so weit bringen wird wie unsere bewährte Insel zu den Java-Grundlagen, die Sie vielleicht schon kennen. Java wächst und gedeiht, und da wir nicht alles zu Java und seinen Bibliotheken in einem Buch zusammenfassen können, weil dies buchbinderische Grenzen sprengen würde, haben wir uns entschlossen, mit den Ausgaben zu Java 7 zwei umfangreiche und in sich vollständige Werke anzubieten: Ein Einsteiger- und Lehrwerk für Studenten und Auszubildende, die umfassendes Grundlagenwissen brauchen. Und eine Insel für den erfahrenen Java-Programmierer, der konkrete Fragen aus der Praxis hat und sich schnell und gründlich in verschiedene Spezialgebiete einarbeiten muss. Herausgekommen sind 2700 Seiten Java-Wissen, fundiert und reich an Details, passgenau auf ihre jeweiligen Bedürfnisse zugeschnitten. Ohne dass Sie Abstriche machen müssen! Die Inseln sind Kultbücher. Und diese Bücher wollen sorgfältig gepflegt und aktualisiert werden. Dass der Inhalt up-to-date ist, versteht sich von selbst. Die Präsentation, sprich: das Layout, ist es jetzt auch. Frischer, aufgeräumter und lesefreundlicher. Sie haben bestimmt ihre Freude daran. Wir hoffen, dass keine Java-Fragen offen bleiben! Sollten Sie dennoch kleine Fehler oder Ungenauigkeiten finden, so haben Sie jederzeit die Möglichkeit, sich an Christian Ullenboom ([email protected]) oder an mich zu wenden. Wir freuen uns über eine freundliche Rückmeldung!
Judith Stevens-Lemoine Lektorat Galileo Computing
[email protected] www.galileocomputing.de Galileo Press · Rheinwerkallee 4 · 53227 Bonn
Auf einen Blick 1
Neues in Java 7 ..................................................................................................
41
2
Threads und nebenläufige Programmierung ..............................................
65
3
Datenstrukturen und Algorithmen ...............................................................
175
4
Raum und Zeit ...................................................................................................
305
5
Dateien, Verzeichnisse und Dateizugriffe ...................................................
357
6
Datenströme ......................................................................................................
427
7
Die eXtensible Markup Language (XML) ......................................................
531
8
Dateiformate .....................................................................................................
617
9
Grafische Oberflächen mit Swing .................................................................
645
10
Grafikprogrammierung ...................................................................................
865
11
Netzwerkprogrammierung .............................................................................
955
12
Verteilte Programmierung mit RMI .............................................................. 1035
13
RESTful und SOAP Web-Services .................................................................... 1057
14
JavaServer Pages und Servlets ....................................................................... 1079
15
Applets ................................................................................................................ 1123
16
Datenbankmanagement mit JDBC ................................................................ 1139
17
Technologien für die Infrastruktur ................................................................ 1207
18
Reflection und Annotationen ......................................................................... 1227
19
Dynamische Übersetzung und Skriptsprachen .......................................... 1289
20
Logging und Monitoring .................................................................................. 1315
21
Java Native Interface (JNI) ............................................................................... 1337
22
Sicherheitskonzepte ......................................................................................... 1355
23
Dienstprogramme für die Java-Umgebung ................................................. 1381
Der Name Galileo Press geht auf den italienischen Mathematiker und Philosophen Galileo Galilei (1564– 1642) zurück. Er gilt als Gründungsfigur der neuzeitlichen Wissenschaft und wurde berühmt als Verfechter des modernen, heliozentrischen Weltbilds. Legendär ist sein Ausspruch Eppur si muove (Und sie bewegt sich doch). Das Emblem von Galileo Press ist der Jupiter, umkreist von den vier Galileischen Monden. Galilei entdeckte die nach ihm benannten Monde 1610. Lektorat Judith Stevens-Lemoine, Anne Scheibe Korrektorat Friederike Daenecke, Zülpich Cover Barbara Thoben, Köln Titelbild Karte: @Christian Nitz – fotolia.com, Palme: @pati – fotolia.com Typografie und Layout Vera Brauner Herstellung Norbert Englert Satz SatzPro, Krefeld Druck und Bindung Bercker Graphischer Betrieb, Kevelaer
Gerne stehen wir Ihnen mit Rat und Tat zur Seite: [email protected] bei Fragen und Anmerkungen zum Inhalt des Buches [email protected] für versandkostenfreie Bestellungen und Reklamationen [email protected] für Rezensions- und Schulungsexemplare
Dieses Buch wurde gesetzt aus der TheAntiqua (9,5/14 pt) in FrameMaker.
Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
ISBN 978-3-8362-1507-7 © Galileo Press, Bonn 2012 1. Auflage 2012
Das vorliegende Werk ist in all seinen Teilen urheberrechtlich geschützt. Alle Rechte vorbehalten, insbesondere das Recht der Übersetzung, des Vortrags, der Reproduktion, der Vervielfältigung auf fotomechanischem oder anderen Wegen und der Speicherung in elektronischen Medien. Ungeachtet der Sorgfalt, die auf die Erstellung von Text, Abbildungen und Programmen verwendet wurde, können weder Verlag noch Autor, Herausgeber oder Übersetzer für mögliche Fehler und deren Folgen eine juristische Verantwortung oder irgendeine Haftung übernehmen. Die in diesem Werk wiedergegebenen Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. können auch ohne besondere Kennzeichnung Marken sein und als solche den gesetzlichen Bestimmungen unterliegen.
Inhalt
Inhalt Vorwort ......................................................................................................................................................
35
1
Neues in Java 7
1.1
Sprachänderungen ........................................................................................................................
41
1.1.1
Zahlen im Binärsystem schreiben ..........................................................................
41
1.1.2
Unterstriche bei Ganzzahlen ....................................................................................
41
1.1.3
switch (String) ................................................................................................................
42
1.1.4
Zusammenfassen gleicher catch-Blöcke mit dem multi-catch ......................
43
1.1.5
Präzisiertes rethrows ..................................................................................................
47
1.1.6
Automatisches Ressourcen-Management (try mit Ressourcen) ...................
51
1.1.7
try mit Ressourcen .......................................................................................................
51
1.1.8
Ausnahmen vom close() bleiben bestehen ..........................................................
53
1.1.9
Die Schnittstelle AutoCloseable ...............................................................................
53
1.1.10
Mehrere Ressourcen nutzen .....................................................................................
55
1.1.11
Unterdrückte Ausnahmen * ......................................................................................
56
JVM-Änderungen ...........................................................................................................................
59
1.2.1
invokedynamic .............................................................................................................
60
Neue Pakete und Klassen ............................................................................................................
63
1.3.1
63
1.2 1.3
Weitere Änderungen ...................................................................................................
2
Threads und nebenläufige Programmierung
2.1
Threads erzeugen ..........................................................................................................................
2.2
65
2.1.1
Threads über die Schnittstelle Runnable implementieren .............................
65
2.1.2
Thread mit Runnable starten ...................................................................................
66
2.1.3
Die Klasse Thread erweitern .....................................................................................
68
Thread-Eigenschaften und -Zustände .....................................................................................
71
2.2.1
Der Name eines Threads ............................................................................................
71
2.2.2
Wer bin ich? ....................................................................................................................
72
2.2.3
Die Zustände eines Threads * ....................................................................................
72
5
Inhalt
2.3
2.4
2.5
6
2.2.4
Schläfer gesucht ...........................................................................................................
73
2.2.5
Mit yield() auf Rechenzeit verzichten ...................................................................
75
2.2.6
Der Thread als Dämon ................................................................................................
76
2.2.7
Das Ende eines Threads .............................................................................................
78
2.2.8
Einen Thread höflich mit Interrupt beenden .....................................................
79
2.2.9
UncaughtExceptionHandler für unbehandelte Ausnahmen ........................
81
2.2.10
Der stop() von außen und die Rettung mit ThreadDeath * .............................
82
2.2.11
Ein Rendezvous mit join() * ......................................................................................
84
2.2.12
Arbeit niederlegen und wieder aufnehmen * .....................................................
87
2.2.13
Priorität * ........................................................................................................................
87
Der Ausführer (Executor) kommt .............................................................................................
88
2.3.1
89
Die Schnittstelle Executor .........................................................................................
2.3.2
Die Thread-Pools ..........................................................................................................
91
2.3.3
Threads mit Rückgabe über Callable .....................................................................
92
2.3.4
Mehrere Callable abarbeiten ....................................................................................
96
2.3.5
ScheduledExecutorService für wiederholende Ausgaben und Zeitsteuerungen nutzen ............................................................................................
97
Synchronisation über kritische Abschnitte ...........................................................................
98
2.4.1
Gemeinsam genutzte Daten ....................................................................................
98
2.4.2
Probleme beim gemeinsamen Zugriff und kritische Abschnitte .................
98
2.4.3
Punkte parallel initialisieren ...................................................................................
100
2.4.4
i++ sieht atomar aus, ist es aber nicht * ................................................................
102
2.4.5
Kritische Abschnitte schützen .................................................................................
103
2.4.6
Kritische Abschnitte mit ReentrantLock schützen ...........................................
106
2.4.7
Synchronisieren mit synchronized .......................................................................
113
2.4.8
Synchronized-Methoden der Klasse StringBuffer * ..........................................
114
2.4.9
Mit synchronized synchronisierte Blöcke ...........................................................
115
2.4.10
Dann machen wir doch gleich alles synchronisiert! ........................................
117
2.4.11
Lock-Freigabe im Fall von Exceptions ...................................................................
118
2.4.12
Deadlocks .......................................................................................................................
119
2.4.13
Mit synchronized nachträglich synchronisieren * ............................................
121
2.4.14
Monitore sind reentrant – gut für die Geschwindigkeit * ...............................
122
2.4.15
Synchronisierte Methodenaufrufe zusammenfassen * ..................................
123
Synchronisation über Warten und Benachrichtigen ..........................................................
124
2.5.1
Die Schnittstelle Condition ......................................................................................
125
2.5.2
It’s Disco-Time * ...........................................................................................................
129
Inhalt
2.6
2.7
2.8
2.9
2.5.3
Warten mit wait() und Aufwecken mit notify() * ................................................
135
2.5.4
Falls der Lock fehlt: IllegalMonitorStateException * .........................................
136
Datensynchronisation durch besondere Concurrency-Klassen * .....................................
138
2.6.1
138
Semaphor ........................................................................................................................
2.6.2
Barrier und Austausch ................................................................................................
143
2.6.3
Stop and go mit Exchanger .......................................................................................
145
Atomare Operationen und frische Werte mit volatile * .....................................................
145
2.7.1
Der Modifizierer volatile bei Objekt-/Klassenvariablen ..................................
146
2.7.2
Das Paket java.util.concurrent.atomic ...................................................................
148
Teile und herrsche mit Fork und Join * ....................................................................................
149
2.8.1
Algorithmendesign per »teile und herrsche« .....................................................
149
2.8.2
Paralleles Lösen von D&C-Algorithmen ...............................................................
151
2.8.3
Fork und Join .................................................................................................................
152
Mit dem Thread verbundene Variablen * ...............................................................................
156
2.9.1
ThreadLocal ....................................................................................................................
156
2.9.2
InheritableThreadLocal ..............................................................................................
159
2.9.3
ThreadLocalRandom als Zufallszahlengenerator ...............................................
160
2.9.4
ThreadLocal bei der Performance-Optimierung ................................................
161
2.10 Threads in einer Thread-Gruppe * ............................................................................................
162
2.10.1
Aktive Threads in der Umgebung ...........................................................................
162
2.10.2
Etwas über die aktuelle Thread-Gruppe herausfinden .....................................
163
2.10.3
Threads in einer Thread-Gruppe anlegen .............................................................
166
2.10.4
Methoden von Thread und ThreadGroup im Vergleich ..................................
169
2.11 Zeitgesteuerte Abläufe ................................................................................................................
170
2.11.1
Die Typen Timer und TimerTask .............................................................................
171
2.11.2
Job-Scheduler Quartz ..................................................................................................
172
2.12 Einen Abbruch der virtuellen Maschine erkennen ...............................................................
173
2.13 Zum Weiterlesen ...........................................................................................................................
174
3
Datenstrukturen und Algorithmen
3.1
Datenstrukturen und die Collection-API ................................................................................
175
3.1.1
Designprinzip mit Schnittstellen, abstrakten und konkreten Klassen .......
176
3.1.2
Die Basis-Schnittstellen Collection und Map ......................................................
176
3.1.3
Die Utility-Klassen Collections und Arrays ..........................................................
177
7
Inhalt
3.2
3.3
3.4 3.5
3.6
8
3.1.4
Das erste Programm mit Container-Klassen ......................................................
177
3.1.5
Die Schnittstelle Collection und Kernkonzepte .................................................
178
3.1.6
Schnittstellen, die Collection erweitern, und Map ............................................
182
3.1.7
Konkrete Container-Klassen ....................................................................................
185
3.1.8
Generische Datentypen in der Collection-API ....................................................
187
3.1.9
Die Schnittstelle Iterable und das erweiterte for ...............................................
187
Listen ................................................................................................................................................
188
3.2.1
Erstes Listen-Beispiel ..................................................................................................
189
3.2.2
Auswahlkriterium ArrayList oder LinkedList .....................................................
190
3.2.3
Die Schnittstelle List ...................................................................................................
191
3.2.4
ArrayList .........................................................................................................................
197
3.2.5
LinkedList .......................................................................................................................
200
3.2.6
Der Feld-Adapter Arrays.asList() .............................................................................
201
3.2.7
ListIterator * ...................................................................................................................
202
3.2.8
toArray() von Collection verstehen – die Gefahr einer Falle erkennen ......
204
3.2.9
Primitive Elemente in Datenstrukturen verwalten ..........................................
207
Mengen (Sets) ................................................................................................................................
208
3.3.1
Ein erstes Mengen-Beispiel .......................................................................................
209
3.3.2
Methoden der Schnittstelle Set ...............................................................................
212
3.3.3
HashSet ...........................................................................................................................
213
3.3.4
TreeSet – die sortierte Menge ..................................................................................
214
3.3.5
Die Schnittstellen NavigableSet und SortedSet .................................................
216
3.3.6
LinkedHashSet ..............................................................................................................
218
Stack (Kellerspeicher, Stapel) ....................................................................................................
218
3.4.1
Die Methoden von Stack ...........................................................................................
219
Queues (Schlangen) und Deques ..............................................................................................
220
3.5.1
Queue-Klassen ..............................................................................................................
221
3.5.2
Deque-Klassen ..............................................................................................................
222
3.5.3
Blockierende Queues und Prioritätswarteschlangen .......................................
223
3.5.4
PriorityQueue ...............................................................................................................
223
Assoziative Speicher ....................................................................................................................
228
3.6.1
Die Klassen HashMap und TreeMap ......................................................................
228
3.6.2
Einfügen und Abfragen der Datenstruktur .........................................................
231
3.6.3
Über die Bedeutung von equals() und hashCode() ............................................
234
3.6.4
Eigene Objekte hashen ...............................................................................................
235
3.6.5
IdentityHashMap .........................................................................................................
237
3.6.6
Das Problem von veränderten Elementen ..........................................................
237
Inhalt
3.7
3.8
3.9
3.6.7
Aufzählungen und Ansichten des Assoziativspeichers ...................................
237
3.6.8
Die Arbeitsweise einer Hash-Tabelle * ...................................................................
241
Die Properties-Klasse ...................................................................................................................
243
3.7.1
Properties setzen und lesen ......................................................................................
243
3.7.2
Properties verketten ....................................................................................................
244
3.7.3
Hierarchische Eigenschaften ....................................................................................
245
3.7.4
Eigenschaften auf der Konsole ausgeben * ..........................................................
245
3.7.5
Properties laden und speichern ...............................................................................
246
3.7.6
Klassenbeziehungen: Properties und Hashtable * .............................................
248
Mit einem Iterator durch die Daten wandern .......................................................................
249
3.8.1
Die Schnittstelle Iterator ............................................................................................
249
3.8.2
Der Iterator kann (eventuell auch) löschen .........................................................
251
3.8.3
Einen Zufallszahleniterator schreiben ..................................................................
252
3.8.4
Iteratoren von Sammlungen, das erweiterte for und Iterable .......................
254
3.8.5
Fail-Fast-Iterator und die ConcurrentModificationException .......................
258
3.8.6
Die Schnittstelle Enumerator * ................................................................................
260
Algorithmen in Collections .........................................................................................................
261
3.9.1
263
Die Bedeutung von Ordnung mit Comparator und Comparable .................
3.9.2
Sortieren ..........................................................................................................................
264
3.9.3
Den größten und kleinsten Wert einer Collection finden ...............................
267
3.9.4
Nicht-änderbare Datenstrukturen, immutable oder nur-lesen? ...................
270
3.9.5
Null Object Pattern und leere Sammlungen/Iteratoren zurückgeben ........
274
3.9.6
Mit der Halbierungssuche nach Elementen fahnden .......................................
278
3.9.7
Ersetzen, Kopieren, Füllen, Umdrehen, Rotieren * ............................................
279
3.9.8
Listen durchwürfeln * .................................................................................................
281
3.9.9
Häufigkeit eines Elements * ......................................................................................
282
3.9.10
Singletons * .....................................................................................................................
282
3.9.11
nCopies() * .......................................................................................................................
283
3.10 Spezielle thread-sichere Datenstrukturen ............................................................................. 3.10.1
Wait-free-Algorithmen ...............................................................................................
3.10.2
Nebenläufiger Assoziativspeicher und die Schnittstelle
284 284
ConcurrentMap .............................................................................................................
284
3.10.3
ConcurrentLinkedQueue ...........................................................................................
285
3.10.4
CopyOnWriteArrayList und CopyOnWriteArraySet ..........................................
285
3.10.5
Wrapper zur Synchronisation ..................................................................................
286
3.10.6
Blockierende Warteschlangen ..................................................................................
287
9
Inhalt
3.10.7
ArrayBlockingQueue und LinkedBlockingQueue .............................................
287
3.10.8
PriorityBlockingQueue ..............................................................................................
290
3.11 Google Guava (aka Google Collections Library) ..................................................................
294
3.11.1
Beispiel Multi-Set und Multi-Map ..........................................................................
294
3.11.2
Datenstrukturen aus Guava .....................................................................................
295
3.11.3
Utility-Klassen von Guava ........................................................................................
297
3.11.4
Prädikate .........................................................................................................................
298
3.11.5
Transformationen .......................................................................................................
299
3.12 Die Klasse BitSet für Bitmengen * ............................................................................................
299
3.12.1
Ein BitSet anlegen, füllen und erfragen ................................................................
300
3.12.2
Mengenorientierte Operationen ............................................................................
301
3.12.3
Methodenübersicht ....................................................................................................
302
3.12.4
Primzahlen in einem BitSet verwalten .................................................................
304
3.13 Zum Weiterlesen ..........................................................................................................................
304
4
Raum und Zeit
4.1
Weltzeit * ........................................................................................................................................
305
4.2
Wichtige Datum-Klassen im Überblick ..................................................................................
306
4.3 4.4
4.5
4.6
10
4.2.1
Der 1.1.1970 ...................................................................................................................
307
4.2.2
System.currentTimeMillis() .....................................................................................
307
4.2.3
Einfache Zeitumrechnungen durch TimeUnit ...................................................
307
Sprachen der Länder ....................................................................................................................
308
4.3.1
Sprachen und Regionen über Locale-Objekte .....................................................
309
Internationalisierung und Lokalisierung ...............................................................................
312
4.4.1
ResourceBundle-Objekte und Ressource-Dateien .............................................
313
4.4.2
Ressource-Dateien zur Lokalisierung ....................................................................
314
4.4.3
Die Klasse ResourceBundle ......................................................................................
314
4.4.4
Ladestrategie für ResourceBundle-Objekte .........................................................
316
Die Klasse Date ..............................................................................................................................
317
4.5.1
Objekte erzeugen und Methoden nutzen ............................................................
317
4.5.2
Date-Objekte sind nicht immutable ......................................................................
319
Calendar und GregorianCalendar ............................................................................................
320
4.6.1
Die abstrakte Klasse Calendar ..................................................................................
320
4.6.2
Der gregorianische Kalender ...................................................................................
322
Inhalt
4.7
4.8
4.9
4.6.3
Calendar nach Date und Millisekunden fragen ..................................................
325
4.6.4
Ostertage * ......................................................................................................................
326
4.6.5
Abfragen und Setzen von Datumselementen über Feldbezeichner ............
328
4.6.6
Wie viele Tage hat der Monat, oder wie viele Monate hat ein Jahr? * ..........
333
4.6.7
Wann beginnt die Woche und wann die erste Woche im Jahr? * ..................
335
Zeitzonen in Java * ........................................................................................................................
336
4.7.1
Zeitzonen durch die Klasse TimeZone repräsentieren .....................................
337
4.7.2
SimpleTimeZone ..........................................................................................................
337
4.7.3
Methoden von TimeZone ..........................................................................................
339
Zeitdauern und der XML-Datentyp Duration * .....................................................................
340
4.8.1
DatatypeFactory als Fabrik ........................................................................................
341
4.8.2
Die Duration-Klasse und ihre Methoden ..............................................................
342
Formatieren und Parsen von Datumsangaben .....................................................................
345
4.9.1
Ausgaben mit printf() ..................................................................................................
345
4.9.2
Mit DateFormat und SimpleDateFormat formatieren .....................................
346
4.9.3
Parsen von Datumswerten ........................................................................................
352
4.10 Zum Weiterlesen ...........................................................................................................................
355
5
Dateien, Verzeichnisse und Dateizugriffe
5.1
Datei und Verzeichnis ..................................................................................................................
357
5.1.1
Dateien und Verzeichnisse mit der Klasse File ...................................................
358
5.1.2
Verzeichnis oder Datei? Existiert es? .....................................................................
361
5.1.3
Verzeichnis- und Dateieigenschaften/-attribute ...............................................
362
5.1.4
Umbenennen und Verzeichnisse anlegen ...........................................................
365
5.1.5
Verzeichnisse auflisten und Dateien filtern ........................................................
365
5.1.6
Dateien berühren, neue Dateien anlegen, temporäre Dateien ......................
369
5.1.7
Dateien und Verzeichnisse löschen ........................................................................
370
5.1.8
Verzeichnisse nach Dateien iterativ durchsuchen * ..........................................
372
5.1.9
Wurzelverzeichnis, Laufwerksnamen, Plattenspeicher * ................................
373
5.1.10
URL-, URI- und Path-Objekte aus einem File-Objekt ableiten * ......................
376
5.1.11
Mit Locking Dateien sperren * ..................................................................................
376
5.1.12
Sicherheitsprüfung * ...................................................................................................
377
5.1.13
Zugriff auf SMB-Server mit jCIFS * ..........................................................................
378
11
Inhalt
5.2
5.3
5.4
Dateien mit wahlfreiem Zugriff ...............................................................................................
378
5.2.1
Ein RandomAccessFile zum Lesen und Schreiben öffnen ..............................
379
5.2.2
Aus dem RandomAccessFile lesen .........................................................................
380
5.2.3
Schreiben mit RandomAccessFile ..........................................................................
383
5.2.4
Die Länge des RandomAccessFile ...........................................................................
384
5.2.5
Hin und her in der Datei ............................................................................................
384
Dateisysteme unter NIO.2 ..........................................................................................................
385
5.3.1
FileSystem und Path ...................................................................................................
386
5.3.2
Die Utility-Klasse Files ...............................................................................................
392
5.3.3
Dateien kopieren und verschieben ........................................................................
395 397
5.3.4
Dateiattribute * .............................................................................................................
5.3.5
Neue Dateien, Verzeichnisse, symbolische Verknüpfungen anlegen und löschen ...................................................................................................................
406
5.3.6
MIME-Typen testen * ..................................................................................................
408
5.3.7
Verzeichnislistings (DirectoryStream) und Filter * ...........................................
410
5.3.8
Rekursive Abläufe des Verzeichnisbaums (FileVisitor) * ................................
412
5.3.9
Dateisysteme und Dateisystemattribute * ..........................................................
416
5.3.10
Verzeichnisse im Dateisystem überwachen * .....................................................
420
Wahlfreier Zugriff mit SeekableByteChannel und ByteBuffer * .....................................
422
5.4.1
SeekableByteChannel .................................................................................................
422
5.4.2
ByteBuffer ......................................................................................................................
423
5.4.3
Beispiel mit Path + SeekableByteChannel + ByteBuffer ..................................
423
5.4.4
FileChannel ....................................................................................................................
424
5.5
Zum Weiterlesen ..........................................................................................................................
426
6
Datenströme
6.1
Stream-Klassen und Reader/Writer am Beispiel von Dateien .........................................
427
6.1.1
Mit dem FileWriter Texte in Dateien schreiben .................................................
428
6.1.2
Zeichen mit der Klasse FileReader lesen ..............................................................
430
6.1.3
Kopieren mit FileOutputStream und FileInputStream ...................................
431
6.2
12
6.1.4
Das FileDescriptor-Objekt * ......................................................................................
435
6.1.5
Datenströme über Files mit NIO.2 beziehen .......................................................
436
Basisklassen für die Ein-/Ausgabe ...........................................................................................
438
6.2.1
Die abstrakten Basisklassen .....................................................................................
438
6.2.2
Übersicht über Ein-/Ausgabeklassen ....................................................................
439
Inhalt
6.3
6.4
6.5
6.6
6.7
6.2.3
Die abstrakte Basisklasse OutputStream ..............................................................
441
6.2.4
Die Schnittstellen Closeable, AutoCloseable und Flushable ...........................
443
6.2.5
Ein Datenschlucker * ...................................................................................................
444
6.2.6
Die abstrakte Basisklasse InputStream .................................................................
445
6.2.7
Ressourcen aus dem Klassenpfad und aus Jar-Archiven laden .....................
446
6.2.8
Ströme mit SequenceInputStream zusammensetzen * ...................................
447
6.2.9
Die abstrakte Basisklasse Writer ..............................................................................
449
6.2.10
Die Schnittstelle Appendable * .................................................................................
451
6.2.11
Die abstrakte Basisklasse Reader .............................................................................
451
Formatierte Textausgaben .........................................................................................................
454
6.3.1
Die Klassen PrintWriter und PrintStream ............................................................
455
6.3.2
System.out, System.err und System.in ..................................................................
460
Schreiben und Lesen aus Strings und Byte-Feldern .............................................................
462
6.4.1
Mit dem StringWriter ein String-Objekt füllen ...................................................
463
6.4.2
CharArrayWriter ...........................................................................................................
464
6.4.3
StringReader und CharArrayReader .......................................................................
465
6.4.4
Mit ByteArrayOutputStream in ein Byte-Feld schreiben ................................
467
6.4.5
Mit ByteArrayInputStream aus einem Byte-Feld lesen ....................................
467
Datenströme filtern und verketten .........................................................................................
468
6.5.1
Streams als Filter verketten (verschachteln) .......................................................
469
6.5.2
Gepufferte Ausgaben mit BufferedWriter und BufferedOutputStream .....
469
6.5.3
Gepufferte Eingaben mit BufferedReader/BufferedInputStream ................
471
6.5.4
LineNumberReader zählt automatisch Zeilen mit * ..........................................
474
6.5.5
Daten mit der Klasse PushbackReader zurücklegen * .......................................
474
6.5.6
DataOutputStream/DataInputStream * ................................................................
478
6.5.7
Basisklassen für Filter * ...............................................................................................
478
6.5.8
Die Basisklasse FilterWriter * ....................................................................................
479
6.5.9
Ein LowerCaseWriter * ................................................................................................
480
6.5.10
Eingaben mit der Klasse FilterReader filtern * ....................................................
482
6.5.11
Anwendungen für FilterReader und FilterWriter * ............................................
483
Vermittler zwischen Byte-Streams und Unicode-Strömen ...............................................
491
6.6.1
Datenkonvertierung durch den OutputStreamWriter .....................................
491
6.6.2
Automatische Konvertierungen mit dem InputStreamReader ....................
492
Kommunikation zwischen Threads mit Pipes * ....................................................................
493
6.7.1
PipedOutputStream und PipedInputStream .......................................................
494
6.7.2
PipedWriter und PipedReader ..................................................................................
496
13
Inhalt
6.8
6.9
Prüfsummen ...................................................................................................................................
498
6.8.1
Die Schnittstelle Checksum ......................................................................................
498
6.8.2
Die Klasse CRC32 ..........................................................................................................
499
6.8.3
Die Adler32-Klasse .......................................................................................................
501
Persistente Objekte und Serialisierung ..................................................................................
502
6.9.1
Objekte mit der Standard-Serialisierung speichern und lesen .....................
503
6.9.2
Zwei einfache Anwendungen der Serialisierung * ............................................
506
6.9.3
Die Schnittstelle Serializable ....................................................................................
507
6.9.4
Nicht serialisierbare Attribute aussparen ............................................................
509
6.9.5
Das Abspeichern selbst in die Hand nehmen .....................................................
511
6.9.6
Tiefe Objektkopien * ...................................................................................................
515
6.9.7
Versionenverwaltung und die SUID ......................................................................
517
6.9.8
Wie die ArrayList serialisiert * .................................................................................
519
6.9.9
Probleme mit der Serialisierung .............................................................................
520
6.10 Alternative Datenaustauschformate ......................................................................................
522
6.10.1
Serialisieren in XML-Dateien ...................................................................................
522
6.10.2
XML-Serialisierung von JavaBeans mit JavaBeans Persistence * ..................
522
6.10.3
Die Open-Source-Bibliothek XStream * ................................................................
525
6.10.4
Binäre Serialisierung mit Google Protocol Buffers * ........................................
526
6.11 Tokenizer * ......................................................................................................................................
526
6.11.1
StreamTokenizer ..........................................................................................................
526
6.12 Zum Weiterlesen ..........................................................................................................................
529
7
Die eXtensible Markup Language (XML)
7.1
Auszeichnungssprachen .............................................................................................................
531
7.1.1
Die Standard Generalized Markup Language (SGML) ......................................
532
7.1.2
Extensible Markup Language (XML) ......................................................................
532
Eigenschaften von XML-Dokumenten ....................................................................................
533
7.2.1
Elemente und Attribute .............................................................................................
533
7.2.2
Beschreibungssprache für den Aufbau von XML-Dokumenten ...................
535
7.2.3
Schema – eine Alternative zu DTD .........................................................................
539
7.2.4
Namensraum (Namespace) ......................................................................................
542
7.2.5
XML-Applikationen * ..................................................................................................
543
7.2
14
Inhalt
7.3
7.4
7.5
7.6
7.7
Die Java-APIs für XML ..................................................................................................................
544
7.3.1
Das Document Object Model (DOM) ......................................................................
545
7.3.2
Simple API for XML Parsing (SAX) ...........................................................................
545
7.3.3
Pull-API StAX .................................................................................................................
545
7.3.4
Java Document Object Model (JDOM) ....................................................................
545
7.3.5
JAXP als Java-Schnittstelle zu XML .........................................................................
546
7.3.6
DOM-Bäume einlesen mit JAXP * ............................................................................
547
Java Architecture for XML Binding (JAXB) ..............................................................................
548
7.4.1
Bean für JAXB aufbauen .............................................................................................
548
7.4.2
JAXBContext und die Marshaller ............................................................................
549
7.4.3
Ganze Objektgraphen schreiben und lesen .........................................................
550
7.4.4
Validierung .....................................................................................................................
553
7.4.5
Weitere JAXB-Annotationen * ..................................................................................
557
7.4.6
Beans aus XML-Schema-Datei generieren ............................................................
565
Serielle Verarbeitung mit StAX .................................................................................................
570
7.5.1
Unterschiede der Verarbeitungsmodelle .............................................................
571
7.5.2
XML-Dateien mit dem Cursor-Verfahren lesen ..................................................
572
7.5.3
XML-Dateien mit dem Iterator-Verfahren verarbeiten * .................................
576
7.5.4
Mit Filtern arbeiten * ...................................................................................................
578
7.5.5
XML-Dokumente schreiben ......................................................................................
579
Serielle Verarbeitung von XML mit SAX * ..............................................................................
582
7.6.1
583
Schnittstellen von SAX ...............................................................................................
7.6.2
SAX-Parser erzeugen ...................................................................................................
584
7.6.3
Operationen der Schnittstelle ContentHandler .................................................
584
7.6.4
ErrorHandler und EntityResolver ...........................................................................
587
XML-Dateien mit JDOM verarbeiten .......................................................................................
588
7.7.1
JDOM beziehen ..............................................................................................................
588
7.7.2
Paketübersicht * ............................................................................................................
588
7.7.3
Die Document-Klasse ..................................................................................................
590
7.7.4
Eingaben aus der Datei lesen ....................................................................................
591
7.7.5
Das Dokument im XML-Format ausgeben ...........................................................
592
7.7.6
Der Dokumenttyp * ......................................................................................................
593
7.7.7
Elemente .........................................................................................................................
594
7.7.8
Zugriff auf Elementinhalte ........................................................................................
597
7.7.9
Liste mit Unterelementen erzeugen * ....................................................................
599
7.7.10
Neue Elemente einfügen und ändern ....................................................................
600
15
Inhalt
7.8
7.9
7.7.11
Attributinhalte lesen und ändern ..........................................................................
603
7.7.12
XPath ...............................................................................................................................
606
Transformationen mit XSLT * ....................................................................................................
610
7.8.1
Templates und XPath als Kernelemente von XSLT ...........................................
610
7.8.2
Umwandlung von XML-Dateien mit JDOM und JAXP .....................................
613
XML-Schema-Validierung * ........................................................................................................
614
7.9.1
SchemaFactory und Schema ....................................................................................
614
7.9.2
Validator .........................................................................................................................
614
7.9.3
Validierung unterschiedlicher Datenquellen durchführen ...........................
615
7.10 Zum Weiterlesen ..........................................................................................................................
615
8
Dateiformate
8.1
Einfache Dateiformate für strukturierte Daten ...................................................................
618
8.1.1
618
8.2
8.3
Property-Dateien .........................................................................................................
8.1.2
CSV-Dateien ...................................................................................................................
618
8.1.3
JSON-Serialisierung mit Jackson .............................................................................
619
Dokumentenformate ...................................................................................................................
620
8.2.1
(X)HTML ..........................................................................................................................
620
8.2.2
PDF-Dokumente ...........................................................................................................
622
8.2.3
Microsoft Office-Dokumente ...................................................................................
622
8.2.4
OASIS Open Document Format ...............................................................................
624
Datenkompression * ....................................................................................................................
624
8.3.1
Java-Unterstützung beim Komprimieren ............................................................
625
8.3.2
Daten packen und entpacken ..................................................................................
626
8.3.3
Datenströme komprimieren ....................................................................................
627
8.3.4
Zip-Archive ....................................................................................................................
632
8.3.5
Jar-Archive .....................................................................................................................
640
8.4
Bild-Formate ..................................................................................................................................
640
8.5
Audio-Dateien ...............................................................................................................................
640
8.5.1
Die Arbeit mit AudioClip ...........................................................................................
640
8.5.2
MIDI-Dateien abspielen .............................................................................................
641
16
Inhalt
9
Grafische Oberflächen mit Swing
9.1
Fenster zur Welt ............................................................................................................................
645
9.1.1
Swing-Fenster mit javax.swing.JFrame darstellen .............................................
645
9.1.2
Fenster schließbar machen – setDefaultCloseOperation() ..............................
647
9.1.3
Sichtbarkeit des Fensters ...........................................................................................
648
9.1.4
Größe und Position des Fensters verändern .......................................................
648
9.1.5
Fenster- und Dialog-Dekoration, Transparenz * .................................................
649
9.1.6
Die Klasse Toolkit * ......................................................................................................
650
9.1.7
Dynamisches Layout während einer Größenänderung * ................................
651
9.1.8
Zum Vergleich: AWT-Fenster darstellen * .............................................................
651
Beschriftungen (JLabel) ...............................................................................................................
653
9.2.1
Mehrzeiliger Text, HTML in der Darstellung .......................................................
656
Icon und ImageIcon für Bilder auf Swing-Komponenten ..................................................
657
9.3.1
Die Klasse ImageIcon ..................................................................................................
657
9.3.2
Die Schnittstelle Icon und eigene Icons zeichnen * ...........................................
659
Es tut sich was – Ereignisse beim AWT ...................................................................................
661
9.4.1
Die Ereignisquellen und Horcher (Listener) von Swing ...................................
662
9.4.2
Listener implementieren ...........................................................................................
663
9.4.3
Listener bei dem Ereignisauslöser anmelden/abmelden ................................
666
9.4.4
Adapterklassen nutzen ...............................................................................................
668
9.4.5
Innere Mitgliedsklassen und innere anonyme Klassen ...................................
670
9.4.6
Aufrufen der Listener im AWT-Event-Thread .....................................................
672
9.4.7
Ereignisse, etwas genauer betrachtet * ..................................................................
673
9.2 9.3
9.4
9.5
9.6
Schaltflächen ..................................................................................................................................
676
9.5.1
Normale Schaltflächen (JButton) .............................................................................
676
9.5.2
Der aufmerksame ActionListener ...........................................................................
678
9.5.3
Schaltflächen-Ereignisse vom Typ ActionEvent .................................................
679
9.5.4
Basisklasse AbstractButton .......................................................................................
680
9.5.5
Wechselknopf (JToggleButton) ................................................................................
682
Textkomponenten ........................................................................................................................
683
9.6.1
Text in einer Eingabezeile .........................................................................................
684
9.6.2
Die Oberklasse der Text-Komponenten (JTextComponent) ..........................
685
9.6.3
Geschützte Eingaben (JPasswordField) ..................................................................
686
9.6.4
Validierende Eingabefelder (JFormattedTextField) ...........................................
687
9.6.5
Einfache mehrzeilige Textfelder (JTextArea) .......................................................
688
9.6.6
Editor-Klasse (JEditorPane) * .....................................................................................
692
17
Inhalt
9.7
Swing Action * ...............................................................................................................................
694
9.8
JComponent und Component als Basis aller Komponenten ............................................
697
9.9
9.8.1
Hinzufügen von Komponenten ..............................................................................
697
9.8.2
Tooltips (Kurzhinweise) .............................................................................................
698
9.8.3
Rahmen (Border) * .......................................................................................................
699
9.8.4
Fokus und Navigation * ..............................................................................................
701
9.8.5
Ereignisse jeder Komponente * ...............................................................................
702
9.8.6
Die Größe und Position einer Komponente * .....................................................
706
9.8.7
Komponenten-Ereignisse * .......................................................................................
707
9.8.8
UI-Delegate – der wahre Zeichner * ........................................................................
708
9.8.9
Undurchsichtige (opake) Komponente * ..............................................................
711
9.8.10
Properties und Listener für Änderungen * ..........................................................
711
Container ........................................................................................................................................
711
9.9.1
Standardcontainer (JPanel) .......................................................................................
712
9.9.2
Bereich mit automatischen Rollbalken (JScrollPane) .......................................
713
9.9.3
Reiter (JTabbedPane) ...................................................................................................
714
9.9.4
Teilungskomponente (JSplitPane) ..........................................................................
715
9.10 Alles Auslegungssache: die Layoutmanager ........................................................................
716
9.10.1
Übersicht über Layoutmanager ..............................................................................
717
9.10.2
Zuweisen eines Layoutmanagers ...........................................................................
717
9.10.3
Im Fluss mit FlowLayout ...........................................................................................
718
9.10.4
BoxLayout ......................................................................................................................
720
9.10.5
Mit BorderLayout in alle Himmelsrichtungen ...................................................
721
9.10.6
Rasteranordnung mit GridLayout ..........................................................................
724
9.10.7
Der GridBagLayoutmanager * ..................................................................................
725
9.10.8
Null-Layout * .................................................................................................................
731
9.10.9
Weitere Layoutmanager ............................................................................................
732
9.11 Rollbalken und Schieberegler ...................................................................................................
733
9.11.1
Schieberegler (JSlider) ................................................................................................
733
9.11.2
Rollbalken (JScrollBar) * .............................................................................................
734
9.12 Kontrollfelder, Optionsfelder, Kontrollfeldgruppen .......................................................... Kontrollfelder (JCheckBox) .......................................................................................
740
9.12.2
ItemSelectable, ItemListener und das ItemEvent .............................................
741
9.12.3
Sich gegenseitig ausschließende Optionen (JRadioButton) ...........................
743
9.13 Fortschritte bei Operationen überwachen * .........................................................................
18
739
9.12.1
745
9.13.1
Fortschrittsbalken (JProgressBar) ...........................................................................
745
9.13.2
Dialog mit Fortschrittsanzeige (ProgressMonitor) ...........................................
748
Inhalt
9.14 Menüs und Symbolleisten .......................................................................................................... 9.14.1
Die Menüleisten und die Einträge ..........................................................................
748 748
9.14.2
Menüeinträge definieren ...........................................................................................
750
9.14.3
Einträge durch Action-Objekte beschreiben ........................................................
751
9.14.4
Mit der Tastatur: Mnemonics und Shortcut ........................................................
752
9.14.5
Der Tastatur-Shortcut (Accelerator) .......................................................................
753
9.14.6
Tastenkürzel (Mnemonics) ........................................................................................
755
9.14.7
Symbolleisten alias Toolbars ....................................................................................
756
9.14.8
Popup-Menüs ................................................................................................................
759
9.14.9
System-Tray nutzen * ..................................................................................................
764
9.15 Das Model-View-Controller-Konzept ......................................................................................
765
9.16 Auswahlmenüs, Listen und Spinner .........................................................................................
767
9.16.1
Listen (JList) ....................................................................................................................
767
9.16.2
Auswahlmenü (JComboBox) .....................................................................................
775
9.16.3
Drehfeld (JSpinner) * ....................................................................................................
787
9.16.4
Datumsauswahl * ..........................................................................................................
789
9.17 Tabellen (JTable) ............................................................................................................................ 9.17.1
789
Ein eigenes Tabellen-Model ......................................................................................
791
9.17.2
Basisklasse für eigene Modelle (AbstractTableModel) .....................................
792
9.17.3
Ein vorgefertigtes Standard-Modell (DefaultTableModel) ..............................
796
9.17.4
Ein eigener Renderer für Tabellen ..........................................................................
798
9.17.5
Zell-Editoren ..................................................................................................................
801
9.17.6
Größe und Umrandung der Zellen * .......................................................................
803
9.17.7
Spalteninformationen * .............................................................................................
803
9.17.8
Tabellenkopf von Swing-Tabellen * ........................................................................
804
9.17.9
Selektionen einer Tabelle * ........................................................................................
805
9.17.10 Automatisches Sortieren und Filtern mit RowSorter * ....................................
806
9.18 Bäume (JTree) .................................................................................................................................
809
9.18.1
JTree und sein TreeModel und TreeNode .............................................................
809
9.18.2
Selektionen bemerken ................................................................................................
811
9.18.3
Das TreeModel von JTree * .........................................................................................
811
9.19 JRootPane und JDesktopPane * .................................................................................................
815
9.19.1
Wurzelkomponente der Top-Level-Komponenten (JRootPane) ...................
815
9.19.2
JDesktopPane und die Kinder von JInternalFrame ...........................................
815
9.19.3
JLayeredPane .................................................................................................................
817
9.20 Dialoge und Window-Objekte ...................................................................................................
818
9.20.1
JWindow und JDialog ..................................................................................................
818
19
Inhalt
9.20.2
Modal oder nicht-modal? ..........................................................................................
819
9.20.3
Standarddialoge mit JOptionPane .........................................................................
820
9.20.4
Der Dateiauswahldialog ............................................................................................
823
9.20.5
Der Farbauswahldialog JColorChooser * ...............................................................
827
9.21 Flexibles Java-Look-and-Feel ....................................................................................................
830
9.21.1
Look and Feel global setzen ......................................................................................
830
9.21.2
UIManager .....................................................................................................................
830
9.21.3
Die Windows-Optik mit JGoodies Looks verbessern * .....................................
833
9.22 Swing-Komponenten neu erstellen oder verändern * .......................................................
833
9.22.1
Überlagerungen mit dem Swing-Komponenten-Dekorator JLayer ............
834
9.23 Die Zwischenablage (Clipboard) ...............................................................................................
836
9.23.1
Clipboard-Objekte .......................................................................................................
836
9.23.2
Mit Transferable auf den Inhalt zugreifen ...........................................................
837
9.23.3
DataFlavor ist das Format der Daten in der Zwischenablage ........................
838
9.23.4
Einfügungen in der Zwischenablage erkennen ..................................................
840
9.23.5
Drag & Drop ...................................................................................................................
841
9.24 Undo durchführen * .....................................................................................................................
842
9.25 AWT, Swing und die Threads .....................................................................................................
844
9.25.1
Ereignisschlange (EventQueue) und AWT-Event-Thread ................................
844
9.25.2
Swing ist nicht thread-sicher ...................................................................................
845
9.25.3
invokeLater() und invokeAndWait() ......................................................................
848
9.25.4
SwingWorker .................................................................................................................
851
9.25.5
Eigene Ereignisse in die Queue setzen * ...............................................................
853
9.25.6
Auf alle Ereignisse hören * ........................................................................................
854
9.26 Barrierefreiheit mit der Java Accessibility API .....................................................................
854
9.27 Zeitliches Ausführen mit dem javax.swing.Timer ..............................................................
855
9.28 Die Zusatzkomponentenbibliothek SwingX .........................................................................
856
9.28.1
Im Angebot: Erweiterte und neue Swing-Komponenten ...............................
857
9.28.2
Überblick über erweiterte Standard-Swing-Klassen .........................................
857
9.28.3
Neue Swing-Klassen ....................................................................................................
858
9.28.4
Weitere SwingX-Klassen ............................................................................................
859
9.28.5
SwingX-Installation ....................................................................................................
860
9.29 Alternativen zu programmierten Oberflächen, AWT und Swing * .................................
860
9.29.1
Deklarative Beschreibungen der Oberfläche: Swing JavaBuilder, Swixml
860
9.29.2
SWT (Standard Widget Toolkit) ...............................................................................
862
9.30 Zum Weiterlesen ..........................................................................................................................
864
20
Inhalt
10 Grafikprogrammierung 10.1 Grundlegendes zum Zeichnen .................................................................................................
865
10.1.1
Die paint()-Methode für das AWT-Frame ............................................................
865
10.1.2
Zeichnen von Inhalten auf ein JFrame ................................................................
867
10.1.3
Auffordern zum Neuzeichnen mit repaint() ......................................................
869
10.1.4
Java 2D-API ...................................................................................................................
869
10.2 Einfache Zeichenmethoden ......................................................................................................
870
10.2.1
Linien .............................................................................................................................
870
10.2.2
Rechtecke ......................................................................................................................
871
10.2.3
Ovale und Kreisbögen ...............................................................................................
872
10.2.4
Polygone und Polylines ............................................................................................
874
10.3 Zeichenketten schreiben und Fonts .......................................................................................
876
10.3.1
Zeichenfolgen schreiben ..........................................................................................
877
10.3.2
Die Font-Klasse ...........................................................................................................
878
10.3.3
Einen neuen Font aus einem gegebenen Font ableiten .................................
880
10.3.4
Zeichensätze des Systems ermitteln * .................................................................
880
10.3.5
Neue TrueType-Fonts in Java nutzen ...................................................................
881
10.3.6
Font-Metadaten durch FontMetrics * ..................................................................
882
10.4 Geometrische Objekte ...............................................................................................................
886
10.4.1
Die Schnittstelle Shape .............................................................................................
888
10.4.2
Kreisförmiges ..............................................................................................................
889
10.4.3
Kurviges * ......................................................................................................................
890
10.4.4
Area und die konstruktive Flächengeometrie * ................................................
890
10.4.5
Pfade * ............................................................................................................................
891
10.4.6
Punkt in einer Form, Schnitt von Linien, Abstand Punkt/Linie * ...............
895
10.5 Das Innere und Äußere einer Form ........................................................................................ 10.5.1
Farben und die Paint-Schnittstelle .......................................................................
896 896
10.5.2
Farben mit der Klasse Color ....................................................................................
897
10.5.3
Die Farben des Systems über SystemColor * .....................................................
903
10.5.4
Composite und Xor * .................................................................................................
907
10.5.5
Dicke und Art der Linien von Formen bestimmen über Stroke * ...............
908
10.6 Bilder ...............................................................................................................................................
913
10.6.1
Eine Übersicht über die Bilder-Bibliotheken .....................................................
914
10.6.2
Bilder mit ImageIO lesen .........................................................................................
915
10.6.3
Ein Bild zeichnen ........................................................................................................
917
10.6.4
Programm-Icon/Fenster-Icon setzen ...................................................................
921
21
Inhalt
10.6.5
Splash-Screen * ...........................................................................................................
922
10.6.6
Bilder im Speicher erzeugen * ................................................................................
922
10.6.7
Pixel für Pixel auslesen und schreiben * ............................................................
925
10.6.8
Bilder skalieren * ........................................................................................................
927
10.6.9
Schreiben mit ImageIO ............................................................................................
929
10.6.10 Asynchrones Laden mit getImage() und dem MediaTracker * ....................
934
10.7 Weitere Eigenschaften von Graphics * .................................................................................
935
10.7.1
Eine Kopie von Graphics erstellen .......................................................................
10.7.2
Koordinatensystem verschieben .........................................................................
936
10.7.3
Beschnitt (Clipping) ..................................................................................................
937
10.7.4
Zeichenhinweise durch RenderingHints ...........................................................
941
10.7.5
Transformationen mit einem AffineTransform-Objekt ...............................
941
10.8 Drucken * .......................................................................................................................................
935
944
10.8.1
Drucken der Inhalte ..................................................................................................
944
10.8.2
Bekannte Drucker ......................................................................................................
946
10.9 Benutzerinteraktionen automatisieren, Robot und Screenshots * ..............................
947
10.9.1
Der Roboter .................................................................................................................
947
10.9.2
Automatisch in die Tasten hauen ........................................................................
948
10.9.3
Automatisierte Mausoperationen .......................................................................
949
10.9.4
Methoden zur Zeitsteuerung .................................................................................
949
10.9.5
Bildschirmabzüge (Screenshots) ...........................................................................
950
10.9.6
Funktionsweise und Beschränkungen ................................................................
952
10.9.7
MouseInfo und PointerInfo ...................................................................................
952
10.10 Zum Weiterlesen ........................................................................................................................
953
11 Netzwerkprogrammierung 11.1 Grundlegende Begriffe .............................................................................................................
955
11.2 URI und URL ..................................................................................................................................
957
11.2.1
Die Klasse URI .............................................................................................................
11.2.2
Die Klasse URL ............................................................................................................
958
11.2.3
Informationen über eine URL * .............................................................................
961
11.2.4
Der Zugriff auf die Daten über die Klasse URL .................................................
963
11.3 Die Klasse URLConnection * .....................................................................................................
965
22
957
11.3.1
Methoden und Anwendung von URLConnection ...........................................
965
11.3.2
Protokoll- und Content-Handler ..........................................................................
967
Inhalt
11.3.3
Im Detail: vom URL zur URLConnection ............................................................
968
11.3.4
Der Protokoll-Handler für Jar-Dateien ................................................................
969
11.3.5
Basic Authentication und Proxy-Authentifizierung .......................................
971
11.4 Mit GET und POST Daten übergeben * ..................................................................................
973
11.4.1
Kodieren der Parameter für Serverprogramme ...............................................
974
11.4.2
Eine Suchmaschine mit GET-Request ansprechen ..........................................
975
11.4.3
POST-Request absenden ...........................................................................................
976
11.5 Host- und IP-Adressen ...............................................................................................................
977
11.5.1
Lebt der Rechner? .......................................................................................................
980
11.5.2
IP-Adresse des lokalen Hosts ..................................................................................
980
11.5.3
Das Netz ist klasse ......................................................................................................
981
11.5.4
NetworkInterface .......................................................................................................
981
11.6 Mit dem Socket zum Server ......................................................................................................
983
11.6.1
Das Netzwerk ist der Computer .............................................................................
983
11.6.2
Sockets ...........................................................................................................................
983
11.6.3
Eine Verbindung zum Server aufbauen ..............................................................
984
11.6.4
Server unter Spannung: die Ströme .....................................................................
985
11.6.5
Die Verbindung wieder abbauen ...........................................................................
986
11.6.6
Informationen über den Socket * ..........................................................................
986
11.6.7
Reine Verbindungsdaten über SocketAddress * ...............................................
988
11.7 Client-Server-Kommunikation ................................................................................................
989
11.7.1
Warten auf Verbindungen .......................................................................................
990
11.7.2
Ein Multiplikationsserver ........................................................................................
991
11.7.3
Blockierendes Lesen ..................................................................................................
995
11.7.4
Von außen erreichbar sein * ...................................................................................
996
11.8 Apache HttpComponents und Commons Net * ..................................................................
997
11.8.1
HttpComponents .......................................................................................................
997
11.8.2
Apache Commons Net ..............................................................................................
998
11.9 Arbeitsweise eines Webservers * ............................................................................................
998
11.9.1
Das Hypertext Transfer Protocol (HTTP) ............................................................
998
11.9.2
Anfragen an den Server ............................................................................................
999
11.9.3
Die Antworten vom Server ...................................................................................... 1002
11.9.4
Webserver mit com.sun.net.httpserver.HttpServer ........................................ 1006
11.10 Verbindungen durch einen Proxy-Server * .......................................................................... 1007 11.10.1 System-Properties ...................................................................................................... 1008 11.10.2 Verbindungen durch die Proxy-API ..................................................................... 1008
23
Inhalt
11.11 Datagram-Sockets * ...................................................................................................................
1010
11.11.1 Die Klasse DatagramSocket ....................................................................................
1012
11.11.2 Datagramme und die Klasse DatagramPacket .................................................
1013
11.11.3 Auf ein hereinkommendes Paket warten ..........................................................
1014
11.11.4 Ein Paket zum Senden vorbereiten ......................................................................
1015
11.11.5 Methoden der Klasse DatagramPacket ...............................................................
1016
11.11.6 Das Paket senden .......................................................................................................
1017
11.12 E-Mail * ..........................................................................................................................................
1019
11.12.1 Wie eine E-Mail um die Welt geht ........................................................................
1019
11.12.2 Das Simple Mail Transfer Protocol und RFC 822 .............................................
1019
11.12.3 POP (Post Office Protocol) .......................................................................................
1020
11.12.4 Die JavaMail API .........................................................................................................
1020
11.12.5 E-Mails mittels POP3 abrufen ................................................................................
1023
11.12.6 Multipart-Nachrichten verarbeiten .....................................................................
1025
11.12.7 E-Mails versenden .....................................................................................................
1027
11.12.8 Ereignisse und Suchen .............................................................................................
1030
11.13 Tiefer liegende Netzwerkeigenschaften * ...........................................................................
1031
11.13.1 Internet Control Message Protocol (ICMP) ........................................................
1031
11.13.2 MAC-Adresse ...............................................................................................................
1032
11.14 Zum Weiterlesen ........................................................................................................................
1033
12 Verteilte Programmierung mit RMI 12.1 Entfernte Objekte und Methoden .........................................................................................
1035
12.1.1
Stellvertreter helfen bei entfernten Methodenaufrufen ..............................
1035
12.1.2
Standards für entfernte Objekte ...........................................................................
1037
12.2 Java Remote Method Invocation ...........................................................................................
1038
12.2.1
Zusammenspiel von Server, Registry und Client ............................................
1038
12.2.2
Wie die Stellvertreter die Daten übertragen .....................................................
1038
12.2.3
Probleme mit entfernten Methoden ...................................................................
1039
12.2.4
Nutzen von RMI bei Middleware-Lösungen ......................................................
1040
12.2.5
Zentrale Klassen und Schnittstellen ....................................................................
1041
12.2.6
Entfernte und lokale Objekte im Vergleich .......................................................
1042
12.3 Auf der Serverseite .....................................................................................................................
1042
24
12.3.1
Entfernte Schnittstelle deklarieren ......................................................................
1042
12.3.2
Remote-Objekt-Implementierung .......................................................................
1043
Inhalt
12.3.3
Stellvertreterobjekte ................................................................................................. 1044
12.3.4
Der Namensdienst (Registry) .................................................................................. 1045
12.3.5
Remote-Objekt-Implementierung exportieren und beim Namensdienst anmelden ........................................................................................ 1047
12.3.6
Einfaches Logging ...................................................................................................... 1049
12.3.7
Aufräumen mit dem DGC * ..................................................................................... 1050
12.4 Auf der Clientseite ...................................................................................................................... 1051 12.5 Entfernte Objekte übergeben und laden ............................................................................. 1052 12.5.1
Klassen vom RMI-Klassenlader nachladen ........................................................ 1052
12.6 Weitere Eigenschaften von RMI .............................................................................................. 1053 12.6.1
RMI und CORBA .......................................................................................................... 1053
12.6.2
RMI über HTTP getunnelt ........................................................................................ 1054
12.6.3
Automatische Remote-Objekt-Aktivierung ....................................................... 1054
12.7 Java Message Service (JMS) ...................................................................................................... 1055 12.8 Zum Weiterlesen ......................................................................................................................... 1055
13 RESTful und SOAP Web-Services 13.1 Web-Services ................................................................................................................................ 1057 13.2 RESTful Web-Services ................................................................................................................. 1059 13.2.1
Aus Prinzip REST ......................................................................................................... 1059
13.2.2
Jersey .............................................................................................................................. 1060
13.2.3
JAX-RS-Annotationen für den ersten REST-Service ......................................... 1061
13.2.4
Test-Server starten ..................................................................................................... 1062
13.2.5
REST-Services konsumieren .................................................................................... 1063
13.2.6
Content-Hander, Marshaller und verschiedene MIME-Typen ..................... 1064
13.2.7
REST-Parameter .......................................................................................................... 1067
13.2.8
REST-Services mit Parametern über die Jersey-Client-API aufrufen .......... 1069
13.2.9
PUT-Anforderungen und das Senden von Daten ............................................. 1070
13.2.10 PUT/POST/DELETE-Sendungen mit der Jersey-Client-API absetzen .......... 1071
13.3 Daily Soap und das SOAP-Protokoll ....................................................................................... 1071 13.3.1
Die technische Realisierung .................................................................................... 1072
13.3.2
Web-Service-APIs und Implementierungen ...................................................... 1072
13.3.3
@WebService in Java 6 ............................................................................................. 1073
13.3.4
Einen Web-Service definieren ................................................................................ 1074
25
Inhalt
13.3.5
Web-Services veröffentlichen ................................................................................
1075
13.3.6
Einen JAX-WS-Client implementieren ................................................................
1076
13.4 Zum Weiterlesen ........................................................................................................................
1078
14 JavaServer Pages und Servlets 14.1 Dynamisch generierte Webseiten .........................................................................................
1079
14.1.1
Was sind Servlets? .....................................................................................................
1080
14.1.2
Was sind JavaServer Pages? ....................................................................................
1081
14.2 Servlets und JSPs mit Tomcat entwickeln ...........................................................................
1082
14.2.1
Servlet-Container .......................................................................................................
1082
14.2.2
Entwicklung der Servlet/JSP-Spezifikationen ...................................................
1083
14.2.3
Webserver mit Servlet-Funktionalität ................................................................
1083
14.2.4
Tomcat installieren ...................................................................................................
1084
14.2.5
Ablageort für eigene JSPs ........................................................................................
1086
14.2.6
Webapplikationen .....................................................................................................
1087
14.2.7
Zuordnung von Webapplikationen zu physikalischen Verzeichnissen ...
1088
14.2.8
Web-Projekt mit Eclipse IDE for Java EE Developers ......................................
1088
14.3 Statisches und Dynamisches ...................................................................................................
1090
14.3.1
Statischer Template-Code .......................................................................................
1090
14.3.2
Dynamische Inhalte ..................................................................................................
1090
14.3.3
Kommentare ...............................................................................................................
1091
14.4 Die Expression Language (EL) ..................................................................................................
1091
14.4.1
Operatoren der EL ......................................................................................................
1092
14.4.2
Literale ..........................................................................................................................
1092
14.4.3
Implizite EL-Objekte .................................................................................................
1093
14.5 Formulardaten .............................................................................................................................
1094
14.5.1
Einen Parameter auslesen ......................................................................................
1094
14.5.2
HTML-Formulare .......................................................................................................
1095
14.6 Auf Beans zurückgreifen ..........................................................................................................
1096
14.6.1
26
Beans in JSPs anlegen ...............................................................................................
1097
14.6.2
Properties einer Bean im EL-Ausdruck erfragen ..............................................
1097
14.6.3
Properties mit setzen ............................................................
1097
14.6.4
Bean-Klasse zum Testen von E-Mail-Adressen .................................................
1098
14.6.5
Parameterwerte in Bean übertragen ...................................................................
1100
Inhalt
14.7 JSP-Tag-Libraries .......................................................................................................................... 1101 14.7.1
Standard Tag Library (JSTL) ..................................................................................... 1101
14.8 Skripting-Elemente in JSPs ....................................................................................................... 1105 14.8.1
Scriptlets ....................................................................................................................... 1106
14.8.2
JSP-Ausdrücke ............................................................................................................. 1106
14.8.3
JSP-Deklarationen ...................................................................................................... 1107
14.8.4
Quoting .......................................................................................................................... 1107
14.8.5
Entsprechende XML-Tags ........................................................................................ 1108
14.8.6
Implizite Objekte für Scriptlets und JSP-Ausdrücke ........................................ 1108
14.9 Sitzungsverfolgung (Session Tracking) ................................................................................. 1109 14.9.1
Lösungen für die Sitzungsverfolgung .................................................................. 1109
14.9.2
Sitzungen in JSPs ........................................................................................................ 1110
14.9.3
Auf Session-Dateien zurückgreifen ...................................................................... 1111
14.10 Servlets ........................................................................................................................................... 1111 14.10.1 Servlets compilieren ................................................................................................. 1115 14.10.2 Servlet-Mapping ......................................................................................................... 1116 14.10.3 Der Lebenszyklus eines Servlets ............................................................................ 1117 14.10.4 Mehrere Anfragen beim Servlet und die Thread-Sicherheit ......................... 1118 14.10.5 Servlets und Sessions ................................................................................................ 1118 14.10.6 Weiterleiten und Einbinden von Servlet-Inhalten .......................................... 1119
14.11 Zum Weiterlesen ......................................................................................................................... 1120
15 Applets 15.1 Applets in der Wiege von Java ................................................................................................ 1123 15.1.1
Applets heute ............................................................................................................... 1123
15.1.2
(J)Applet und Applikationen ................................................................................... 1124
15.1.3
Das erste Hallo-Applet .............................................................................................. 1125
15.2 Die Applet-API .............................................................................................................................. 1127 15.2.1
Die Zyklen eines Applets .......................................................................................... 1127
15.2.2
Parameter an das Applet übergeben .................................................................... 1127
15.2.3
Wie das Applet den Browser-Inhalt ändern kann * .......................................... 1129
15.2.4
Den Ursprung des Applets erfragen ..................................................................... 1130
15.2.5
Datenaustausch zwischen Applets * ..................................................................... 1131
15.2.6
Was ein Applet alles darf * ....................................................................................... 1134
27
Inhalt
15.2.7
Ist Java im Browser aktiviert? * ..............................................................................
1135
15.2.8
Applet unter Firefox (Netscape) oder Microsoft Internet Explorer? * .......
1135
15.3 Webstart .......................................................................................................................................
1137
15.4 Zum Weiterlesen ........................................................................................................................
1137
16 Datenbankmanagement mit JDBC 16.1 Relationale Datenbanken ........................................................................................................ 16.1.1
1139
Das relationale Modell .............................................................................................
1139
16.2 Datenbanken und Tools ............................................................................................................
1140
16.2.1
HSQLDB .........................................................................................................................
1141
16.2.2
Weitere Datenbanken * ............................................................................................
1142
16.2.3
Eclipse-Plugins zum Durchschauen von Datenbanken .................................
1145
16.3 JDBC und Datenbanktreiber ....................................................................................................
1148
16.3.1
Treibertypen * .............................................................................................................
1149
16.3.2
JDBC-Versionen * .......................................................................................................
1151
16.4 Eine Beispielabfrage ..................................................................................................................
1152
16.4.1
Schritte zur Datenbankabfrage .............................................................................
1152
16.4.2
Ein Client für die HSQLDB-Datenbank ................................................................
1153
16.4.3
Datenbankbrowser und eine Beispielabfrage unter NetBeans ...................
1155
16.5 Mit Java an eine Datenbank andocken ................................................................................
1159
16.5.1
Der Treiber-Manager * ..............................................................................................
1160
16.5.2
Den Treiber laden ......................................................................................................
1160
16.5.3
Eine Aufzählung aller Treiber * ..............................................................................
1162
16.5.4
Log-Informationen * .................................................................................................
1162
16.5.5
Verbindung zur Datenbank auf- und abbauen ................................................
1163
16.6 Datenbankabfragen ...................................................................................................................
1167
28
16.6.1
Abfragen über das Statement-Objekt ..................................................................
1168
16.6.2
Ergebnisse einer Abfrage in ResultSet ................................................................
1169
16.6.3
Java und SQL-Datentypen .......................................................................................
1170
16.6.4
Date, Time und Timestamp ....................................................................................
1173
16.6.5
Unicode in der Spalte korrekt auslesen ..............................................................
1175
16.6.6
Eine SQL-NULL und wasNull() bei ResultSet ......................................................
1175
16.6.7
Wie viele Zeilen hat ein ResultSet? * ....................................................................
1176
Inhalt
16.7 Elemente einer Datenbank hinzufügen und aktualisieren ............................................. 1176 16.7.1
Batch-Updates ............................................................................................................. 1177
16.7.2
Die Ausnahmen bei JDBC, SQLException und Unterklassen ........................ 1179
16.8 ResultSet und RowSet * ............................................................................................................. 1182 16.8.1
Die Schnittstelle RowSet .......................................................................................... 1182
16.8.2
Implementierungen von RowSet .......................................................................... 1182
16.8.3
Der Typ CachedRowSet ............................................................................................. 1183
16.8.4
Der Typ WebRowSet .................................................................................................. 1184
16.9 Vorbereitete Anweisungen (Prepared Statements) .......................................................... 1187 16.9.1
PreparedStatement-Objekte vorbereiten ........................................................... 1187
16.9.2
Werte für die Platzhalter eines PreparedStatement ........................................ 1189
16.10 Transaktionen .............................................................................................................................. 1190 16.11 Metadaten * .................................................................................................................................. 1190 16.11.1 Metadaten über die Tabelle ..................................................................................... 1190 16.11.2 Informationen über die Datenbank ..................................................................... 1194
16.12 Vorbereitete Datenbankverbindungen ................................................................................ 1195 16.12.1 DataSource ................................................................................................................... 1195 16.12.2 Gepoolte Verbindungen ........................................................................................... 1198
16.13 JPA-Beispiel mit der NetBeans-IDE ......................................................................................... 1199 16.13.1 Entity-Beans generieren ........................................................................................... 1199 16.13.2 Die Quellen im Überblick ......................................................................................... 1201 16.13.3 Persistence Unit .......................................................................................................... 1203 16.13.4 Ein JPA-Beispielprogramm ...................................................................................... 1204
16.14 Zum Weiterlesen ......................................................................................................................... 1205
17 Technologien für die Infrastruktur 17.1 Property-Validierung durch Bean Validation ...................................................................... 1207 17.1.1
Technische Abhängigkeiten und POJOs .............................................................. 1218
17.2 Wie eine Implementierung an die richtige Stelle kommt ............................................... 1220 17.2.1
Arbeiten mit dem ServiceLoader ........................................................................... 1221
17.2.2
Die Utility-Klasse Lookup als ServiceLoader-Fassade ..................................... 1223
17.2.3
Contexts and Dependency Injection (CDI) aus dem JSR-299 ........................ 1224
17.3 Zum Weiterlesen ......................................................................................................................... 1226
29
Inhalt
18 Reflection und Annotationen 18.1 Metadaten .................................................................................................................................... 18.1.1
Metadaten durch JavaDoc-Tags .............................................................................
18.2 Metadaten der Klassen mit dem Class-Objekt ...................................................................
1227 1227 1228
18.2.1
An ein Class-Objekt kommen ................................................................................
1228
18.2.2
Was das Class-Objekt beschreibt * ........................................................................
1231
18.2.3
Der Name der Klasse .................................................................................................
1233
18.2.4
instanceof mit Class-Objekten * ............................................................................
1235
18.2.5
Oberklassen finden * .................................................................................................
1236
18.2.6
Implementierte Interfaces einer Klasse oder eines Interfaces * .................
1237
18.2.7
Modifizierer und die Klasse Modifier * ...............................................................
1238
18.2.8
Die Arbeit auf dem Feld * .........................................................................................
1240
18.3 Attribute, Methoden und Konstruktoren ............................................................................
1241
18.3.1
Reflections – Gespür für die Attribute einer Klasse ........................................
1243
18.3.2
Methoden einer Klasse erfragen ...........................................................................
1246
18.3.3
Properties einer Bean erfragen .............................................................................
1250
18.3.4
Konstruktoren einer Klasse ....................................................................................
1250
18.3.5
Annotationen ..............................................................................................................
1253
18.4 Objekte erzeugen und manipulieren ....................................................................................
1253
18.4.1
Objekte erzeugen .......................................................................................................
1253
18.4.2
Die Belegung der Variablen erfragen ..................................................................
1255
18.4.3
Eine generische eigene toString()-Methode * ...................................................
1257
18.4.4
Variablen setzen .........................................................................................................
1260
18.4.5
Bean-Zustände kopieren * .......................................................................................
1262
18.4.6
Private Attribute ändern .........................................................................................
1262
18.4.7
Methoden aufrufen ...................................................................................................
1263
18.4.8
Statische Methoden aufrufen ................................................................................
1265
18.4.9
Dynamische Methodenaufrufe bei festen Methoden beschleunigen * ....
1266
18.5 Eigene Annotationstypen * ......................................................................................................
1268
30
18.5.1
Annotationen zum Laden von Ressourcen .......................................................
1268
18.5.2
Neue Annotationen deklarieren ...........................................................................
1269
18.5.3
Annotationen mit genau einem Attribut ..........................................................
1270
18.5.4
Element-Werte-Paare (Attribute) hinzufügen ..................................................
1271
18.5.5
Annotationsattribute vom Typ einer Aufzählung ..........................................
1272
Inhalt
18.5.6
Felder von Annotationsattributen ....................................................................... 1273
18.5.7
Vorbelegte Attribute ................................................................................................. 1274
18.5.8
Annotieren von Annotationstypen ...................................................................... 1276
18.5.9
Deklarationen für unsere Ressourcen-Annotationen .................................... 1280
18.5.10 Annotierte Elemente auslesen ............................................................................... 1282 18.5.11 Auf die Annotationsattribute zugreifen ............................................................. 1283 18.5.12 Komplettbeispiel zum Initialisieren von Ressourcen .................................... 1284 18.5.13 Mögliche Nachteile von Annotationen ............................................................... 1287
18.6 Zum Weiterlesen ......................................................................................................................... 1288
19 Dynamische Übersetzung und Skriptsprachen 19.1 Codegenerierung ......................................................................................................................... 1290 19.1.1
Generierung von Java-Quellcode .......................................................................... 1291
19.1.2
Codetransformationen ............................................................................................. 1294
19.1.3
Erstellen von Java-Bytecode .................................................................................... 1294
19.2 Programme mit der Compiler API übersetzen .................................................................... 1295 19.2.1
Java Compiler API ....................................................................................................... 1295
19.2.2
Fehler-Diagnose .......................................................................................................... 1298
19.2.3
Eine im String angegebene Compiliationseinheit übersetzen .................... 1300
19.2.4
Wenn Quelle und Ziel der Speicher sind ............................................................. 1302
19.3 Ausführen von Skripten ............................................................................................................ 1306 19.3.1
JavaScript-Programme ausführen ........................................................................ 1306
19.3.2
Groovy ........................................................................................................................... 1308
19.4 Zum Weiterlesen ......................................................................................................................... 1314
20 Logging und Monitoring 20.1 Logging mit Java .......................................................................................................................... 1315 20.1.1
Logging-APIs ................................................................................................................ 1315
20.1.2
Logging mit java.util.logging .................................................................................. 1316
20.1.3
Logging mit log4j * ..................................................................................................... 1320
20.1.4
Die Simple Logging Facade ...................................................................................... 1323
20.2 Systemzustände überwachen .................................................................................................. 1324
31
Inhalt
20.3 MBean-Typen, MBean-Server und weitere Begriffe ......................................................... 20.3.1
1325
MXBeans des Systems ..............................................................................................
1325
20.4 Geschwätzige Programme und JConsole .............................................................................
1328
20.4.1
JConsole ........................................................................................................................
1328
20.5 Der MBeanServer ........................................................................................................................
1330
20.6 Eine eigene Standard-MBean ..................................................................................................
1331
20.6.1
Management-Schnittstelle .....................................................................................
1332
20.6.2
Implementierung der Managed-Ressource .......................................................
1332
20.6.3
Anmeldung beim Server .........................................................................................
1333
20.6.4
Eine eigene Bean in JConsole einbringen ..........................................................
1333
20.7 Zum Weiterlesen ........................................................................................................................
1336
21 Java Native Interface (JNI) 21.1 Java Native Interface und Invocation-API ........................................................................... 21.2 Eine C-Funktion in ein Java-Programm einbinden ............................................................ 21.2.1
Den Java-Code schreiben .........................................................................................
21.3 Dynamische Bibliotheken erzeugen ..................................................................................... 21.3.1
1337 1338 1338 1340
Die Header-Datei erzeugen .....................................................................................
1340
21.3.2
Implementierung der Funktion in C ...................................................................
1342
21.3.3
Die C-Programme übersetzen und die dynamische Bibliothek überzeugen ..................................................................................................................
1343
21.4 Nativ die Stringlänge ermitteln .............................................................................................
1345
21.5 Erweiterte JNI-Eigenschaften ..................................................................................................
1347
21.5.1
Klassendefinitionen .................................................................................................
1347
21.5.2
Zugriff auf Attribute .................................................................................................
1348
21.5.3
Methoden aufrufen ...................................................................................................
1350
21.5.4
Threads und Synchronisation ...............................................................................
1352
21.6 Einfache Anbindung von existierenden Bibliotheken .....................................................
1352
21.6.1
Generieren von JNI-Wrappern aus C++-Klassen und C-Headern ................
1352
21.6.2
COM-Schnittstellen anzapfen ................................................................................
1353
21.7 Invocation-API .............................................................................................................................
1353
21.8 Zum Weiterlesen ........................................................................................................................
1354
32
Inhalt
22 Sicherheitskonzepte 22.1 Zentrale Elemente der Java-Sicherheit ................................................................................. 1355 22.1.1
Security-API der Java SE ............................................................................................ 1355
22.1.2
Cryptographic Service Providers ........................................................................... 1356
22.2 Der Sandkasten (Sandbox) ....................................................................................................... 1357 22.3 Sicherheitsmanager (Security Manager) .............................................................................. 1358 22.3.1
Der Sicherheitsmanager bei Applets .................................................................... 1359
22.3.2
Sicherheitsmanager aktivieren .............................................................................. 1361
22.3.3
Rechte durch Policy-Dateien vergeben ............................................................... 1363
22.3.4
Erstellen von Rechtedateien mit dem grafischen Policy-Tool ..................... 1365
22.3.5
Kritik an den Policies ................................................................................................ 1366
22.4 Signierung ..................................................................................................................................... 1368 22.4.1
Warum signieren? ...................................................................................................... 1368
22.4.2
Digitale Ausweise und die Zertifizierungsstelle ............................................... 1368
22.4.3
Mit keytool Schlüssel erzeugen ............................................................................. 1369
22.4.4
Signieren mit jarsigner ............................................................................................. 1370
22.5 Digitale Unterschriften * ........................................................................................................... 1371 22.5.1
Die MDx-Reihe ............................................................................................................ 1371
22.5.2
Secure Hash Algorithm (SHA) ................................................................................ 1372
22.5.3
Mit der Security-API einen Fingerabdruck berechnen ................................... 1372
22.5.4
Die Klasse MessageDigest ........................................................................................ 1373
22.6 Verschlüsseln von Daten(-strömen) * .................................................................................... 1375 22.6.1
Den Schlüssel, bitte .................................................................................................... 1375
22.6.2
Verschlüsseln mit Cipher ......................................................................................... 1377
22.6.3
Verschlüsseln von Datenströmen ......................................................................... 1377
22.7 Zum Weiterlesen ......................................................................................................................... 1379
23 Dienstprogramme für die Java-Umgebung 23.1 Programme des JDK .................................................................................................................... 1381 23.2 Monitoringprogramme vom JDK ............................................................................................ 1381 23.2.1
jps .................................................................................................................................... 1381
23.2.2
jstat ................................................................................................................................. 1382
23.2.3
jmap ................................................................................................................................ 1382
33
Inhalt
23.2.4
jstack ..............................................................................................................................
1383
23.2.5
VisualVM ......................................................................................................................
1385
23.3 Programmieren mit der Tools-API .........................................................................................
1390
23.3.1
Eigene Doclets .............................................................................................................
23.4 Ant ..................................................................................................................................................
1390 1393
23.4.1
Bezug und Installation von Ant ............................................................................
1393
23.4.2
Das Build-Skript build.xml .....................................................................................
1394
23.4.3
Build den Build ...........................................................................................................
1394
23.4.4
Properties .....................................................................................................................
1395
23.4.5
Externe und vordefinierte Properties .................................................................
1396
23.4.6
Weitere Ant-Tasks ......................................................................................................
1397
23.5 Disassembler, Decompiler und Obfuscator .........................................................................
1398
23.5.1
Der Diassembler javap .............................................................................................
1399
23.5.2
Decompiler ..................................................................................................................
1404
23.5.3
Obfuscatoren ...............................................................................................................
1406
23.6 Weitere Dienstprogramme ......................................................................................................
1408
23.6.1
Sourcecode Beautifier ..............................................................................................
1408
23.6.2
Java-Programme als Systemdienst ausführen .................................................
1409
23.7 Zum Weiterlesen ........................................................................................................................
1410
Index ............................................................................................................................................................
1411
34
Vorwort »Alles, was einen Anfang hat, hat auch ein Ende, und meistens hat das, was ein Ende hat, auch eine Fortsetzung.« – Sprichwort
Willkommen im zweiten Teil der Insel. Während der erste Band in die Grundlagen von Java einführte und sich dabei insbesondere auf die objektorientierten Konzepte und die Syntax der Sprache Java konzentrierte, kümmert sich der zweite Band um die Bibliotheken aus der Java SE.
Organisation der Kapitel Den Einsteig ins Buch bildet Kapitel 1, »Neues in Java 7«, mit einer kompakten Darstellung der Neuerungen. Die Änderungen in den Bibliotheken fließen dabei in die jeweiligen Kapitel ein; so konzentriert sich das kurze Kapitel eher auf die neuen Spracheigenschaften. Kapitel 2 beschäftigt sich mit »Threads und nebenläufiger Programmierung«. Das Kapitel
umfasst auch die Koordination mehrerer kooperierender oder konkurrierender Threads. Seit Java 5 ist ein neues java.util.concurrent-Paket hinzugekommen, das die Programmierung nebenläufiger Programme gegenüber Java 1.0 sehr vereinfacht – dieses neue Paket bildet die Grundlage des Kapitels. Kapitel 3 beschäftigt sich mit den »Datenstrukturen und Algorithmen«, die die Standard-
bibliothek anbietet. Die wichtigsten Klassen wie Listen, Mengen, Stapel, Bitmengen und Assoziativspeicher werden vorgestellt, und dann werden unterschiedliche Aufgaben mit den jeweils passenden Datenstrukturen gelöst. Als Algorithmen kommen beispielsweise vorgefertigte Sortierverfahren zum Einsatz. Das Kapitel diskutiert ebenfalls für Nebenläufigkeit optimierte Datenstrukturen. Zeitzonen und unterschiedliche Ausgabeformate für Datumswerte sind Thema in Kapitel 4, »Raum und Zeit«. Darunter fallen auch Datumsberechnungen auf der Grundlage des gregorianischen Kalenders. Interessant sind Java-Möglichkeiten zur Internationalisierung, was sich durchweg durch alle APIs zieht, die in irgendeiner Weise Nachrichten zum Benutzer geben.
35
Vorwort
Das Kapitel 5, »Dateien, Verzeichnisse und Dateizugriffe«, setzt den Fokus auf Dateiverarbeitung. Zuerst zeigen wir, wie sich Attribute von Dateien und Verzeichnissen auslesen lassen, und dann, wie sich wahlfreier Zugriff auf eine Datei realisieren lässt. Das in Java 7 eingeführte NIO.2-Paket nimmt dabei einen großen Raum ein, da es sehr leistungsfähig ist. Nahtlos folgt in Kapitel 6, »Datenströme«, die Verarbeitung von Daten aus beliebigen Quellen und Senken. Während sich Kapitel 5 nur auf Dateien beschränkt, geht es in diesem Kapitel um allgemeinere Ein-/Ausgabe-Konzepte, die auch bei Datenströmen aus Netzwerken, Datenbanken oder Schnittstellen vorkommen. Die Datenströme können dabei durch Filter geschickt werden. Von Letzteren stellen wir einige vor, die zum Beispiel die Zeilennummer zählen, einen Datenstrom puffern oder ihn komprimieren. Eine elegante Möglichkeit ist das Serialisieren von Objekten. Dabei wird der Zustand eines Objekts ausgelesen und so in einen Datenstrom geschrieben, dass sich das Objekt später wiederherstellen lässt. Eine eigene Speicherroutine kann somit entfallen. Ein neues Thema spannt Kapitel 7 mit »Die eXtensible Markup Language (XML)« auf. Java als plattformunabhängige Programmiersprache und XML als dokumentenunabhängige Beschreibungssprache sind ein ideales Paar, und die Kombination dieser beiden Technologien ist der Renner der letzten Jahre. Das Kapitel beginnt auf der höchsten Abstraktionsebene, beschreibt, wie XML-Daten auf Objekte übertragen werden, und geht dann weiter zur elementaren Verarbeitung der XML-Dokumente, wie sie zum Beispiel als Objekt-Baum aufgebaut und modifiziert werden. Heutzutage ist die Speicherung in XML populär, und auch Office-Dokumente werden in diesem Stil gespeichert. Doch keiner würde auf die Idee kommen, die Dokumente im XML-Format auszulesen und dort die Absätze und Zeichen herauszuziehen. Das Gleiche gilt für Grafikdateien: Es ist zwar eine Byte-Datei, doch die wird nicht als Byte für Byte von uns eingelesen, sondern es gibt immer eine API, die sich darum kümmert, Zeichen oder Bytes in ein für uns komfortables Format zu bringen. Ein paar populäre Dateiformate stellt Kapitel Kapitel 8, »Dateiformate«, vor. Zu den beschriebenen Formaten zählen nicht nur Dokumentenformate, wie für Microsoft Office, sondern auch Formate für die Kompression. Kapitel 9, »Grafische Oberflächen mit Swing«, stellt die Swing-Komponenten zur Interaktion
vor, wie zum Beispiel Schaltflächen. Es geht auf die Behandlung von Ereignissen ein, die aus Benutzeraktionen resultieren, und beschreibt Container, die andere Komponenten aufnehmen und layouten. Das anschließende Kapitel 10 deckt die zweite Aufgabe der grafischen Oberflächen ab, indem es auf die »Grafikprogrammierung« eingeht. Das AWT (Abstract Window Toolkit) ist die JavaMöglichkeit, grafische Oberflächen zu gestalten. Dabei gliedert es sich in zwei große Teile: zum einen in die direkte Ausgabe von Grafik-Primitiven wie Linien, und zum anderen in
36
Vorwort
Komponenten für grafische Oberflächen. Das Kapitel behandelt die Themen Fenster, Zeichenketten und Zeichensätze, Farben und Bilder. Kapitel 11, »Netzwerkprogrammierung«, stellt vor, welche Informationen eine URL hat und
wie mit dieser URL Daten von Webservern bezogen werden können. Bei Webservern werden wir CGI-Programme ansprechen, um an gewünschte Inhalte zu kommen. Mithilfe von Sockets wollen wir eine eigene Client-Server-Kommunikation aufbauen. Außer auf die gesicherte Verbindung TCP gehen wir auch auf ungesicherte UDP-Verbindungen ein. »Verteilte Programmierung mit RMI« in Kapitel 12 zeigt auf, wie ein Java-Programm einfach Objekte und Methoden nutzen kann, die auf einem anderen Rechner gespeichert beziehungsweise ausgeführt werden. Dabei wird der Aufruf einer Methode über das Netzwerk übertragen, und für das aufrufende Programm sieht es so aus, als ob es sich um einen normalen Methodenaufruf für ein lokales Objekt handelt. Kapitel 13, »RESTful und SOAP Web-Services«, stellt mit REST einen neuen Trend in der Kom-
munikation zwischen Browser und Web-Server vor und mit SOAP einen Klassiker für den entfernten Methodenaufruf zwischen Systemen. SOAP ist Teil der Java SE, und für REST wird Jersey vorgestellt, die Referenzimplementierung der JAX-RS-API. Mit Kapitel 14, »JavaServer Pages und Servlets«, geht es dann in die Welt der dynamischen Webseiten. Java ist zurzeit auf der Serverseite sehr populär, und dort besonders beim sogenannten Enterprise-Computing. Mit JavaServer Pages ist es besonders einfach, dynamische Webinhalte zu formulieren und auf die vom Client mitgeschickten Informationen sehr einfach zuzugreifen. JSPs verfügen zudem über die gesamten Java-Möglichkeiten, insbesondere die Fähigkeit zur Datenbankanbindung. Grafische Oberflächen und Netzwerke verbinden das Kapitel 15 zum Thema »Applets«. Applets sind Java-Programme innerhalb eines Webbrowsers. Applets machten Java vor über 10 Jahren auf der Welt bekannt, und die ersten Java-Bücher erklärten alles im Zusammenhang mit Applets. Heutzutage spielen Applets keine große Rolle mehr – auch durch die Verbreitung von Flash – und sind schon fast zu einer Nischentechnologie geworden. »Datenbankmanagement mit JDBC« ist das Thema von Kapitel 16. Als freie, quelloffene Beispieldatenbank wird HSQLDB vorgestellt, da sie sehr leicht zu installieren und zu betreiben ist und praktischerweise Beispieldaten mitbringt. Die Java-Beispiele bauen eine Verbindung zu HSQLDB auf, setzen SQL-Anweisungen ab, holen die Ergebnisse herein und visualisieren sie. Viele der vorgestellen Technologien sind sehr speziell, doch Kapitel 17, »Technologien für die Infrastruktur«, geht auf den Aufbau großer Anwendungen ein und stellt Basistechnologien vor, die ein gutes Fundament für eigene Anwendungen bilden und in jeder Architektur zu finden sein dürften, ob es nun grafische Anwendungen sind oder reine Serveranwendungen.
37
Vorwort
Mit Kapitel 18 widmen wir uns einer Java-typischen Technik: »Reflection und Annotationen«. Java-Klassen liegen selbst wieder als Meta-Objekte, als Exemplare der speziellen Klasse Class, vor. Diese Class-Objekte geben Auskunft über die verfügbaren und definierten Variablen, Methoden und Konstruktoren. So lassen sich beispielsweise dynamisch bestimmte Methoden aufrufen oder die Werte von dynamisch ausgewählten Objektvariablen abfragen. Die Annotationen sind eine bedeutende Neuerung in Java 5. Am Anfang war die JVM fest mit der Programmiersprache Java verbunden, doch das änderte sich im Laufe der Jahre. Heute gibt es unterschiedliche Programmiersprachen, die auf einer JVM laufen – von ganz entwickelten Skriptsprachen bis zu portierten. Kapitel 19, »Dynamische Übersetzung und Skriptsprachen«, stellt Skriptsprachen vor und auch die Möglichkeit, wie eigene Klassen mit der Compiler-API übersetzt werden. Wie Java-Programme zu Testzwecken überwacht werden können, zeigt Kapitel 20, »Logging und Monitoring«. Mit der JMX-API lassen sich MBeans an einem MBean-Server anmelden, und das Dienstprogramm jconsole ermöglicht den Zugriff und die Steuerung der Komponenten. Java kann nicht alles plattformunabhängig lösen. An einer bestimmen Stelle muss plattformabhängiger Programmcode eingebaut werden. Um von Java auf Nicht-Java-Code wie C(++) zuzugreifen, definiert Oracle das in Kapitel 21 vorgestellte »Java Native Interface (JNI)«. Kapitel 22 zeigt kurz »Sicherheitskonzepte«, etwa das Sandkastenprinzip, und Sicherheitsma-
nager auf, zeigt aber auch, wie von Daten eine Prüfsumme gebildet werden kann und wie Daten mit DES oder RSA verschlüsselt werden. In Kapitel 23, »Dienstprogramme für die Java-Umgebung«, geht es um die zum JDK gehörigen Programme und um einige Extratools, die für Ihre Arbeit nützlich sind. Im Mittelpunkt stehen Compiler, Interpreter und die Handhabung von Jar-Archiven. Dieses Archivformat ist vergleichbar mit den bekannten Zip-Archiven und fasst mehrere Dateien zusammen. Mit den eingebetteten Dokumentationskommentaren in Java kann aus einer Quellcodedatei ganz einfach eine komplette HTML-Dokumentation der Klassen, Schnittstellen, Vererbungsbeziehungen und Eigenschaften inklusive Verlinkung erstellt werden. Unter den Programmen, die zu keiner Standardinstallation gehören, sind etwa Tools, die Java-Programme in C-Programme übersetzen, sie neu einrücken und formatieren und Bytecode wieder in lesbaren Java-Quellcode umwandeln.
Vorwort zur 1. Auflage Es ist unverkennbar, dass dieses Buch seinen Ursprung in »Java ist auch eine Insel« hat. Es enthält alle fortgeschrittenen Java-Konzepte der vorangegangenen Insel. Bei dieser Aufspaltung ist es natürlich nicht geblieben, denn sonst wäre das Buch ja auch nur 700 Seiten dick und nicht 1400. Es gab also Änderungen und Neuerungen gegenüber diesen Kapiteln in der alten Insel.
38
Vorwort
Zu den Neuerungen: Natürlich ist das Buch auf der Höhe der Zeit und beschreibt die aktuellen Java 7-Features. Das erste Kapitel fasst die bescheidenen Sprachänderungen zusammen. Aufseiten der Bibliothek gibt es zwei größere Zuwächse: NIO.2 und das kleinere Fork-And-JoinFramework. Swing bietet eine neue Klasse namens JLayer und bekommt kleine Updates, etwa durch eine generische Typvariable etwa bei ListModel oder JComboBox. Ein weiteres neues Kapitel behandelt dynamische Übersetzung mit dem Java-Compiler zur Laufzeit und Skriptsprachen, wobei es einige Beispiele zur beliebten JVM-Sprache Groovy gibt. Und da Web-Services nicht mehr nur durch SOAP realisiert werden, gibt es ein Unterkapitel zum REST-Prinzip und JAW-RS. Im Swing-Kapitel ist eine bildgeführte Anleitung zu finden, wie sich mit NetBeans einfach grafische Oberflächen entwickeln lassen. Am Ende des Swing-Kapitels befindet sich ein Ausblick auf die freie Komponentenbibliothek SwingX, mit der Entwickler die GUIs aufhübschen können. Das Datenbankkapitel hat einen Ausblick auf JPA bekommen, wobei die Beispiele hier auch wieder mit NetBeans realisiert werden. Zu den Aktualisierungen: Auch ohne die Anpassungen aus Java 7 gibt es Verbesserungen und Aktualisierungen. Im Tooling-Bereich ist der Decompiler Jad durch JD ersetzt worden. Gleichzeitig gibt das gleiche Kapitel eine Einführung in Java-Bytecode und das Tool javap. Weiterhin im Bereich Datenbanktools ist eine kleine Änderung nötig geworden, da der Datenbankbrowser in die Eclipse Data Tools Platform (DTP) gewandert ist und sich auch die grafische Oberfläche veränderte. Im Bereich Java ME ist das Plugin zu Eclipse gewandert und trägt jetzt den neuen Namen Eclipse Mobile Tools for Java (MTJ).
Christian Ullenboom
Sonsbeck, im Oktober 2011
39
Kapitel 1
1
Neues in Java 7 »Jede Lösung eines Problems ist ein neues Problem.« – Johann Wolfgang von Goethe (1749–1832)
1.1
Sprachänderungen
Die folgenden Abschnitte stellen Sprachänderungen aus Java 7 vor.
1.1.1
Zahlen im Binärsystem schreiben
Die Literale für Ganzzahlen lassen sich in vier unterschiedlichen Stellenwertsystemen angeben. Das natürlichste ist das Dezimalsystem (auch Zehnersystem genannt), bei dem die Literale aus den Ziffern »0« bis »9« bestehen. Zusätzlich existieren Oktal- und Hexadezimalsysteme, und seit Java 7 die Binärschreibweise. Bis auf Dezimalzahlen beginnen die Zahlen in anderen Formaten mit einem besonderen Präfix. Präfix
Stellenwertsystem
Basis
Darstellung von 1
0b oder 0B
Binär
2
0b1 oder 0B1
0
Oktal
8
01
Kein
Dezimal
10
1
0x oder 0X
Hexadezimal
16
0x1 oder 0X1
Tabelle 1.1: Die Stellenwertsysteme und ihre Schreibweise
1.1.2 Unterstriche bei Ganzzahlen Um eine Anzahl von Millisekunden in Tage zu konvertieren, muss einfach eine Division vorgenommen werden. Um Millisekunden in Sekunden umzurechnen, brauchen wir eine Division durch 1000, von Sekunden auf Minuten eine Division durch 60, von Minuten auf Stun-
41
1
Neues in Java 7
den eine Division durch 60, und die Stunden auf Tage bringt die letzte Division durch 24. Schreiben wir das auf: long millis = 10 * 24*60*60*1000L; long days = millis / 86400000L; System.out.println( days );
// 10
Eine Sache fällt bei der Zahl 86400000 auf: Besonders gut lesbar ist sie nicht. Die eine Lösung ist, es erst gar nicht zu so einer Zahl kommen zu lassen und sie wie in der ersten Zeile durch eine Reihe von Multiplikationen aufzubauen – mehr Laufzeit kostet das nicht, da dieser konstante Ausdruck zur Übersetzungszeit feststeht. Die zweite Variante ist eine neue Schreibweise, die Java 7 einführt: Unterstriche in Zahlen. Anstatt ein numerisches Literal als 86400000 zu schreiben, ist in Java 7 auch Folgendes erlaubt: long millis = 10 * 86_400_000L; long days = millis / 86_400_000L; System.out.println( days );
// 10
Die Unterstriche machen die 1000er-Blöcke gut sichtbar. Hilfreich ist die Schreibweise auch bei Literalen in Binär- und Hexdarstellung, da die Unterstriche hier ebenfalls Blöcke absetzen können.1
Beispiel Unterstriche verdeutlichen Blöcke bei Binär- und Hexadezimalzahlen. int i = 0b01101001_01001101_11100101_01011110; long l = 0x7fff_ffff_ffff_ffffL;
Der Unterstrich darf in jedem Literal stehen, zwei aufeinanderfolgende Unterstriche sind aber nicht erlaubt.
1.1.3 switch (String) Seit Java 7 sind switch-Anweisungen auf String-Objekten möglich. String input = javax.swing.JOptionPane.showInputDialog( "Eingabe" ); switch ( input.toLowerCase() ) 1
42
Bei Umrechnungen zwischen Stunden, Minuten und so weiter hilft auch die Klasse TimeUnit mit einigen statischen toXXX()-Methoden.
1.1
Sprachänderungen
{
1 case "kekse": System.out.println( "Ich mag Keeeekse" ); break; case "kuchen": System.out.println( "Ich mag Kuchen" ); break; case "scholokade": case "lakritze": System.out.println( "Hm. lecker" ); break; default: System.out.printf( "Kann man %s essen?", input );
}
Obwohl Zeichenkettenvergleiche nun möglich sind, fallen Überprüfungen auf reguläre Ausdrücke leider heraus, die insbesondere Skriptsprachen anbieten. Wie auch beim switch mit Ganzzahlen können die Zeichenketten beim String-case-Zweig aus finalen (also nicht änderbaren) Variablen stammen. Ist etwa String KEKSE = "kekse"; vordefiniert, ist case KEKSE: erlaubt.
1.1.4 Zusammenfassen gleicher catch-Blöcke mit dem multi-catch Greift ein Programm auf Teile zurück, die scheitern können, so ergeben sich in komplexeren Abläufen schnell Situationen, in denen unterschiedliche Ausnahmen auftreten können. Entwickler sollten versuchen, den Programmcode in einem try-Block durchzuschreiben, und dann in catch-Blöcken auf alle möglichen Fehler zu reagieren, die den Block vom korrekten Durchlaufen abgehalten haben. Oftmals kommt es zu dem Phänomen, dass die aufgerufenen Programmteile unterschiedliche Ausnahmetypen auslösen, aber die Behandlung der Fehler gleich aussieht. Um Quellcodeduplizierung zu vermeiden, sollte der Programmcode zusammengefasst werden. Nehmen wir an, die Behandlung der Ausnahmen SQLException und IOException soll gleich sein. Wir haben schon gesehen, dass ein catch(Exception e) keine gute Lösung ist und nie im Programmcode vorkommen sollte, denn dann würden auch andere Ausnahmen mitgefangen. Zum Glück gibt es in Java 7 eine elegante Lösung.
43
1
Neues in Java 7
Multi-catch Java 7 führt eine neue Schreibweise für catch-Anweisungen ein, um mehrere Ausnahmen auf einmal aufzufangen; sie heißt multi-catch. In der abgewandelten Variante von catch steht dann nicht mehr nur eine Ausnahme, sondern eine Sammlung von Ausnahmen, die ein »|« trennt. Der Schrägstrich ist schon als Oder-Operator bekannt und wurde daher auch hier eingesetzt, denn die Ausnahmen sind ja auch als eine Oder-Verknüpfung zu verstehen. Die allgemeine Syntax ist: try { ... } catch ( E1 | E2 | ... | En exception )
Die Variable exception ist implizit final. Um das multi-catch zu demonstrieren, nehmen wir ein Programm an, das eine Farbtabelle einliest. Die Datei besteht aus mehreren Zeilen, wobei in jeder Zeile die erste Zahl einen Index repräsentiert und die zweite Zahl den hexadezimalen RGB-Farbwert. Listing 1.1: basiscolors.txt 0 000000 1 ff0000 8 00ff00 9 ffff00
Eine eigene Methode readColorTable() soll die Datei einlesen und ein int-Feld der Größe 256 als Rückgabe liefern, wobei an den in der Datei angegebeen Positionen jeweils die Farbwerte eingetragen sind. Nicht belegte Positionen bleiben 0. Gibt es einen Ladefehler, soll die Rückgabe null sein und die Methode eine Meldung auf dem Fehlerausgabekanal ausgeben. Das Einlesen soll die Scanner-Klasse übernehmen. Bei der Verarbeitung der Daten und der Füllung des Feldes sind diverse Fehler denkbar: Þ IOException: Die Datei ist nicht vorhanden, oder während des Einlesens kommt es zu Pro-
blemen. Þ InputMismatchException: Der Index oder die Hexadezimalzahl sind keine Zahlen (einmal zur
Basis 10, und dann zur Basis 16). Den Fehlertyp löst der Scanner aus. Þ ArrayIndexOutOfBoundsException: Der Index liegt nicht im Bereich von 0 bis 255.
Während der erste Fehler beim Dateisystem zu suchen ist, sind die zwei unteren Fehler – unabhängig davon, dass sie ungeprüfte Ausnahmen sind – auf ein fehlerhaftes Format zurück-
44
1.1
Sprachänderungen
zuführen. Die Behandlung soll immer gleich aussehen und kann daher gut in einem multicatch zusammengefasst werden. Daraus folgt: Listing 1.2: ReadColorTable.java import java.io.*; import java.util.Scanner; public class ReadColorTable { private static int[] readColorTable( String filename ) { Scanner input; int[] colors = new int[ 256 ]; try { input = new Scanner( new File(filename) ); while ( input.hasNextLine() ) { int index = input.nextInt(); int rgb
= input.nextInt( 16 );
colors[ index ] = rgb; } return colors; } catch ( IOException e ) { System.err.printf( "Dateioperationen fehlgeschlagen%n%s%n", e ); } catch ( InputMismatchException | ArrayIndexOutOfBoundsException e ) { System.err.printf( "Datenformat falsch%n%s%n", e ); } finally { input.close(); } return null; }
45
1
1
Neues in Java 7
public static void main( String[] args ) { readColorTable( "basiscolors.txt" ); } }
Multi-catch-Blöcke sind also eine Abkürzung, und der Bytecode sieht genauso aus wie mehrere gesetzte catch-Blöcke, also wie: catch ( InputMismatchException e ) { System.err.printf( "Datenformat falsch%n%s%n", e ); } catch ( ArrayIndexOutOfBoundsException e ) { System.err.printf( "Datenformat falsch%n%s%n", e ); }
Multi-catch-Blöcke sind nur eine Abkürzung, daher teilen sie auch die Eigenschaften der normalen catch-Blöcke. Der Compiler führt die gleichen Prüfungen wie bisher durch, also ob etwa die genannten Ausnahmen im try-Block überhaupt ausgelöst werden können. Nur das, was in der durch »|« getrennten Liste aufgezählt ist, wird behandelt; unser Programm fängt zum Beispiel nicht generisch alle RuntimeExceptions ab. Und genauso dürfen die in catch oder multicatch genannten Ausnahmen nicht in einem anderen (multi)-catch auftauchen. Neben den Standard-Tests kommen neue Überprüfungen hinzu, ob etwa die exakt gleiche Exception zweimal in der Liste ist oder ob es Widersprüche durch Mengenbeziehungen gibt.
Hinweis Der folgende multi-catch ist falsch: try { new RandomAccessFile("", ""); } catch ( FileNotFoundException | IOException | Exception e ) { }
Der javac-Compiler meldet einen Fehler der Art »Alternatives in a multi-catch statement cannot be related by subclassing« und bricht ab.
46
1.1
Sprachänderungen
1
Hinweis (Forts.) Mengenprüfungen führt der Compiler auch ohne multi-catch durch, und Folgendes ist ebenfalls falsch: try { new RandomAccessFile("", ""); } catch ( Exception e ) { } catch ( IOException e ) { } catch ( FileNotFoundException e ) { }
Während allerdings eine Umsortierung der Zeilen die Fehler korrigiert, spielt die Reihenfolge bei multi-catch keine Rolle.
1.1.5 Präzisiertes rethrows Die Notwendigkeit, Ausnahmen über einen Basistyp zu fangen, ist mit dem Einzug vom multi-catch gesunken. Doch für gewisse Programmteile ist es immer noch praktisch, alle Fehler eines gewissen Typs aufzufangen. Wir können auch so weit in der Ausnahmehierarchie nach oben laufen, um alle Fehler aufzufangen – dann haben wir es mit einem try { ... } catch(Throwable t){ ... } zu tun. Ein multi-catch ist für geprüfte Ausnahmen besonders gut, aber bei ungeprüften Ausnahmen ist eben nicht immer klar, was als Fehler denn so ausgelöst wird, und ein catch(Throwable t) hat den Vorteil, dass es alles wegfischt.
Problemstellung Werden Ausnahmen über einen Basistyp gefangen und wird diese Ausnahme mit throw weitergeleitet, dann ist es naheliegend, dass der aufgefangene Typ genau der Typ ist, der auch bei throws in der Methodensignatur stehen muss. Stellen wir uns vor, ein Programmblock nimmt einen Screenshot und speichert ihn in einer Datei. Kommt es beim Abspeichern zu einem Fehler, soll das, was vielleicht schon in die Datei geschrieben wurde, gelöscht werden; die Regel ist also: Entweder steht der Screenshot komplett in der Datei oder es gibt gar keine Datei. Die Methode kann so aussehen, wobei die Ausnahmen an den Aufrufer weitergegeben werden sollen: public static void saveScreenshot( String filename ) throws AWTException, IOException { try { Rectangle r = new Rectangle( Toolkit.getDefaultToolkit().getScreenSize() );
47
1
Neues in Java 7
BufferedImage screenshot = new Robot().createScreenCapture( r ); ImageIO.write( screenshot, "png", new File( filename ) ); } catch ( AWTException e ) { throw e; } catch ( IOException e ) { new File( filename ).delete(); throw e; } }
Mit den beiden catch-Blöcken sind wir genau auf die Ausnahmen eingegangen, die createScreenCapture() und write() auslösen. Das ist richtig, aber löschen wir wirklich immer die Dateireste, wenn es Probleme beim Schreiben gibt? Richtig ist, dass wir immer dann die Datei löschen, wenn es zu einer IOException kommt. Aber was passiert, wenn die Implementierung eine RuntimeException auslöst? Dann wird die Datei nicht gelöscht, aber das ist gefragt! Das scheint einfach gefixt, denn statt catch ( IOException e ) { new File( filename ).delete(); throw e; }
schreiben wir: catch ( Throwable e ) { new File( filename ).delete(); throw e; }
Doch können wir das Problem so lösen? Der Typ Throwable passt doch gar nicht mehr mit dem deklarierten Typ IOException in der Methodensignatur zusammen: public static void saveScreenshot( String filename ) throws AWTException /*1*/, IOException /*2*/ {
48
1.1
Sprachänderungen
...
1
catch ( AWTException /*1*/ e ) { throw e; } catch ( Throwable /*?*/ e ) { new File( filename ).delete(); throw e; } }
Die erste catch-Klausel fängt AWTException und leitet es weiter. Damit wird saveScreenshot() zum möglichen Auslöser von AWTException und die Ausnahme muss mit throws an die Signatur. Wenn nun ein catch-Block jedes Throwable auffängt und diesen Throwable-Fehler weiterleitet, ist zu erwarten, dass an der Signatur auch Throwable stehen muss und IOException nicht reicht. Das war auch bis Java 6 so, aber in Java 7 kam eine Anpassung.
Neu seit Java 7: eine präzisere Typprüfung In Java 7 hat der Compiler eine kleine Veränderung erfahren, von einer unpräziseren zu einer präziseren Typanalyse: Immer dann, wenn in einem catch-Block ein throw stattfindet, ermittelt der Compiler die im try-Block tatsächlich aufgetretenen geprüften Exception-Typen und schenkt dem im catch genannten Typ für das rethrow im Prinzip keine Beachtung. Statt dem gefangenen Typ wird der Compiler den durch die Codeanalyse gefundenen Typ beim rethrow melden. Der Compiler erlaubt nur dann das präzise rethrow, wenn die catch-Variable nicht verändert wird. Zwar ist eine Veränderung einer nicht-finalen catch-Variablen wie auch unter Java 1.0 erlaubt, doch wenn die Variable belegt wird, schaltet der Compiler von der präzisen in die unpräzise Erkennung zurück. Führen wir etwa die folgende Zuweisung ein, so funktioniert das Ganze schon nicht mehr: catch ( Throwable e ) { new File( filename ).delete(); e = new IllegalStateException(); throw e; }
49
1
Neues in Java 7
Die Zuweisung führt zu dem Compilerhinweis, dass jetzt auch Throwable mit in die throwsKlausel muss. 2
Stilfrage Die catch-Variable kann für die präzisere Typprüfung den Modifizierer final tragen, muss das aber nicht tun. Immer dann, wenn es keine Veränderung an der Variablen gibt, wird der Compiler sie als final betrachten und eine präzisere Typprüfung durchführen – daher nennt sich das auch effektiv final. Die Java Language Specification rät vom final-Modifizierer aus Stilgründen ab. Ab Java 7 ist es das Standardverhalten, und daher ist es Quatsch, überall ein final dazuzuschreiben, um die präzisere Typprüfung zu dokumentieren.
Migrationsdetail Da der Compiler nun mehr Typwissen hat, stellt sich die Frage, ob alter Programmode mit dem neuen präziseren Verhalten vielleicht ungültig werden könnte. Theoretisch ist das möglich, aber die Sprachdesigner haben in über 9 Millionen Zeilen Code2 von unterschiedlichen Projekten keine Probleme gefunden. Prinzipiell könnte der Compiler jetzt unerreichbaren Code finden, der vorher versteckt blieb. Ein kleines Beispiel, was vor Java 7 compiliert, aber ab Java 7 nicht mehr: try { throw new FileNotFoundException(); } catch ( IOException e ) { try { throw e;
// e ist für den Compiler vom Typ FileNotFoundException
} catch ( MalformedURLException f ) { } }
Die Variable e in catch (IOException e) ist effektiv final, und der Compiler führt die präzisere Typerkennung durch. Er findet heraus, dass der wahre rethrow-Typ nicht IOException, sondern FileNotFoundException ist. Wenn dieser Typ dann mit throw e weitergeleitet wird, kann ihn catch(MalformedURLException) nicht auffangen.
2
50
Die Zahl stammt aus der FOSDEM 2011-Präsentation »Project Coin: Language Evolution in the Open«.
1.1
Sprachänderungen
1
Migrationsdetail (Forts.) Unter Java 6 war das etwas anders, denn hier wusste der Compiler nur, dass e irgendeine IOException ist, und es hätte ja durchaus die IOException-Unterklasse MalformedURLException sein können. (Warum MalformedURLException aber eine Unterklasse von IOException ist, steht auf einem ganz anderen Blatt.)
1.1.6 Automatisches Ressourcen-Management (try mit Ressourcen) Java hat eine automatische Garbage-Collection (GC), sodass nicht mehr referenzierte Objekte erkannt und ihr Speicher automatisch freigegeben wird. Nun bezieht sich die GC aber ausschließlich auf Speicher, doch es gibt viele weitere Ressourcen: Þ Dateisystem-Ressourcen von Dateien Þ Netzwerkressourcen wie Socket-Verbindungen Þ Datenbankverbindungen Þ nativ gebundene Ressourcen vom Grafiksubsystem Þ Synchronisationsobjekte
Auch hier gilt es, nach getaner Arbeit aufzuräumen und Ressourcen freizugeben, etwa Dateien und Datenbankverbindungen zu schließen. Mit dem try-catch-finally-Konstrukt haben wir gesehen, wie Ressourcen freizugeben sind. Doch es lässt sich auch ablesen, dass relativ viel Quellcode geschrieben werden muss und der try-catch-finally drei Unfeinheiten hat: 1. Sollte eine Variable in finally zugänglich sein, muss sie außerhalb des try-Blocks deklariert werden, was ihr eine höhere Sichtbarkeit als nötig gibt. 2. Das Schließen der Ressourcen bringt oft ein zusätzliches try-catch mit sich. 3. Eine im finally ausgelöste Ausnahme (etwa beim close()) überdeckt die im try-Block ausgelöste Ausnahme.
1.1.7 try mit Ressourcen Um das Schließen von Ressourcen zu vereinfachen, wurde in Java 7 eine besondere Form der try-Anweisung eingeführt, die try mit Ressourcen genannt werden. Mit ihm lassen sich Ressource-Typen, die die Schnittstelle java.lang.AutoCloseable implementieren, automatisch schließen. Ein-/Ausgabeklassen wie Scanner, InputStream und Writer, implementieren diese Schnittstelle und können direkt verwendet werden. Weil try mit Ressourcen dem Automatic Resource Management dient, heißt der spezielle try-Block auch ARM-Block.
51
1
Neues in Java 7
Gehen wir in die Praxis: Aus einer Datei soll mit einem Scanner die erste Zeile gelesen und ausgegeben werden. Nach dem Lesen soll der Scanner geschlossen werden. Die linke Seite der folgenden Tabelle nutzt die spezielle Syntax, die rechte Seite ist im Prinzip die Übersetzung, allerdings noch etwas vereinfacht, wie wir später genauer sehen werden. try mit Ressourcen
Vereinfachte ausgeschriebene Implementierung
InputStream in =
InputStream in =
ClassLoader.getSystemResourceAsStream(
ClassLoader.getSystemResourceAsStream( "EastOfJava.txt" );
"EastOfJava.txt" ); try ( Scanner res =
{ final Scanner res =
new Scanner( in ) )
new Scanner( file );
{ try
System.out.println(
{
res.nextLine() );
System.out.println(
}
res.nextLine() ); } finally { res.close(); } } Tabelle 1.2: Die main()-Methode von TryWithResources1 und ihre prinzipielle Umsetzung
Üblicherweise folgt nach dem Schlüsselwort try ein Block, doch try-mit-Ressourcen nutzt eine eigene spezielle Syntax. 1. Nach dem try folgt statt dem direkten {}-Block eine Anweisung in runden Klammern, und dann erst der {}-Block, also try (...) {...} statt try {...}. 2. In den runden Klammern findet man eine lokale Variablendeklaration (die Variable ist automatisch final) mit einer Zuweisung. Die Ressourcenvariable muss vom Typ AutoCloseable sein. Rechts vom Gleichheitszeichen steht ein Ausdruck, etwa ein Konstruktor- oder Methodenaufruf. Der Typ des Ausdrucks muss natürlich auch intanceof AutoCloseable sein. Die in dem try deklarierte lokale AutoCloseable-Variable ist nur in dem Block gültig und wird automatisch freigegeben, gleichgültig ob der ARM-Block korrekt durchlaufen wurde oder ob es bei der Abarbeitung zu einem Fehler kam. Der Compiler fügt alle nötigen Prüfungen ein.
52
1.1
Sprachänderungen
1.1.8 Ausnahmen vom close() bleiben bestehen
1
Unser Scanner-Beispiel hat eine Besonderheit, denn keine der Methoden löst eine geprüfte Ausnahme aus – weder getSystemResourceAsStream(), new Scanner(InputStream), nextLine() noch das close(), was try-mit-Ressourcen automatisch aufruft. Anders ist es, wenn die Ressource ein InputStream ist, denn dort deklariert die close()-Methode eine IOException. Die muss daher auch behandelt werden, wie es das folgende Beispiel zeigt: Listing 1.3: TryWithResourcesReadsLine, readFirstLine() static String readFirstLine( File file ) { try ( BufferedReader br = new BufferedReader(new FileReader(file) ) ) { return br.readLine(); } catch ( IOException e ) { e.printStackTrace(); return null; } }
Wenn try-mit-Ressourcen verwendet wird, bleibt die Ausnahme bestehen; es zaubert die Ausnahmen beim catch also nicht weg.
Hinweis Löst close() eine geprüfte Ausnahme aus, und wird diese nicht behandelt, so kommt es zum Compilerfehler. Die close()-Methode vom BufferedReader löst zum Beispiel eine IOException aus, sodass sich die folgende Methode nicht übersetzen lässt: void no() { try ( Reader r = new BufferedReader(null) ) { }
// Compilerfehler
}
Der Ausdruck new BufferedReader(null) benötigt keine Behandlung, denn der Konstruktor löst keine Ausnahme aus. Einzig der nicht behandelte Fehler von close() führt zu »exception thrown from implicit call to close() on resource variable 'r'«.
1.1.9 Die Schnittstelle AutoCloseable Die ARM-Anweisung schließt Ressourcen vom Typ AutoCloseable. Daher wird es Zeit, sich diese Schnittstelle etwas genauer anzuschauen:
53
1
Neues in Java 7
package java.lang; public interface AutoCloseable { void close() throws Exception; }
Anders als das übliche close() ist die Ausnahme deutlich allgemeiner mit Exception angegeben; die Ein-/Ausgabe-Klassen lösen beim Misslingen immer eine IOException aus, aber jede Klasse hat eigene Ausnahmetypen: Typ
Signatur
java.io.Scanner
close() // ohne Ausnahme
javax.sound.sampled.Line
close() // ohne Ausnahme
java.io.FileInputStream
close() throws IOException
java.sql.Connection
close() throws SQLException
Tabelle 1.3: Einige Typen, die AutoCloseable implementieren
Eine Unterklasse darf die Ausnahme ja auch weglassen, das machen Klassen wie der Scanner, der keine Ausnahme weiterleitet, sondern sie intern schluckt – wenn es Ausnahmen gab, liefert sie die Scanner-Methode ioException().
AutoCloseable und Closeable Auf den ersten Blick einleuchtend wäre es, die schon existierende Schnittstelle Closeable als Typ zu nutzen. Doch das hätte Nachteile: Die close()-Methode ist mit einem throws IOException deklariert, was bei einer allgemeinen automatischen Ressourcen-Freigabe unpassend ist, wenn etwa ein Grafikobjekt bei der Freigabe eine IOException auslöst. Vielmehr ist der Weg anders herum: Closeable erweitert AutoCloseable, denn das Schließen von Ein-/Ausgabe-Ressourcen ist eine besondere Art, allgemeine Ressourcen zu schließen. package java.io; import java.io.IOException; public interface Closeable extends AutoCloseable { void close() throws IOException; }
54
1.1
Sprachänderungen
Wer ist AutoCloseable?
1
Da alle Klassen, die Closeable implementieren, auch automatisch vom Typ AutoCloseable sind, kommen schon einige Typen zusammen. Im Wesentlichen sind es aber Klassen aus dem java.io-Paket, wie Channel-, Reader-, Writer-Implementierungen, FileLock, XMLDecoder und noch ein paar Exoten wie URLClassLoader, ImageOutputStream. Auch Typen aus dem java.sql-Paket gehören zu den Nutznießern. Klassen aus dem Bereich Threading, wo etwa ein Lock wieder freigeben werden könnte, oder Grafik-Anwendungen, bei denen der Grafik-Kontext wieder freigegeben werden muss, gehören nicht dazu.
1.1.10
Mehrere Ressourcen nutzen
Unsere beiden Beispiele zeigten die Nutzung eines Ressource-Typs. Es sind aber auch mehrere Typen möglich, die dann mit einem Semikolon getrennt werden: try ( InputStream in = new FileInputStream(src); OutputStream out = new FileOutputStream(dest) ) { ... }
Hinweis Die Trennung erledigt ein Semikolon, und jedes Segment kann einen unterschiedlichen Typ deklarieren, etwa InputStream/OutputStream. Die Ressourcen-Typen müssen also nicht gleich sein, und auch wenn sie es sind, muss der Typ immer neu geschrieben werden, also etwa: try ( InputStream in1 = ...; InputStream in2 = ... )
Es ist ungültig, Folgendes zu schreiben: try ( InputStream in1 = ..., in2 = ... )
// Compilerfehler
Wenn es beim Anlegen in der Kette zu einem Fehler kommt, wird nur das geschlossen, was auch aufgemacht wurde. Wenn es also bei der ersten Initialisierung von in1 schon zu einer Ausnahme kommt, wird die Belegung von in2 erst gar nicht begonnen und daher auch nicht geschlossen. (Intern setzt der Compiler das als geschachtelte try-catch-finally-Blöcke um.)
Beispiel Am Schluss der Ressourcensammlung kann – muss aber nicht – ein Semikolon stehen, so wie auch bei Feldinitialisierungen zum Schluss ein Komma stehen kann: int[] array = { 1, 2, }; //
^ Komma optional
55
1
Neues in Java 7
Beispiel (Forts.) try ( InputStream in = new FileInputStream(src); ) { ... } //
^ Semikolon optional
try ( InputStream in = new FileInputStream(src); OutputStream out = new FileOutputStream(dest); ) { ... } //
^ Semikolon optional
Ob das stilvoll ist, muss jeder selbst entscheiden; in der Insel steht kein unnützes Zeichen.
1.1.11
Unterdrückte Ausnahmen *
Aufmerksame Leser haben bestimmt schon ein Detail wahrgenommen: Im Text steht »vereinfachte ausgeschriebene Implementierung«, was vermuten lässt, dass es ganz so einfach doch nicht ist. Das stimmt, denn es können zwei Ausnahmen auftauchen, die einiges an Sonderbehandlung benötigen: Þ Ausnahme im try-Block. An sich unproblematisch. Þ Ausnahme beim close(). Auch an sich unproblematisch. Aber es gibt mehrere close()-Auf-
rufe, wenn nicht nur eine Ressource verwendet wurde. Ungünstig. Þ Die Steigerung: Ausnahme im try-Block und dann auch noch Ausnahme(n) beim close().
Das ist ein echtes Problem! Eine Ausnahme alleine ist kein Problem, aber zwei Ausnahmen auf einmal bilden ein großes Problem, da ein Programmblock nur genau eine Ausnahme melden kann und nicht eine Sequenz von Ausnahmen. Daher sind verschiedene Fragen zu klären, falls der try-Block und close() beide eine Ausnahme auslösen: Þ Welche Ausnahme ist wichtiger? Die Ausnahme im try-Block oder die vom close()? Þ Wenn es zu zwei Ausnahmen kommt: Soll die von close() vielleicht immer verdeckt wer-
den und immer nur die vom try-Block zum Anwender kommen? Þ Wenn beide Ausnahmen wichtig sind, wie sollen sie gemeldet werden?
Wie haben sich die Java-Ingenieure entschieden? Eine Ausnahme bei close() darf bei einem gleichzeitigen Auftreten einer Exception im try-Block auf keinen Fall verschwinden.3 Wie also beide Ausnahmen melden? Hier gibt es einen Trick: Da die Ausnahme im try-Block wichtiger ist, ist sie die »Haupt-Ausnahme«, und die close()-Ausnahme kommt Huckepack als ExtraInformation mit oben drauf.
3
56
In einem frühen Prototyp war dies tatsächlich der Fall – die Ausnahme wurde komplett geschluckt.
1.1
Sprachänderungen
Dieses Verhalten soll das nächste Beispiel zeigen. Um die Ausnahmen besser steuern zu können, soll eine eigene AutoCloseable-Implementierung eine Ausnahme in close() auslösen. Listing 1.4: SuppressedClosed.java public class SuppressedClosed { public static void main( String[] args ) { class NotCloseable implements AutoCloseable { @Override public void close() { throw new UnsupportedOperationException( "close() mag ich nicht" ); } } try ( NotCloseable res = new NotCloseable() ) { throw new NullPointerException(); } } }
Das Programm löst also im close() und im try-Block eine Ausnahme aus. Das Resultat ist: Exception in thread "main" java.lang.NullPointerException at SuppressedClosed.main(SuppressedClosed.java:14) Suppressed: java.lang.UnsupportedOperationException: close() mag ich nicht at SuppressedClosed$1NotCloseable.close(SuppressedClosed.java:9) at SuppressedClosed.main(SuppressedClosed.java:15)
Die interessante Zeile beginnt mit »Suppressed:«, denn dort ist die close()-Ausnahme referenziert. An den Aufrufer kommt die spannende Ausnahme vom misslungenen try-Block aber nicht direkt von close(), sondern verpackt in der Hauptausnahme und muss extra erfragt werden. Zum Vergleich: Kommentieren wir throw new NullPointerException() aus, gibt es nur noch die close()-Ausnahme und es folgt auf der Konsole:
57
1
1
Neues in Java 7
Exception in thread "main" java.lang.UnsupportedOperationException: close() mag ich nicht at SuppressedClosed$1NotCloseable.close(SuppressedClosed.java:9) at SuppressedClosed.main(SuppressedClosed.java:15)
Die Ausnahme ist also nicht irgendwo anders untergebracht, sondern die »Hauptausnahme«. Eine Steigerung ist, dass es mehr als eine Ausnahme beim Schließen geben kann. Simulieren wir auch dies wieder an einem Beispiel, indem wir unser Beispiel um eine Zeile ergänzen: try ( NotCloseable res1 = new NotCloseable(); NotCloseable res2 = new NotCloseable() ) { throw new NullPointerException(); }
Aufgerufen führt dies zu: Exception in thread "main" java.lang.NullPointerException at SuppressedClosed.main(SuppressedClosed.java:15) Suppressed: java.lang.UnsupportedOperationException: close() mag ich nicht at SuppressedClosed$1NotCloseable.close(SuppressedClosed.java:9) at SuppressedClosed.main(SuppressedClosed.java:16) Suppressed: java.lang.UnsupportedOperationException: close() mag ich nicht at SuppressedClosed$1NotCloseable.close(SuppressedClosed.java:9) at SuppressedClosed.main(SuppressedClosed.java:16)
Jede unterdrückte close()-Ausnahme taucht auf.
Umsetzung Im Kapitel über finally wurde das Verhalten vorgestellt, dass eine Ausnahme im finally eine Ausnahme im try-Block unterdrückt. Der Compiler setzt bei der Umsetzung vom try-mit-Ressourcen das close() in einen finally-Block. Ausnahmen im finally-Block sollen eine mögliche Hauptausnahme aber nicht schlucken. Daher fängt die Umsetzung vom Compiler jede mögliche Ausnahme im try-Block ab sowie die close()-Ausnahme und hängt diese SchließAusnahme, falls vorhanden, an die Hauptausnahme.
Spezielle Methoden in Throwable * Damit eine normale Exception die unterdrückten close()-Ausnahmen Huckepack nehmen kann, sind in der Basisklasse Throwable seit Java 7 zwei Methoden hinzugekommen:
58
1.2
JVM-Änderungen
final class java.lang.Throwable
1
Þ final Throwable[] getSuppressed()
Liefert alle unterdrückten Ausnahmen. Die printStackTrace()-Methode zeigt alle unterdrückten Ausnahmen und greift auf getSuppressed() zurück. Für Anwender wird es selten Anwendungsfälle für diese Methode geben. Þ final void addSuppressed(Throwable exception)
Fügt eine neue unterdrückte Ausnahme hinzu. In der Regel ruft der finally-Block vom trymit-Ressourcen die Methode auf, doch wir können auch selbst die Methode nutzen, wenn wir mehr als eine Ausnahme melden wollen. Die Java-Bibliothek selbst nutzt das bisher nur an sehr wenigen Stellen. Neben den beiden Methoden gibt es einen protected-Konstruktor, der bestimmt, ob es überhaupt unterdrückte Ausnahmen geben soll oder ob sie nicht vielleicht komplett geschluckt werden. Wenn, dann zeigt sie auch printStackTrace() nicht mehr an.
Blick über den Tellerrand In C++ gibt es Dekonstruktoren, die beliebige Anweisungen ausführen, wenn ein Objekt freigegeben wird. Hier lässt sich auch das Schließen von Ressourcen realisieren. C# nutzt statt try das spezielle Schlüsselwort using, mit Typen, die die Schnittstelle IDisposable implementieren, mit einer Methode Dispose() statt close(). (In Java sollte die Schnittstelle ursprünglich auch Disposable statt nun AutoCloseable heißen.) In Python 2.5 wurde ein context management protocol mit dem Schlüsselwort with realisiert, sodass Python automatisch bei Betreten eines Blockes __enter__() aufruft und beim Verlassen die Methode __exit__(). Das ist insofern interessant, als dass hier zwei Methoden zur Verfügung stehen. Bei Java ist es nur close() beim Verlassen des Blockes, aber es gibt keine Methode zum Betreten eines Blockes; so etwas muss beim Anlegen der Ressource erledigt werden.
1.2 JVM-Änderungen Wenn es um Java geht, müssen wir immer unterscheiden, ob es um die Sprache selbst geht, um die Bibliotheken, um die JVM oder um die Implementierung von Oracle, die das JDK darstellt. Eine wichtige Änderung am Bytecode, und damit an der JVM selbst, ist ein neuer Bytecode zum Beschleunigen von Methoden, deren Signatur nicht bekannt ist.
59
1
Neues in Java 7
In der Implementierung von Oracle gibt es zwei große Änderungen an der JVM selbst: Þ einen neuen Garbage-Collector G1 (für Garbage Frist) Þ komprimierte 64-Bit-Objekt-Pointer, sodass sie in 32 Bit Platz finden.
Bei Java-Programmen mit DTrace (wie Solaris) lassen sich die Zustände erfragen und die Abarbeitung überwachen.
1.2.1 invokedynamic Seit Java vor über 10 Jahren auf dem Markt erschien, hat sich vieles geändert (und auch vieles ist gleich geblieben). Auffällig ist eine starke Zunahme von Skriptsprachen – spielten sie vor 10 Jahren kaum eine Rolle, sind sie heute unübersehbar. Möglicherweise ist ein Grund dafür, dass vor 10–20 Jahren compilierte Sprache einfach nicht die nötige Performance brachten, aber heute auch durch leistungsfähige Maschinen und intelligente Ausführung die Leistung einfach da ist.
Skriptsprachen auf der JVM Eine unübersehbare Tatsache ist, dass viele Skriptsprachen heute in einer virtuellen Maschine laufen. Besondere Rolle nehmen die Java-Plattform (mit der JVM) und die .NET-Plattform mit CLR (einer virtuellen Maschine für .NET) ein. Zwei Trends zeigen sich: Zum einen werden existierende Skriptsprachen auf die JVM/CLR übertragen und zum anderen Sprachen explizit für die virtuellen Maschinen entworfen. Skriptsprache
Für JVM
Für CLR
Python
Jython
IronPython
Ruby
JRuby
IronRuby
Lua
Jill, Kahlua
LuaCLR
JavaScript
Rhino
IronJS
PHP
Quercus
Tcl
Jacl Groovy JavaFX Boo
Tabelle 1.4: Skriptsprachen auf der JVM (Java) und CLR (.NET)
60
1.2
JVM-Änderungen
Umsetzung der Skriptsprachen auf der JVM
1
Eine Skriptsprache, die explizit für eine VM entworfen wurde, berücksichtigt natürlich Einschränkungen. Existierende Programmiersprachen sind eine ganz andere Herausforderung, da sie Sprach- und Laufzeitkonstrukte bieten können, die auf der JVM vielleicht nicht unterstützt werden. Das ist ein Problem, und drei Strategien zur Lösung bieten sich an: Þ Ignorieren der Eigenschaften: Python ermöglicht Mehrfachvererbung, Java nicht. Daher
kann das Verhalten von Python unter Java nicht perfekt nachgebildet werden, obwohl Jython sein Bestes gibt. Weiterhin kann Python Interrupts auffangen, aber so etwas gibt es unter Java nicht, also auch nicht in Jython. (Das ist aber eher eine Bibliotheks- und weniger eine Spracheigenschaft.) Þ Nachbilden der Eigenschaften: In Sprachen wie JavaScript, Python oder Ruby gibt es das so-
genannte Duck Typing. Zur Laufzeit wird erst das Vorhandensein von Methoden geprüft, und die Typen müssen nicht im Quellcode stehen. In JavaScript ist zum Beispiel function add(x, y){return x + y;} oder function isEmpty(s){return s == null || s.length() == 0;} erlaubt, und erst später beim Aufruf stellt sich heraus, was x und y überhaupt ist und ob ein Plus-Operator/length()-Methode definiert ist. Deklarationen und Aufrufe dieser Art sind nur mit vielen Tricks auf der JVM umzusetzen. Þ Ändern der JVM zur Unterstützung der Eigenschaften: Die Spracheigenschaften zu ignorie-
ren ist natürlich keine schöne Sache. Glücklicherweise kommt das selten vor, denn die JVM macht vieles mit. Ruby erlaubt etwa Methodennamen wie ==, , +, und 1.+2 ist gültig. Die Bezeichner sind in Java zwar nicht möglich, aber die JVM hat grundsätzlich mit den Bezeichnen keine Probleme. Es ist interessant zu sehen, wie unterschiedlich Java als Sprache und die JVM sind, denn vieles in Java gibt es in der JVM gar nicht. Enums zum Beispiel sind nur einfache Klassen. Oder dass eine Klasse ohne einen vom Entwickler explizit geschriebenen Konstruktor automatisch einen Standardkonstruktor bekommt, ist nur etwas, was der Compiler generiert. Oder ein super() als ersten Aufruf im Konstruktor – alles das sind Compilereigenschaften, und von Generics ganz zu schweigen. Wenn die Besonderheiten einer Skriptsprache über Tricks und intelligentes Übersetzen in Bytecode realisiert werden können, stellt sich die Frage, ob an der JVM überhaupt Änderungen nötig sind. Wie bei vielen Diskussionen kommt dann ein Argument auf, das Änderungen oft rechtfertigt: Performance. Wenn eine Änderung in der JVM die Abarbeitung bestimmter Konstrukte massiv beschleunigt, ist das ein Grund für die Änderung. Und somit sind wir beim neuen Bytecode invokedynamic angelangt.
Umsetzung von Duck Typing Reine Java-Programme werden den Bytecode invokedynamic nie benötigen, er ist einzig und allein in die JVM eingeführt worden, um Methodenaufrufe der Skriptsprachen auf der JVM zu
61
1
Neues in Java 7
beschleunigen. Die bisherigen Bytecodes von Methodenaufrufen trugen alle nötigen Typinformationen, so wie es bei Java üblich ist. Nehmen wir: System.out.prinln( 1 );
Der Compiler macht aus dem Programm ein invokevirtual, wobei genau bei dem Aufruf steht, dass ein println() gemeint ist, was ein int annimmt. Die Typinformationen im Bytecode sind: Þ Der Empfänger ist PrintStream, und seine Methode ist println. Þ Der Parametertyp ist ein int. Þ Die »Rückgabe« ist void.
Exakt diese Typen müssen vom Compiler in Bytecode gegossen werden, sonst kann die JVM den Aufruf nicht durchführen. Skriptsprachen hingegen sind da lascher. Nehmen wir noch einmal unser Beispiel aus JavaScript: function isEmpty(s) { return s == null || s.length() == 0; }
Die Typen wären zwar zur Laufzeit bekannt, aber eben nicht zur Compilezeit, in der der Bytecode erstellt würde. Ein Aufruf der Methode wird schwierig, denn es fehlen ganz offensichtlich der Rückgabe- und der Parametertyp. Natürlich könnten sie über einen Trick zu Object ergänzt werden. Spielen wir kurz die Konsequenzen durch: Object isEmpty( Object s )
Das sieht gut aus. Aber jetzt wird es haarig bei length(), das keine Methode von Object ist. Das Problem kann ein Compiler auf zwei Arten lösen. Zunächst kann der Aufruf an das unbekannte Objekt, das ja zur Laufzeit üblicherweise etwas anderes als String ist, über Reflection gelöst werden. Da Reflection-Aufrufe aber nicht so performant sind wie richtige Methodenaufrufe, ist diese Lösung nicht so effizient. Eine zweite Lösung besteht in der Einführung einer Schnittstelle, die genau die fehlenden Operationen deklariert: interface I { int length(); } I isEmpty( I s ) { return s == null || s.length() == 0; }
Ja, das geht – irgendwie. Das ist performanter als Reflection, aber auf diese Weise kommen eine riesige Anzahl neuer Schnittstellen bzw. Klassen in die JVM, deren Behandlung recht speicherintensiv ist. Außerdem können die Deklarationen von Methoden in Skriptsprachen auch außerhalb von Klassen vorkommen, sodass für Java ein Fake-Methoden-Empfänger erzeugt werden müsste.
62
1.3
Neue Pakete und Klassen
invokedynamic und Hilfsklassen
1
Um die sonderbare Methodendeklaration in Java performant umzusetzen, hat der JSR-292, »Supporting Dynamically Typed Languages on the Java Platform«, den neuen Bytecode invokedynamic zusammen mit einigen Hilfsklassen im Paket java.lang.invoke definiert. 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. Weitere Details und ein Programmbeispiel finden Leser unter http://java.sun.com/developer/ technicalArticles/DynTypeLang/. Sehr tiefe Detailinformationen liefert http://blogs.oracle. com/jrose/resource/pres/200910-VMIL.pdf.
1.3 Neue Pakete und Klassen Auf einige Neuerungen geht das Buch noch gezielter ein, etwa auf NIO.2 in Kapitel 5, »Dateien, Verzeichnisse und Dateizugriffe«, oder auf die API für nebenläufige Programmierung, das Fork-und-Join-Framework in Kapitel 2, »Threads und nebenläufige Programmierung«. Da die APIs alle bibliotheksbezogen sind und dieses Buch die Java-Bibliothek in den Mittelpunkt rückt, sind die Änderungen zu Java 7 dort vermerkt – mal ist es hier eine Methode, mal da; große Überraschungen gibt es nicht. An Typen im Paket java.lang gibt es ebenfalls kleine Änderungen. Java 7 unterstützt Unicode 6, was bedeutet, dass Java 7 Konstanten für die neuen Zeichenbereiche einführt und Methoden wie isLetter() aktualisiert hat, um auch dieses neue Zeichen korrekt zu berücksichtigen. Die Klasse Character hat für die Unicode-Blöcke Konstanten bekommen. Über den Unicode 6Standard gibt http://unicode.org/versions/Unicode6.0.0/ Auskunft. Für »normale« Entwickler ist das wenig relevant. Für die üblichen Unicode-Kodierungen gibt es in StandardCharsets Konstanten.
1.3.1 Weitere Änderungen Im GIU-Bereich, das heißt bei AWT und Swing, haben sich Kleinigkeiten geändert. Fenster können auch nicht eckig und transparent sein – das ging zwar auch schon seit einer späteren Java 6-Version, aber nur inoffiziell – das heißt, mit keiner Klasse im »erlaubten« Paket. Zwar war ein Datumsauswahldialog für Java 7 in Planung, aber er verschiebt sich wohl noch bis Java 8.
63
1
Neues in Java 7
Neuerungen in Kürze: Þ Alle Wrapper-Klassen bieten eine statische compare()-Methode, die zwei primitive Werte
vergleicht. Die Methode ist eine Alternative zur compareTo()-Methode, die alle WrapperKlassen bieten, die Comparable implementieren. Þ Der ProcessBuilder ist eine Klasse in Java, um externe Prozesse aufzubauen. Neu sind
Methoden, um die Datenströme umzuleiten. Þ Klassenlader lassen sich mit close() wieder schließen. Þ kleine Änderungen an den Kalender-Klassen Þ Unterstützung für SCTP (Stream Control Transmission Protocol) und SDP (Sockets Direct
Protocol). Das Tutorial gibt unter http://download.oracle.com/javase/tutorial/sdp/sockets/ eine Einführung in die sehr spezielle Technologie. Þ neue Klassen für asynchrone Datei- und Socket-Operationen Þ Neu in Java 7 ist JDBC 4.1, was nicht nur auf AutoCloseable eingeht, sondern auch Standard-
Implementierungen für sogenannte Row-Sets mitbringt. Weiterhin können die JDBC-Klassen Pseudo-Spalten nutzen, und bei einer Connection lässt sich das Datenbank-Schema erfragen und setzen.
64
Kapitel 2 2
Threads und nebenläufige Programmierung »Es ist nicht zu wenig Zeit, die wir haben, sondern es ist zu viel Zeit, die wir nicht nutzen.« – Lucius Annaeus Seneca (ca. 4 v. Chr.– 65 n. Chr.), römischer Philosoph und Staatsmann
2.1 Threads erzeugen Die folgenden Abschnitte verdeutlichen, wie der nebenläufige Programmcode in einen Runnable verpackt und dem Thread zur Ausführung vorgelegt wird.
2.1.1 Threads über die Schnittstelle Runnable implementieren Damit der Thread weiß, was er ausführen soll, müssen wir ihm Anweisungsfolgen geben. Diese werden in einem Befehlsobjekt vom Typ Runnable verpackt und dem Thread übergeben. Wird der Thread gestartet, arbeitet er die Programmzeilen aus dem Befehlsobjekt parallel zum restlichen Programmcode ab. Die Schnittstelle Runnable ist schmal und schreibt nur eine run()-Methode vor. interface java.lang.Runnable Þ void run()
Implementierende Klassen realisieren die Operation und setzen dort den parallel auszuführenden Programmcode ein.
Abbildung 2.1: UML-Diagramm der einfachen Schnittstelle Runnable
65
2
Threads und nebenläufige Programmierung
Wir wollen zwei Threads angeben, wobei einer zwanzigmal das aktuelle Datum und die Uhrzeit ausgibt und der andere einfach eine Zahl: Listing 2.1: com/tutego/insel/thread/DateCommand.java package com.tutego.insel.thread; public class DateCommand implements Runnable { @Override public void run() { for ( int i = 0; i < 20; i++ ) System.out.println( new java.util.Date() ); } } Listing 2.2: com/tutego/insel/thread/CounterCommand.java package com.tutego.insel.thread; class CounterCommand implements Runnable { @Override public void run() { for ( int i = 0; i < 20; i++ ) System.out.println( i ); } }
Unser parallel auszuführender Programmcode in run() besteht aus einer Schleife, die in einem Fall ein aktuelles Date-Objekt ausgibt und im anderen Fall einen Schleifenzähler.
2.1.2 Thread mit Runnable starten Nun reicht es nicht aus, einfach die run()-Methode einer Klasse direkt aufzurufen, denn dann wäre nichts nebenläufig, sondern wir würden einfach eine Methode sequenziell ausführen. Damit der Programmcode parallel zur Applikation läuft, müssen wir ein Thread-Objekt mit dem Runnable verbinden und dann den Thread explizit starten. Dazu übergeben wir dem Konstruktor der Klasse Thread eine Referenz auf das Runnable-Objekt und rufen start() auf. Nach-
66
2.1
Threads erzeugen
dem start() für den Thread eine Ablaufumgebung geschaffen hat, ruft es intern selbstständig die Methode run() genau einmal auf. Läuft der Thread schon, so löst ein zweiter Aufruf der start()-Methode eine IllegalThreadStateException aus: Listing 2.3: com/tutego/insel/thread/FirstThread.java, main() Thread t1 = new Thread( new DateCommand() ); t1.start(); Thread t2 = new Thread( new CounterCommand() ); t2.start();
Beim Starten des Programms erfolgt eine Ausgabe auf dem Bildschirm, die in etwa so aussehen kann: Tue Aug 21 16:59:58 CEST 2007 0 1 2 3 4 5 6 7 8 9 Tue Aug 21 16:59:58 CEST 2007 10 ...
Deutlich ist die Verzahnung der beiden Threads zu erkennen. Was allerdings auf den ersten Blick etwas merkwürdig wirkt, ist die erste Zeile des Datum-Threads und viele weitere Zeilen des Zähl-Threads. Dies hat jedoch nichts zu bedeuten und zeigt deutlich den Nichtdeterminismus1 bei Threads. Interpretiert werden kann dies jedoch durch die unterschiedlichen Laufzeiten, die für die Datums- und Zeitausgabe nötig sind.
1
Nicht vorhersehbar, bedeutet hier: Wann der Scheduler den Kontextwechsel vornimmt, ist unbekannt.
67
2
2
Threads und nebenläufige Programmierung
class java.lang.Thread implements Runnable Þ Thread(Runnable target)
Erzeugt einen neuen Thread mit einem Runnable, das den parallel auszuführenden Programmcode vorgibt. Þ void start()
Ein neuer Thread – neben dem die Methode aufrufenden Thread – wird gestartet. Der neue Thread führt die run()-Methode nebenläufig aus. Jeder Thread kann nur einmal gestartet werden.
Hinweis Wenn ein Thread im Konstruktor einer Runnable-Implementierung gestartet wird, sollte die Arbeitsweise bei der Vererbung beachtet werden. Nehmen wir an, eine Klasse leitet von einer anderen Klasse ab, die im Konstruktor einen Thread startet. Bildet die Applikation ein Exemplar der Unterklasse, so werden bei der Bildung des Objekts immer erst die Konstruktoren der Oberklasse aufgerufen. Dies hat zur Folge, dass der Thread schon läuft, auch wenn das Objekt noch nicht ganz gebaut ist. Die Erzeugung ist erst abgeschlossen, wenn nach dem Aufruf der Konstruktoren der Oberklassen der eigene Konstruktor vollständig abgearbeitet wurde.
2.1.3 Die Klasse Thread erweitern Da die Klasse Thread selbst die Schnittstelle Runnable implementiert und die run()-Methode mit leerem Programmcode bereitstellt, können wir auch Thread erweitern, wenn wir eigene parallele Aktivitäten programmieren wollen: Listing 2.4: com/tutego/insel/thread/DateThread.java, DateThread public class DateThread extends Thread { @Override public void run() { for ( int i = 0; i < 20; i++ ) System.out.println( new Date() ); } }
Dann müssen wir kein Runnable-Exemplar mehr in den Konstruktor einfügen, denn wenn unsere Klasse eine Unterklasse von Thread ist, reicht ein Aufruf der geerbten Methode start().
68
2.1
Threads erzeugen
2
Abbildung 2.2: UML-Diagramm der Klasse Thread, die Runnable implementiert
Danach arbeitet das Programm direkt weiter, führt also kurze Zeit später die nächste Anweisung hinter start() aus:
69
2
Threads und nebenläufige Programmierung
Listing 2.5: com/tutego/insel/thread/DateThreadUser, main() Thread t = new DateThread(); t.start(); new DateThread().start();
// (*)
Die (*)-Zeile zeigt, dass das Starten sehr kompakt auch ohne Zwischenspeicherung der Objektreferenz möglich ist. class java.lang.Thread implements Runnable Þ void run()
Diese Methode in Thread hat einen leeren Rumpf. Unterklassen überschreiben run(), sodass sie den parallel auszuführenden Programmcode enthält.
Überschreiben von start() und Selbststarter Die Methode start() kann von uns auch überschrieben werden, was aber nur selten sinnvoll beziehungsweise nötig ist. Wir müssen dann darauf achten, super.start() aufzurufen, damit der Thread wirklich startet. Damit wir als Thread-Benutzer nicht erst die start()-Methode aufrufen müssen, kann ein Thread sich auch selbst starten. Der Konstruktor ruft dazu einfach die eigene start()Methode auf: class DateThread extends Thread { DateThread() { start(); } // ... der Rest bleibt ... }
run( ) wurde statt start( ) aufgerufen: Ja, wo laufen sie denn? Ein Programmierfehler, der Anfängern schnell unterläuft, ist folgender: Statt start() rufen sie aus Versehen run() auf dem Thread auf. Was geschieht? Fast genau das Gleiche wie bei start(), nur mit dem Unterschied, dass die Objektmethode run() nicht parallel zum übrigen Programm abgearbeitet wird. Der aktuelle Thread bearbeitet die run()-Methode sequenziell, bis
70
2.2
Thread-Eigenschaften und -Zustände
sie zu Ende ist und die Anweisungen nach dem Aufruf an die Reihe kommen. Der Fehler fällt nicht immer direkt auf, denn die Aktionen in run() finden ja statt – nur eben nicht nebenläufig.
Erweitern von Thread oder Implementieren von Runnable? Die beste Idee wäre, Runnable-Objekte zu bauen, die dann dem Thread übergeben werden. Befehlsobjekte dieser Art sind recht flexibel, da die einfachen Runnable-Objekte leicht übergeben und sogar von Threads aus einem Thread-Pool ausgeführt werden können. Ein Nachteil der Thread-Erweiterung ist, dass die Einfachvererbung störend sein kann; erbt eine Klasse von Thread, ist die Erweiterung schon »aufgebraucht«. Doch, egal ob eine Klasse Runnable implementiert oder Thread erweitert, eines bleibt: eine neue Klasse.
2.2 Thread-Eigenschaften und -Zustände Ein Thread hat eine ganze Reihe von Zuständen, wie einen Namen und eine Priorität, die sich erfragen und setzen lassen. Nicht jede Eigenschaft ist nach dem Start änderbar, doch welche das sind, zeigen die folgenden Abschnitte.
2.2.1 Der Name eines Threads Ein Thread hat eine ganze Menge Eigenschaften – wie einen Zustand, eine Priorität und auch einen Namen. Dieser kann mit setName() gesetzt und mit getName() erfragt werden. class java.lang.Thread implements Runnable Þ Thread(String name)
Erzeugt ein neues Thread-Objekt und setzt den Namen. Sinnvoll bei Unterklassen, die den Konstruktor über super(name) aufrufen. Þ Thread(Runnable target, String name)
Erzeugt ein neues Thread-Objekt mit einem Runnable und setzt den Namen. Þ final String getName()
Liefert den Namen des Threads. Der Name wird im Konstruktor angegeben oder mit setName() zugewiesen. Standardmäßig ist der Name »Thread-x«, wobei x eine eindeutige Nummer ist. Þ final void setName(String name)
Ändert den Namen des Threads.
71
2
2
Threads und nebenläufige Programmierung
2.2.2 Wer bin ich? Eine Erweiterung der Klasse Thread hat den Vorteil, dass geerbte Methoden wie getName() sofort genutzt werden können. Wenn wir Runnable implementieren, genießen wir diesen Vorteil nicht. Die Klasse Thread liefert mit der statischen Methode currentThread() die Objektreferenz für das Thread-Exemplar, das diese Anweisung gerade ausführt. Auf diese Weise lassen sich nichtstatische Thread-Methoden wie getName() verwenden.
Beispiel Gib die aktuelle Priorität des laufenden Threads und den Namen aus: System.out.println( Thread.currentThread().getPriority() ); // z. B. 5 System.out.println( Thread.currentThread().getName() );
// z. B. main
Falls es in einer Schleife wiederholten Zugriff auf Thread.currentThread() gibt, sollte das Ergebnis zwischengespeichert werden, denn der Aufruf ist nicht ganz billig. class java.lang.Thread implements Runnable Þ static Thread currentThread()
Liefert den Thread, der das laufende Programmstück ausführt.
2.2.3 Die Zustände eines Threads * Bei einem Thread-Exemplar können wir einige Zustände feststellen: 1. Nicht erzeugt: Der Lebenslauf eines Thread-Objekts beginnt mit new, doch befindet er sich damit noch nicht im Zustand ausführend. 2. Laufend (vom Scheduler berücksichtigt) und nicht laufend (vom Scheduler nicht berücksichtigt): Durch start() gelangt der Thread in den Zustand »ausführbar« beziehungsweise »laufend«. Der Zustand kann sich ändern, wenn ein anderer Thread zur Ausführung gelangt und dann dem aktuellen Thread den Prozessor entzieht. Der vormals laufende Thread kommt in den Zustand nicht laufend, bis der Scheduler ihm wieder Rechenzeit zuordnet. 3. Wartend: Dieser Zustand wird mittels spezieller Synchronisationstechniken oder Ein-/Ausgabefunktionen erreicht – der Thread verweilt in einem Wartezustand. 4. Beendet: Nachdem die Aktivität des Thread-Objekts beendet wurde, kann es nicht mehr aktiviert werden und ist tot, also beendet.
72
2.2
Thread-Eigenschaften und -Zustände
Zustand über Thread.State In welchem Zustand ein Thread gerade ist, zeigt die Methode getState(). Sie liefert ein Objekt vom Typ der Aufzählung Thread.State (die einzige Aufzählung im Paket java.lang), die Folgendes deklariert: Zustand
Erläuterung
NEW
neuer Thread, noch nicht gestartet
RUNNABLE
Läuft in der JVM.
BLOCKED
Wartet auf einen MonitorLock, wenn er etwa einen synchronized-Block betreten möchte.
WAITING
Wartet etwa auf ein notify().
TIMED_WAITING
Wartet etwa in einem sleep().
TERMINATED
Ausführung ist beendet.
Tabelle 2.1: Zustände eines Threads
Zudem lässt sich die Methode isAlive() verwenden, die erfragt, ob der Thread gestartet wurde, aber noch nicht tot ist.
2.2.4 Schläfer gesucht Manchmal ist es notwendig, einen Thread eine bestimmte Zeit lang anzuhalten. Dazu lassen sich Methoden zweier Klassen nutzen: Þ die überladene statische Methode Thread.sleep(): Etwas erstaunlich ist sicherlich, dass sie
keine Objektmethode von einem Thread-Objekt ist, sondern eine statische Methode. Ein Grund wäre, dass dadurch verhindert wird, externe Threads zu beeinflussen. Es ist nicht möglich, einen fremden Thread, über dessen Referenz wir verfügen, einfach einige Sekunden lang schlafen zu legen und ihn so von der Ausführung abzuhalten. Þ die Objektmethode sleep() auf einem TimeUnit-Objekt: Auch sie bezieht sich immer auf
den ausführenden Thread. Der Vorteil gegenüber sleep() ist, dass hier die Zeiteinheiten besser sichtbar sind.
73
2
2
Threads und nebenläufige Programmierung
Beispiel Der ausführende Thread soll zwei Sekunden lang schlafen. Einmal mit Thread.sleep(): try { Thread.sleep( 2000 ); } catch ( InterruptedException e ) { }
Dann mit TimeUnit: try { TimeUnit.SECONDS.sleep( 2 ); } catch ( InterruptedException e ) { }
Der Schlaf kann durch eine InterruptedException unterbrochen werden, etwa durch interrupt(). Die Ausnahme muss behandelt werden, da sie keine RuntimeException ist.
Praktisch wird das Erweitern der Klasse Thread bei inneren anonymen Klassen. Die folgende Anweisung gibt nach zwei Sekunden Schlafzeit eine Meldung auf dem Bildschirm aus: Listing 2.6: com/tutego/insel/thread/SleepInInnerClass.java, main() new Thread() { @Override public void run() { try { Thread.sleep( 2000 ); System.out.println( "Zeit ist um." ); } catch ( InterruptedException e ) { e.printStackTrace(); } } }.start();
Da new Thread(){...} ein Exemplar der anonymen Unterklasse ergibt, lässt die auf dem Ausdruck aufgerufene Objektmethode start() den Thread gleich loslaufen. Aufgaben dieser Art lösen auch die Timer gut. class java.lang.Thread implements Runnable Þ static void sleep(long millis) throws InterruptedException
Der aktuell ausgeführte Thread wird mindestens millis Millisekunden schlafen gelegt. Unterbricht ein anderer Thread den schlafenden, wird vorzeitig eine InterruptedException ausgelöst.
74
2.2
Thread-Eigenschaften und -Zustände
Þ static void sleep(long millis, int nanos) throws InterruptedException
Der aktuell ausgeführte Thread wird mindestens millis Millisekunden und zusätzlich nanos Nanosekunden schlafen gelegt. Im Gegensatz zu sleep(long) wird bei einer negativen Millisekundenanzahl eine IllegalArgumentException ausgelöst; auch wird diese Exception ausgelöst, wenn die Nanosekundenanzahl nicht zwischen 0 und 999.999 liegt. enum java.util.concurrent.TimeUnit extends Enum implements Serializable, Comparable Þ NANOSECONDS, MICROSECONDS, MILLISECONDS, SECONDS, MINUTES, HOURS, DAYS
Aufzählungselemente von TimeUnit. Þ void sleep(long timeout) throws InterruptedException
Führt ein Thread.sleep() für die Zeiteinheit aus. Eine überladene Methode Thread.sleep(long, TimeUnit) wäre nett, gibt es aber nicht.
Abbildung 2.3: UML-Diagramme für Timer und TimerTask
2.2.5 Mit yield() auf Rechenzeit verzichten Neben sleep() gibt es eine weitere Methode, um kooperative Threads zu programmieren: die Methode yield(). Sie funktioniert etwas anders als sleep(), da hier nicht nach Ablauf der genannten Millisekunden zum Thread zurückgekehrt wird, sondern yield() den Thread bezüglich seiner Priorität wieder in die Thread-Warteschlange des Systems einordnet. Einfach ausgedrückt, sagt yield() der Thread-Verwaltung: »Ich setze diese Runde aus und mache weiter, wenn ich das nächste Mal dran bin.«
75
2
2
Threads und nebenläufige Programmierung
class java.lang.Thread implements Runnable Þ static void yield()
Der laufende Thread gibt freiwillig seine Rechenzeit ab. Die Methode ist für Implementierungen der JVM nicht verbindlich.
2.2.6 Der Thread als Dämon Ein Server reagiert oft in einer Endlosschleife auf eingehende Aufträge vom Netzwerk und führt die gewünschte Aufgabe aus. In unseren bisherigen Programmen haben wir oft Endlosschleifen eingesetzt, sodass ein gestarteter Thread nie beendet wird. Wenn also run() wie in den vorangehenden Beispielen nie abbricht (Informatiker sprechen hier von terminiert), läuft der Thread immer weiter, auch wenn die Hauptapplikation beendet ist. Dies ist nicht immer beabsichtigt, da vielleicht Server-Funktionalität nach dem Beenden der Applikation nicht mehr gefragt ist. Dann sollte auch der endlos laufende Thread beendet werden. Um dies auszudrücken, erhält ein im Hintergrund arbeitender Thread eine spezielle Kennung: Der Thread wird als Dämon2 gekennzeichnet. Standardmäßig ist ein aufgebauter Thread kein Dämon.
Ein Dämon ist wie ein Heinzelmännchen im Hintergrund mit einer Aufgabe beschäftigt. Wenn das Hauptprogramm beendet ist und die Laufzeitumgebung erkennt, dass kein normaler Thread mehr läuft, sondern nur Dämonen, dann ist das Ende der Dämonen eingeläutet, und die JVM kommt zum Ende. Denn Dämonen-Threads sind Zulieferer: Gibt es keine Klienten mehr, werden auch sie nicht mehr gebraucht. Das ist wie bei den Göttern der Scheibenwelt: Glaubt keiner an sie, hören sie auf zu existieren. Wir müssen uns also um das Ende des Dämons nicht kümmern. Gleichzeitig heißt das aber auch, dass ein Dämonen-Thread vorsichtig mit Ein-/Ausgabeoperationen sein muss, denn er kann jederzeit – auch etwa während einer Schreiboperation auf die Festplatte – abgebrochen werden, was zu beschädigten Daten führen kann.
2
76
Das griechische dalx (engl. daemon) bezeichnet allerlei Wesen zwischen Gott und Teufel. Eine gute Einleitung gibt http://de.wikipedia.org/wiki/D%C3 %A4mon.
2.2
Thread-Eigenschaften und -Zustände
Hinweis Der Garbage-Collector (GC) ist ein gutes Beispiel für einen Dämon. Nur, wenn es andere Threads gibt, muss der Speicher aufgeräumt werden. Gibt es keine anderen Threads mehr, kann auch die JVM mit beendet werden, was auch die Dämonen-Threads beendet.
2
Wie ein Thread in Java zum Dämon wird Einen Thread in Java als Dämon zu kennzeichnen, heißt, die Methode setDaemon() mit dem Argument true aufzurufen. Die Methode ist nur vor dem Starten des Threads erlaubt. Danach kann der Status nicht wieder vom Dämon in den normalen Benutzer-Thread umgesetzt werden. Die Auswirkungen von setDaemon(true) können wir am folgenden Programm ablesen: Listing 2.7: com/tutego/insel/thread/DaemonThread.java package com.tutego.insel.thread; class DaemonThread extends Thread { DaemonThread() { setDaemon( true ); } @Override public void run() { while ( true ) System.out.println( "Lauf, Thread, lauf" ); } public static void main( String[] args ) { new DaemonThread().start(); } }
In diesem Programm wird der Thread gestartet, und danach ist die Anwendung sofort beendet. Vor dem Ende kann der neue Thread aber schon einige Zeilen auf der Konsole ausgeben.
77
2
Threads und nebenläufige Programmierung
Klammern wir die Anweisung mit setDaemon(true) aus, läuft das Programm ewig, da die Laufzeitumgebung auf das natürliche Ende der Thread-Aktivität wartet. class java.lang.Thread implements Runnable Þ final void setDaemon(boolean on)
Markiert den Thread als Dämon oder normalen Thread. Die Methode muss aufgerufen werden, bevor der Thread gestartet wurde, andernfalls folgt eine IllegalThreadStateException. Mit anderen Worten: Nachträglich kann ein existierender Thread nicht mehr zu einem Dämon gemacht werden, und ihm kann auch nicht die Dämonenhaftigkeit genommen werden, so er sie hat. Þ final boolean isDaemon()
Testet, ob der Thread ein Dämon-Thread ist.
AWT und Dämonen * Obwohl Dämonen für Hintergrundaufgaben eine gute Einrichtung sind, ist der AWT-Thread kein Dämon. Unterschiedliche AWT-Threads sind normale Benutzer-Threads; dazu gehören AWT-Input, AWT-Motif oder Screen_Updater. Dies bedeutet, dass bei einmaliger Nutzung einer AWT-Methode ein spezieller Nicht-Dämon-Thread gestartet wird, sodass die Applikation nicht automatisch beendet wird, wenn das Hauptprogramm endet. Daher muss die Applikation in vielen Fällen hart mit System.exit() beendet werden.
2.2.7 Das Ende eines Threads Es gibt Threads, die dauernd laufen, weil sie zum Beispiel Serverfunktionen implementieren. Andere Threads führen einmalig eine Operation aus und sind danach beendet. Allgemein ist ein Thread beendet, wenn eine der folgenden Bedingungen zutrifft: Þ Die run()-Methode wurde ohne Fehler beendet. Wenn wir eine Endlosschleife programmie-
ren, würde diese potenziell einen nie endenden Thread bilden. Þ In der run()-Methode tritt eine RuntimeException auf, die die Methode beendet. Das beendet
weder die anderen Threads noch die JVM als Ganzes. Þ Der Thread wurde von außen abgebrochen. Dazu dient die prinzipbedingt problematische
Methode stop(), von deren Verwendung abgeraten wird und die auch veraltet ist. Þ Die virtuelle Maschine wird beendet und nimmt alle Threads mit ins Grab.
78
2.2
Thread-Eigenschaften und -Zustände
Wenn der Thread einen Fehler melden soll Da ein Thread nebenläufig arbeitet, kann die run()-Methode synchron schlecht Exceptions melden oder einen Rückgabewert liefern. Wer sollte auch an welcher Stelle darauf hören? Eine Lösung für das Problem ist ein Listener, der sich beim Thread anmeldet und darüber informiert wird, ob der Thread seine Arbeit machen konnte oder nicht. Eine andere Lösung gibt Callable, mit dem ein spezieller Fehlercode zurückgegeben oder eine Exception angezeigt werden kann. Speziell für ungeprüfte Ausnahmen kann ein UncaughtExceptionHandler weiterhelfen.
2.2.8 Einen Thread höflich mit Interrupt beenden Der Thread ist in der Regel zu Ende, wenn die run()-Methode ordentlich bis zum Ende ausgeführt wurde. Enthält eine run()-Methode jedoch eine Endlosschleife – wie etwa bei einem Server, der auf eingehende Anfragen wartet –, so muss der Thread von außen zur Kapitulation gezwungen werden. Die naheliegende Möglichkeit, mit der Thread-Methode stop() einen Thread abzuwürgen, wollen wir in Abschnitt 2.2.10, »Der stop() von außen und die Rettung mit ThreadDeath«, diskutieren. Wenn wir den Thread schon nicht von außen beenden wollen, können wir ihn immerhin bitten, seine Arbeit aufzugeben. Periodisch müsste er dann nur überprüfen, ob jemand von außen den Abbruchswunsch geäußert hat.
Die Methoden interrupt() und isInterrupted() Die Methode interrupt() setzt von außen in einem Thread-Objekt ein internes Flag, das dann in der run()-Methode durch isInterrupted() periodisch abgefragt werden kann. Das folgende Programm soll jede halbe Sekunde eine Meldung auf dem Bildschirm ausgeben. Nach zwei Sekunden wird der Unterbrechungswunsch mit interrupt() gemeldet. Auf dieses Signal achtet die sonst unendlich laufende Schleife und bricht ab: Listing 2.8: com/tutego/insel/thread/ThreadusInterruptus.java, main() Thread t = new Thread() { @Override public void run() { System.out.println( "Es gibt ein Leben vor dem Tod. " ); while ( ! isInterrupted() )
79
2
2
Threads und nebenläufige Programmierung
{ System.out.println( "Und er läuft und er läuft und er läuft" ); try { Thread.sleep( 500 ); } catch ( InterruptedException e ) { interrupt(); System.out.println( "Unterbrechung in sleep()" ); } } System.out.println( "Das Ende" ); } }; t.start(); Thread.sleep( 2000 ); t.interrupt();
Die Ausgabe zeigt hübsch die Ablaufsequenz: Es gibt ein Leben vor dem Tod. Und er läuft und er läuft und er läuft Und er läuft und er läuft und er läuft Und er läuft und er läuft und er läuft Und er läuft und er läuft und er läuft Unterbrechung in sleep() Das Ende
Die run()-Methode im Thread ist so implementiert, dass die Schleife genau dann verlassen wird, wenn isInterrupted() den Wert true ergibt, also von außen die interrupt()-Methode für dieses Thread-Exemplar aufgerufen wurde. Genau dies geschieht in der main()-Methode. Auf den ersten Blick ist das Programm leicht verständlich, doch vermutlich erzeugt das interrupt() im catch-Block die Aufmerksamkeit. Stünde diese Zeile dort nicht, würde das Programm aller Wahrscheinlichkeit nach nicht funktionieren. Das Geheimnis ist folgendes: Wenn die Ausgabe nur jede halbe Sekunde stattfindet, befindet sich der Thread fast die gesamte Zeit über in der Schlafmethode sleep(). Also wird vermutlich der interrupt() den
80
2.2
Thread-Eigenschaften und -Zustände
Thread gerade beim Schlafen stören. Genau dann wird sleep() durch InterruptedException unterbrochen, und der catch-Behandler fängt die Ausnahme ein. Jetzt passiert aber etwas Unerwartetes: Durch die Unterbrechung wird das interne Flag zurückgesetzt, sodass isInterrupted() meint, die Unterbrechung habe gar nicht stattgefunden. Daher muss interrupt() erneut aufgerufen werden, da das Abbruch-Flag neu gesetzt werden muss und isInterrupted() das Ende bestimmen kann. Wenn wir mit der Objektmethode isInterrupted() arbeiten, müssen wir beachten, dass neben sleep() auch die Methoden join() und wait() durch die InterruptedException das Flag löschen.
Hinweis Die Methoden sleep(), wait() und join() lösen alle eine InterruptedException aus, wenn sie durch die Methode interrupt() unterbrochen werden. Das heißt, interrupt() beendet diese Methoden mit der Ausnahme.
Zusammenfassung: interrupted(), isInterrupted() und interrupt() Die Methodennamen sind verwirrend gewählt, sodass wir die Aufgaben noch einmal zusammenfassen wollen: Die Objektmethode interrupt() setzt in einem (anderen) Thread-Objekt ein Flag, dass es einen Antrag gab, den Thread zu beenden. Sie beendet aber den Thread nicht, obwohl es der Methodenname nahelegt. Dieses Flag lässt sich mit der Objektmethode isInterrupted() abfragen. In der Regel wird dies innerhalb einer Schleife geschehen, die darüber bestimmt, ob die Aktivität des Threads fortgesetzt werden soll. Die statische Methode interrupted() ist zwar auch eine Anfragemethode und testet das entsprechende Flag des aktuell laufenden Threads, wie Thread.currentThread().isInterrupted(), aber zusätzlich löscht es den Interrupt-Status auch, was isInterrupted() nicht tut. Zwei aufeinanderfolgende Aufrufe von interrupted() führen daher zu einem false, es sei denn, in der Zwischenzeit erfolgt eine weitere Unterbrechung.
2.2.9 UncaughtExceptionHandler für unbehandelte Ausnahmen Einer der Gründe für das Ende eines Threads ist eine unbehandelte Ausnahme, etwa von einer nicht aufgefangenen RuntimeException. Um in diesem Fall einen kontrollierten Abgang zu ermöglichen, lässt sich an den Thread ein UncaughtExceptionHandler hängen, der immer dann benachrichtigt wird, wenn der Thread wegen einer nicht behandelten Ausnahme endet. UncaughtExceptionHandler ist eine in Thread deklarierte innere Schnittstelle, die eine Operation void uncaughtException(Thread t, Throwable e) vorschreibt. Eine Implementierung der Schnitt-
stelle lässt sich entweder einem individuellen Thread oder allen Threads anhängen, sodass im
81
2
2
Threads und nebenläufige Programmierung
Fall des Abbruchs durch unbehandelte Ausnahmen die JVM die Methode uncaughtException() aufruft. Auf diese Weise kann die Applikation im letzten Atemzug noch den Fehler loggen, den die JVM über das Throwable e übergibt. class java.lang.Thread implements Runnable Þ void setUncaughtExceptionHandler(Thread.UncaughtExceptionHandler eh)
Setzt den UncaughtExceptionHandler für den Thread. Þ Thread.UncaughtExceptionHandler getUncaughtExceptionHandler()
Liefert den aktuellen UncaughtExceptionHandler. Þ Static void setDefaultUncaughtExceptionHandler(Thread.UncaughtExceptionHandler eh)
Setzt den UncaughtExceptionHandler für alle Threads. Þ static Thread.UncaughtExceptionHandler getDefaultUncaughtExceptionHandler()
Liefert den zugewiesenen UncaughtExceptionHandler aller Threads. Ein mit setUncaughtExceptionHandler() lokal gesetzter UncaughtExceptionHandler überschreibt den Eintrag für den setDefaultUncaughtExceptionHandler(). Zwischen dem mit dem Thread assoziierten Handler und dem globalen gibt es noch einen Handler-Typ für Thread-Gruppen, der jedoch seltener verwendet wird.
2.2.10
Der stop() von außen und die Rettung mit ThreadDeath *
Wenn ein Thread nicht auf interrupt() hört, aber aus irgendwelchen Gründen dringend beendet werden muss, müssen wir wohl oder übel die veraltete Methode stop() einsetzen.
Abbildung 2.4: Dass die Methode stop() veraltet ist, zeigen in Eclipse eine unterschlängelte Linie und ein Symbol am linken Rand an. Steht der Cursor auf der problematischen Zeile, weist eine Fehlermeldung ebenfalls auf das Problem hin.
deprecated gibt uns schon einen guten Hinweis darauf, stop() besser nicht zu benutzen (leider gibt es hier, im Gegensatz zu den meisten anderen veralteten Methoden, keinen einfachen, empfohlenen Ersatz). Überschreiben können wir stop() auch nicht, da es final ist. Wenn wir einen Thread von außen beenden, geben wir ihm keine Chance mehr, seinen Zustand
82
2.2
Thread-Eigenschaften und -Zustände
konsistent zu verlassen. Zudem kann die Unterbrechung an beliebiger Stelle erfolgen, sodass angeforderte Ressourcen frei in der Luft hängen können.
2 class java.lang.Thread implements Runnable Þ final void stop()
Wurde der Thread gar nicht gestartet oder ist er bereits abgearbeitet beziehungsweise beendet, kehrt die Methode sofort zurück. Andernfalls wird über checkAccess() geprüft, ob wir überhaupt das Recht haben, den Thread abzuwürgen. Dann wird der Thread beendet, egal was er zuvor unternommen hat; jetzt kann er nur noch sein Testament in Form eines ThreadDeathObjekts als Exception anzeigen.
Das ThreadDeath-Objekt So unmöglich ist das Reagieren auf ein stop() auch nicht. Immer dann, wenn ein Thread mit stop() zum Ende kommen soll, löst die JVM eine ThreadDeath-Ausnahme aus, die letztendlich den Thread beendet. ThreadDeath ist eine Unterklasse von Error, das wiederum von Throwable abgeleitet ist, sodass ThreadDeath mit einem try-Block abgefangen werden kann. Die Java-Entwickler haben ThreadDeath nicht zu einer Unterklasse von Exception gemacht, weil sie nicht wollten, dass ThreadDeath bei einer allgemeinen Exception-Behandlung über catch(Exception e) abgefangen wird.3 Wenn wir ThreadDeath auffangen, können wir noch auf den Tod reagieren und Aufräumarbeiten erlauben. Wir sollten aber nicht vergessen, anschließend das aufgefangene ThreadDeathObjekt wieder auszulösen, weil der Thread sonst nicht beendet wird: Listing 2.9: com/tutego/insel/thread/ThreadStopRecovery.java, main() Thread t = new Thread() { @Override public void run() { try { while ( true ) System.out.println( "I Like To Move It." ); } catch ( ThreadDeath td )
3
Dass wir die Klasse überhaupt nutzen können, ist einem Fehler von Sun zuzuschreiben; die Klasse sollte eigentlich nicht sichtbar sein.
83
2
Threads und nebenläufige Programmierung
{ System.out.println( "Das Leben ist nicht totzukriegen." ); throw td; } } }; t.start(); try { Thread.sleep( 1 ); } catch ( Exception e ) { } t.stop(); ThreadDeath bietet eine extravagante Möglichkeit, um das aktuell laufende Programm zu be-
enden: throw new ThreadDeath(). Die Anweisung System.exit() ist aber weniger Aufsehen erregend.
2.2.11
Ein Rendezvous mit join() *
Wollen wir Aufgaben auf mehrere Threads verteilen, kommt der Zeitpunkt, an dem die Ergebnisse eingesammelt werden. Die Resultate können allerdings erst dann zusammengebracht werden, wenn alle Threads mit ihrer Ausführung fertig sind. Da sie sich zu einem bestimmten Zeitpunkt treffen, heißt das auch Rendezvous. Zum Warten gibt es mehrere Strategien. Zunächst lässt sich mit Callable arbeiten, um dann mit get() synchron auf das Ende zu warten. Arbeiten wir mit Runnable, so kann ein Thread keine direkten Ergebnisse wie eine Methode nach außen geben, weil die run()-Methode den Ergebnistyp void hat. Da ein nebenläufiger Thread zudem asynchron arbeitet, wissen wir nicht einmal, wann wir das Ergebnis erwarten können. Die Übertragung von Werten ist kein Problem. Hier können Klassenvariablen und auch Objektvariablen helfen, denn über sie können wir kommunizieren. Jetzt fehlt nur noch, dass wir auf das Ende der Aktivität eines Threads warten können. Das funktioniert mit der Methode join(). In unserem folgenden Beispiel legt ein Thread t in der Variable result ein Ergebnis ab. Wir können die Auswirkungen von join() sehen, wenn wir die auskommentierte Zeile hineinnehmen: Listing 2.10: com/tutego/insel/thread/JoinTheThread.java package com.tutego.insel.thread; class JoinTheThread
84
2.2
Thread-Eigenschaften und -Zustände
{ static class JoinerThread extends Thread
2
{ public int result; @Override public void run() { result = 1; } } public static void main( String[] args ) throws InterruptedException { JoinerThread t = new JoinerThread(); t.start(); //
t.join(); System.out.println( t.result ); }
}
Ohne den Aufruf von join() wird als Ergebnis 0 ausgegeben, denn das Starten des Threads kostet etwas Zeit. In dieser Zeit geben wir aber die automatisch auf 0 initialisierte Klassenvariable aus. Nehmen wir join() hinein, wird die run()-Methode zu Ende ausgeführt, und der Thread setzt die Variable result auf 1. Das sehen wir dann auf dem Bildschirm. class java.lang.Thread implements Runnable Þ final void join() throws InterruptedException
Der aktuell ausgeführte Thread wartet auf den Thread, für den die Methode aufgerufen wird, bis dieser beendet ist. Þ final void join(long millis) throws InterruptedException
Wie join(), doch wartet diese Variante höchstens millis Millisekunden. Wurde der Thread bis dahin nicht vollständig beendet, fährt das Programm fort. Auf diese Weise kann versucht werden, innerhalb einer bestimmten Zeitspanne auf den Thread zu warten, sonst aber weiterzumachen. Ist millis gleich 0, so hat dies die gleiche Wirkung wie join(). Þ final void join (long millis, int nanos) throws InterruptedException
Wie join(long), jedoch mit potenziell genauerer Angabe der maximalen Wartezeit.
85
2
Threads und nebenläufige Programmierung
Nach einem thread.join(long) ist mitunter die thread.isAlive()-Methode nützlich, denn sie sagt aus, ob thread noch aktiv arbeitet oder beendet ist. In TimeUnit gibt es mit timedJoin() eine Hilfsmethode, um mit der Dauer schöner zu arbeiten. class java.lang.TimeUnit implements Runnable Þ voidtimedJoin(Thread thread, long timeout) throws InterruptedException
Berechnet aus der TimeUnit und dem timeout Millisekunden (ms) und Nanosekunden (ns) und führt ein join(ms, ns) auf dem thread aus.
Warten auf den Langsamsten Große Probleme lassen sich in mehrere Teile zerlegen, und jedes Teilproblem kann dann von einem Thread gelöst werden. Dies ist insbesondere bei Mehrprozessorsystemen eine lohnenswerte Investition. Zum Schluss müssen wir nur noch darauf warten, dass die Threads zum Ende gekommen sind, und das Ergebnis einsammeln. Dazu eignet sich join() gut.
Beispiel Zwei Threads arbeiten an einem Problem. Anschließend wird gewartet, bis beide ihre Aufgabe erledigt haben. Dann könnte etwa ein anderer Thread die von a und b verwendeten Ressourcen wieder nutzen: Thread a = new AThread(); Thread b = new BThread(); a.start(); b.start(); a.join(); b.join();
Es ist unerheblich, wessen join() wir zuerst aufrufen, da wir ohnehin auf den langsamsten Thread warten müssen. Wenn ein Thread schon beendet ist, kehrt join() sofort zurück. Eine andere Lösung für zusammenlaufende Threads besteht darin, diese in einer ThreadGruppe zusammenzufassen. Dann können sie zusammen behandelt werden, sodass nur das Ende der Thread-Gruppe beobachtet wird.
86
2.2
2.2.12
Thread-Eigenschaften und -Zustände
Arbeit niederlegen und wieder aufnehmen *
Wollen wir erreichen, dass ein Thread für eine bestimmte Zeit die Arbeit niederlegt und ein anderer den schlafenden Thread wieder aufwecken kann, müssten wir das selbst implementieren. Zwar gibt es mit suspend() und resume() zwei Methoden, doch diese Start-Stopp-Technik ist nicht erwünscht, da sie ähnlich problematisch ist wie stop(). class java.lang.Thread implements Runnable Þ final void suspend()
Lebt der Thread, wird er so lange eingefroren (schlafen gelegt), bis resume() aufgerufen wird. Þ final void resume()
Weckt einen durch suspend() lahmgelegten Thread wieder auf, der dann wieder arbeiten kann.
2.2.13
Priorität *
Jeder Thread verfügt über eine Priorität, die aussagt, wie viel Rechenzeit ein Thread relativ zu anderen Threads erhält. Die Priorität ist eine Zahl zwischen Thread.MIN_PRIORITY (1) und Thread.MAX_PRIORITY (10). Durch den Wert kann der Scheduler erkennen, welchem Thread er den Vorzug geben soll, wenn mehrere Threads auf Rechenzeit warten. Bei seiner Initialisierung bekommt jeder Thread die Priorität des erzeugenden Threads. Normalerweise ist es die Priorität Thread.NORM_PRIORITY (5). Das Betriebssystem (oder die JVM) nimmt die Threads immer entsprechend der Priorität aus der Warteschlange heraus (daher Prioritätswarteschlange). Ein Thread mit der Priorität N wird vor allen Threads mit der Wichtigkeit kleiner N, aber hinter denen der Priorität größer gleich N gesetzt. Ruft nun ein kooperativer Thread mit der Priorität N die Methode yield() auf, bekommt ein Thread mit der Priorität
Java(TM) 2 Runtime Environment, Standard Edition Sun Microsystems Inc. http://java.sun.com/ ; ... windows pentium i486 i386
Die Methode loadFromXML() liest aus einem InputStream und löst im Fall eines fehlerhaften Dateiformats eine InvalidPropertiesFormatException aus. Beim Speichern kann so ein Fehler natürlich nicht auftreten. Und genauso, wie bei store() ein OutputStream mit einem Kommentar gespeichert wird, macht das auch storeToXML(). Die Methode ist mit einem zusätzlichen Parameter überladen, der eine XML-Kodierung erlaubt. Ist der Wert nicht gesetzt, so ist die Standardkodierung UTF-8.
247
3
Datenstrukturen und Algorithmen
class java.util.Properties extends Hashtable Þ void store(OutputStream out, String header)
Speichert die Properties-Liste mithilfe des Ausgabestroms ab. Am Kopf der Datei wird eine Kennung geschrieben, die im zweiten Argument steht. Die Kennung darf null sein. Þ void load(InputStream inStream)
Lädt eine Properties-Liste aus einem Eingabestrom. Þ void storeToXML(OutputStream os, String comment, String encoding) throws IOException
Speichert die Properties im XML-Format. comment kann null sein, wenn ein Kommentar erwünschst ist. encoding steht für die Zeichenkodierung, etwa »Latin-1« oder »UTF-8«. Þ void loadFromXML(InputStream in) throws IOException, InvalidPropertiesFormatException
Liest Properites im XML-Format von einem Eingabestrom ein.
3.7.6 Klassenbeziehungen: Properties und Hashtable * Die Properties-Klasse ist eine Erweiterung von Hashtable, weil die Speicherung der Einstellungsdaten in dieser Datenstruktur erfolgt. Ein Properties-Objekt erweitert die Hash-Tabelle um die Möglichkeit, die Schlüssel-Werte-Paare in einem festgelegten Format aus einer Textdatei beziehungsweise einem Datenstrom zu laden und wieder zu speichern. Doch gerade weil Hashtable erweitert wird, sind auch alle Methoden der Klasse Hashtable auf ein PropertiesObjekt anwendbar. Das ergibt nicht für alle Methoden Sinn und ist auch nicht in jedem Fall problemlos. Dass Properties eine Unterklasse von Hashtable ist, ist ähnlich fragwürdig wie die Vererbungsbeziehung von Stack als Unterklasse von Vector. So ist ein Augenmerk auf die put()-Methode zu legen. Sie gibt es in der Klasse Properties nicht, denn put() wird von Hashtable geerbt. Wir sollten sie auch nicht verwenden, da es über sie möglich ist, Objekte einzufügen, die nicht vom Typ String sind. Das gleiche Argument könnte für get() gelten, doch sprechen zwei Dinge dagegen: zum einen, dass wir beim get() aus einem Hashtable-Objekt immer ein Object-Objekt bekommen und daher meistens eine Typanpassung benötigen; und zum anderen durchsucht diese Methode lediglich den Inhalt des angesprochenen PropertiesExemplars. getProperties() arbeitet da etwas anders. Nicht nur ist der Rückgabewert automatisch ein String, sondern getProperties() durchsucht auch übergeordnete Properties-Objekte mit, die zum Beispiel Standardwerte speichern.
248
3.8
Mit einem Iterator durch die Daten wandern
3.8 Mit einem Iterator durch die Daten wandern Wenn wir mit einer ArrayList oder LinkedList arbeiten, so haben wir zumindest eine gemeinsame Schnittstelle List, um an die Daten zu kommen. Doch was vereinigt eine Menge (Set) und eine Liste, sodass sich die Elemente der Sammlungen mit gleichem Programmcode erfragen lassen? Listen geben als Sequenz den Elementen zwar Positionen, aber in einer Menge hat kein Element eine Position. Hier bieten sich Iteratoren beziehungsweise Enumeratoren an, die unabhängig von der Datenstruktur alle Elemente auslesen – wir sagen dann, dass sie »über die Datenstruktur iterieren«. Und nicht nur eine Datenstruktur kann Daten liefern; eine Dateioperation könnte genauso gut Datengeber für alle Zeilen sein. In Java gibt es für Iteratoren zum einen die Schnittstelle java.util.Iterator und zum anderen den älteren java.util.Enumeration. Der Enumerator ist nicht mehr aktuell, daher konzentrieren wir uns zunächst auf den Iterator.
Abbildung 3.10: Iterator und Enumeration
3.8.1 Die Schnittstelle Iterator Ein Iterator ist ein Datengeber, der über eine Methode verfügen muss, um das nächste Element zu liefern. Dann muss es eine zweite Methode geben, die Auskunft darüber gibt, ob der Datengeber noch weitere Elemente zur Verfügung stellt. Zwei Operationen der Schnittstelle Iterator sind daher:
Iterator
Hast du mehr?
Gib mir das Nächste!
hasNext()
next()
Tabelle 3.4: Zwei zentrale Methoden des Iterators
Die Methode hasNext() ermittelt, ob es überhaupt ein nächstes Element gibt, und wenn ja, ob next() das nächste Element erfragen darf. Bei jedem Aufruf von next() erhalten wir ein weite-
res Element der Datenstruktur. So kann der Iterator einen Datengeber (in der Regel eine Datenstruktur) Element für Element ablaufen. Übergehen wir ein false von hasNext() und fragen trotzdem mit next() nach dem nächsten Element, bestraft uns eine NoSuchElementException.
249
3
3
Datenstrukturen und Algorithmen
Prinzipiell könnte die Methode, die das nächste Element liefert, auch per Definition null zurückgeben und so anzeigen, dass es keine weiteren Elemente mehr gibt. Allerdings kann null dann kein gültiger Iterator-Wert sein, und das wäre ungünstig. interface java.util.Iterator Þ boolean hasNext()
Liefert true, falls die Iteration weitere Elemente bietet. Þ E next()
Liefert das nächste Element in der Aufzählung oder NoSuchElementException, wenn keine weiteren Elemente mehr vorhanden sind. Þ void remove()
Die Schnittstelle Iterator erweitert selbst keine weitere Schnittstelle.11 Die Deklaration ist generisch, da das, was der Iterator liefert, immer von einem bekannten Typ ist.
Beispiel Die Aufzählung erfolgt meistens über einen Zweizeiler. Da jede Collection eine Methode iterator() besitzt, lassen sich alle Elemente wie folgt auf dem Bildschirm ausgeben: Collection set = new TreeSet(); Collections.addAll( set, "Horst", "Schlämmer", "Hape" , "Kerkeling" ); for ( Iterator iter = set.iterator(); iter.hasNext(); ) System.out.println( iter.next() );
Das erweiterte for macht das Ablaufen aber noch einfacher, und der gleiche Iterator steckt dahinter.
Beim Iterator geht es immer nur vorwärts Im Gegensatz zum Index eines Felds können wir beim Iterator ein Objekt nicht noch einmal auslesen (next() geht automatisch zum nächsten Element), nicht vorspringen beziehungsweise hin und her springen. Ein Iterator gleicht anschaulich einem Datenstrom; wollten wir ein Element zweimal besuchen, zum Beispiel eine Datenstruktur von rechts nach links noch einmal durchwandern, dann müssen wir wieder ein neues Iterator-Objekt erzeugen oder uns die Elemente zwischendurch merken. Nur bei Listen und sortierten Datenstrukturen ist die Reihenfolge der Elemente vorhersehbar.
11
Konkrete Enumeratoren (und Iteratoren) können nicht automatisch serialisiert werden; die realisierenden Klassen müssen hierzu die Schnittstelle Serializable implementieren.
250
3.8
Mit einem Iterator durch die Daten wandern
Hinweis In Java steht der Iterator nicht auf einem Element, sondern zwischen Elementen.
3 3.8.2 Der Iterator kann (eventuell auch) löschen Die Schnittstelle Iterator bietet prinzipiell die Möglichkeit, das zuletzt aufgezählte Element aus dem zugrunde liegenden Container mit remove() zu entfernen. Vor dem Aufruf muss also next() das zu löschende Element als Ergebnis geliefert haben. Eine Enumeration kann die aufgezählte Datenstruktur grundsätzlich nicht verändern.
Beispiel Ein LinkedHashSet ist eine auf dem HashSet basierende Datenstruktur, die sich aber zusätzlich die Einfügereihenfolge merkt. Ein Programm soll die ältesten Einträge löschen und nur noch die neusten zwei Elemente behalten: LinkedHashSet set = new LinkedHashSet(); set.addAll( Arrays.asList( 3, 2, 1, 6, 5, 4 ) ); System.out.println( set );
// [3, 2, 1, 6, 5, 4]
for ( Iterator iter = set.iterator(); iter.hasNext(); ) { iter.next(); if ( set.size() > 2 ) iter.remove(); } System.out.println( set ); // [5, 4]
interface java.util.Iterator Þ boolean hasNext() Þ E next() Þ void remove()
Entfernt das Element, das der Iterator zuletzt bei next() geliefert hat. Kann ein Iterator keine Elemente löschen, so löst er eine UnsupportedOperationException aus. In der Dokumentation ist die Methode remove() als optional gekennzeichnet. Das heißt, dass ein konkreter Iterator kein remove() können muss – auch eine UnsupportedOperationException ist möglich. Das ist etwa dann der Fall, wenn ein Iterator von einer unveränderbaren Datenstruktur kommt.
251
3
Datenstrukturen und Algorithmen
Hinweis Warum es die Methode remove() im Iterator gibt, ist eine interessante Frage. Die Erklärung dafür: Der Iterator kennt die Stelle, an der sich die Daten befinden (eine Art Cursor). Darum können die Daten dort auch effizient und direkt gelöscht werden. Das erklärt jedoch nicht unbedingt, warum es keine Einfüge-Methode gibt. Ein allgemeiner Grund mag sein, dass bei vielen Container-Typen das Einfügen an einer bestimmten Stelle keinen Sinn ergibt, etwa bei einem sortierten NavigableSet oder NavigableMap. Dort ist die Einfügeposition durch die Sortierung vorgegeben oder belanglos (beziehungsweise bei HashSet durch die interne Realisierung bestimmt), also kein Fall für einen Iterator. Dazu wirft das Einfügen weitere Fragen auf: vor oder nach dem zuletzt per next() gelieferten Element? Soll das neue Element mit aufgezählt werden oder nicht? Soll es auch dann nicht aufgezählt werden, wenn es in der Sortierung erst später an die Reihe käme? Eine Löschen-Methode ist problemloser und universell anwendbar.
3.8.3 Einen Zufallszahleniterator schreiben Zur Übung wollen wir einen Iterator schreiben, der Zufallszahlen liefert. Der Konstruktor soll dazu die maximale Zufallszahl entgegennehmen (exklusiv), die Methode next() liefert anschließend immer die Zufallszahl und hasNext() immer true. Da auch remove() von der Schnittstelle Iterator vorgeschrieben ist, müssen wir die Methode implementieren, lösen jedoch eine Ausnahme aus, da es nichts zu löschen gibt. Listing 3.23: com/tutego/insel/util/RandomIterator.java package com.tutego.insel.util; import java.util.*; /** * Iterator for pseudorandom numbers. */ public class RandomIterator implements Iterator { private final Random random = new Random(); private final int bound; /** * Initializes this iterator with a maximum value (exclusive) for * pseudorandom numbers.
252
3.8
Mit einem Iterator durch die Daten wandern
* @param bound Maximum (exclusive) pseudorandom */ public RandomIterator( int bound ) {
3 this.bound = bound;
} /** * Always true. * @return {@code true}. */ @Override public boolean hasNext() { return true; } /** * Returns a pseudorandom, uniformly distributed {@code Integer} value * between 0 (inclusive) and the specified value (exclusive). * @return Next pseudorandom. */ @Override public Integer next() { return random.nextInt( bound ); } /** * Not supported. * @throws UnsupportedOperationException */ @Override public void remove() { throw new UnsupportedOperationException(); } }
253
3
Datenstrukturen und Algorithmen
Ein Beispiel: Listing 3.24: com/tutego/insel/util/RandomIteratorDemo.java, main() Iterator random = new RandomIterator( 6 ); int dice1 = random.next(); int dice2 = random.next(); System.out.println( dice1 ); System.out.println( dice2 );
Als Übung kann jeder den Iterator so verändern, dass auch ein Startwert definiert werden kann (jetzt ist er 0).
3.8.4 Iteratoren von Sammlungen, das erweiterte for und Iterable Jede Collection wie ArrayList oder HashSet liefert mit iterator() einen Iterator. interface java.util.Collection extends Iterable Þ Iterator iterator()
Liefert den Iterator der Datenstruktur. Collection erweitert eine Schnittstelle Iterable, die unter Java 5 eingeführt wurde; sie schreibt die Methode vor, die einen Iterator liefert. interface java.util.Iterable Þ Iterator iterator()
Liefert den Iterator für eine Sammlung.
Der typisierte Iterator Von einer typisierten Collection liefert iterator() ebenfalls einen typisierten Iterator. Das heißt, die Datenstruktur überträgt den generischen Typ auf den Iterator. Nehmen wir eine mit String typisierte Sammlung an: Collection c = new LinkedList();
Ein Aufruf von c.iterator() liefert nun Iterator, und beim Durchlaufen über den Iterator kann die explizite Typanpassung beim next() entfallen:
254
3.8
Mit einem Iterator durch die Daten wandern
for ( Iterator i = c.iterator(); i.hasNext(); ) { String s = i.next();
3
... }
Iterator und erweitertes for Stößt der Compiler auf ein erweitertes for, und erkennt er rechts vom Doppelpunkt den Typ Iterable, so erzeugt er Bytecode für eine Schleife, die den Iterator und seine bekannten Methoden hasNext() und next() nutzt. Nehmen wir eine statische Methode totalStringLength(List) an, die ermitteln soll, wie viele Zeichen alle Strings zusammen besitzen. Aus static int totalStringLength( List strings ) { int result = 0; for ( String s : strings ) result += s.length(); return result; }
erzeugt der Compiler selbstständig: static int totalStringLength( List strings ) { int result = 0; for ( Iterator iter = strings.iterator(); iter.hasNext(); ) result += iter.next().length(); return result; }
Da die erweiterte Schleife das Ablaufen einer Datenstruktur vereinfacht, wird ein explizit ausprogrammierter Iterator selten benötigt. Doch der Iterator kann ein Element über die remove()-Methode des Iterators löschen, was über das erweiterte for nicht möglich ist.
255
3
Datenstrukturen und Algorithmen
Einen eigenen Iterator und Iterable-Implementierung Die Konzepte Iterator und Iterable müssen sauber getrennt werden: ein Iterator ist das Objekt, das durch eine Datensammlung läuft, während ein Iterable das Objekt ist, das einen anderen Iterator liefert. Eine Klasse kann beide Schnittstellen implementieren, doch oft kommt das nicht vor. Für unser nächstes Beispiel ergibt das aber Sinn – es nutzt einem Iterator, der durch eine Sammlung läuft und immer dann, wenn er an das Ende kommt, wieder von vorne beginnt. Zunächst der Einsatz: Listing 3.25: com/tutego/insel/util/RotatingIteratorDemo.java, main int i = 0; for ( String s : new RotatingIterator( "Bohnen", "Eintopf" ) ) { System.out.println( "Toll, heute gibt es " + s ); if ( i++ == 7 ) break; }
Zur Implementierung: Listing 3.26: com/tutego/insel/util/RotatingIterator.java package com.tutego.insel.util; import java.util.Arrays; import java.util.Collection; import java.util.ConcurrentModificationException; import java.util.Iterator; import java.util.NoSuchElementException; /** * An {@link Iterator} that goes over a given {@link Collection} * but rolls back to the start when it reaches the end. * If the underling {@link Collection} contains no elements the method * {@link #hasNext()} will return {@code false}. Removing elements is * supported if the Iterator of the underlying Collection * supports {@link Iterator#remove()}. Iterating over the underling * Collection and modifying it at the same time will probably result in a * {@link ConcurrentModificationException}. */
256
3.8
Mit einem Iterator durch die Daten wandern
public class RotatingIterator implements Iterator, Iterable { private final Collection
Dann müssen alle JSP-Tags (für Scriptlets, Ausdrücke ...) in äquivalente XML-Anweisungen umgesetzt werden: Normale Syntax
XML-Syntax
expression
scriptlet
declaration
Tabelle 14.7: XML-Entsprechungen für JSP-Tags
14.8.6 Implizite Objekte für Scriptlets und JSP-Ausdrücke Der Programmcode der Scriptlets wird in die service()-Methode eines Servlets gestellt. Dort haben wir Zugriff auf einige vordefinierte Variablen, die so in der JSP-Spezifikation beschrieben sind. Sie heißen implizite Objekte. Ihr Name kann nicht verändert werden, und eigene Variablen dürfen nicht so benannt werden. Implizites Objekt
Benutzt, um ...
Typ
request
Anfragen zu verarbeiten und Eingabewerte
HttpServletRequest
wie Parameter zu lesen. response
etwas an den Client zu übermitteln, wie
HttpServletResponse
beispielsweise Header. out
in den Ausgabestrom zu schreiben.
JspWriter
application
Daten aller Anwendungen zu speichern.
ServletContext
session
Sitzungsinformationen zu speichern.
HttpSession
pageContext
Kontextdaten für eine Seite zu speichern.
PageContext
Page
ein Exemplar des Servlets anzusprechen.
Object (this)
Tabelle 14.8: Implizite JSP-Objekte
1108
14.9
Sitzungsverfolgung (Session Tracking)
Wenn wir programmtechnisch eine Ausgabe machen, schreiben wir:
Das ist gleichwertig mit . Natürlich können wir immer das out-Objekt zur Ausgabe einsetzen, doch hat dies wieder den Nachteil, dass die Visualisierung nicht vom Programmcode getrennt ist. In Scriptlet-Code kann auf diese Weise auf die Ausgabe zugegriffen werden, sodass die Scriptlets nicht immer durch JSP-Ausdrücke unterbrochen werden müssen.
14.9 Sitzungsverfolgung (Session Tracking) Jeder Auftrag an den Webserver wird unabhängig von anderen Aufträgen verwaltet. Wenn wir beispielsweise eine Seite neu laden oder einen Verweis verfolgen, weiß der Server nicht (beziehungsweise interessiert sich nicht dafür), dass die Anfrage von uns kam. Was an diesem Verhalten deutlich wird, ist das Fehlen eines Zustands. Es fehlt also die Möglichkeit, dass ein Client vom Server identifiziert wird und einem aktuellen Zustand des bidirektionalen Kommunikationsverlaufes zugeordnet werden kann. Der Zustand bezieht sich hier auf eine nichtexistente serverseitige Information. Aus diesem Grund wird HTTP auch als zustandsloses Protokoll bezeichnet. Dass dies aber nicht immer wünschenswert ist und sogar einen Nachteil darstellen kann, sehen wir an unterschiedlichen Anforderungen: Þ Ein Warenkorb für den Einkauf: In Online-Systemen wird ein Einkaufswagen gefüllt, und
unterschiedliche Webseiten informieren Kaufwillige über die Produkte. Wenn der Server die Seitenanfrage einem Client nicht zuordnen kann, ist es nicht möglich, den Warenkorb individuell zu füllen. Þ Individualisierung: Benutzer können auf sie persönlich zugeschnittene Webseiten sehen
und etwa das Wetter auf Bali auf der Startseite auswählen sowie die Fußballergebnisse von Schalke 04. Þ Demoskopie: Das System eignet sich auch für die Benutzerüberwachung. Besucht ein Be-
nutzer eine Seite mehrmals, kann der Betreiber dies erkennen und diese Information mit einem »Ist-beliebt-Faktor« verbinden. Diese Information lässt sich natürlich kommerziell gut nutzen.
14.9.1
Lösungen für die Sitzungsverfolgung
Es ist also ein System gesucht, das es dem Server erlaubt, den Client zu identifizieren, auch wenn HTTP ein zustandsloses Protokoll ist. Als Lösungen bieten sich an:
1109
14
14
JavaServer Pages und Servlets
Þ Cookies: Ein Cookie speichert eine Kennung, sodass der Server den Client erkennt und die
Informationen für ihn speziell aufbereitet. Obwohl dies in Java durch die Cookie-Klasse einfach möglich ist, hat dieser Ansatz noch einige Schwächen. Dem Servlet fällt die Aufgabe zu, aus der Cookie-Kennung die entsprechende Sitzung herauszusuchen und die Daten zu holen. Ein weiteres Problem ergibt sich dadurch, dass Cookies zwar möglich sind, aber vom Benutzer abgelehnt werden können, da dieser seine Anonymität aufs Spiel gesetzt sieht. Schaltet der Benutzer in seinem Lieblingsbrowser die Cookies aus, können wir nichts machen. Doch auch wenn Cookies verwendet werden, bleibt die Frage, wie lange der Cookie gültig sein soll. Hier ist zu überlegen, ob die Voreinstellung, dass der »Keks« nur eine Sitzung übersteht, sinnvoll ist. Þ URL-Rewriting: Da ein Servlet vom Aufrufer Parameter bekommen kann, ist es eine nette
Idee, an die URL einen Wert anzuhängen, der die aktuelle Sitzung kennzeichnet. Diese Kennung entspricht dann genau dem Wert des Cookies. Die Lösung ist simpel und funktioniert bei allen Browsern. Der Nachteil auf der Serverseite ist wiederum, dass uns die Aufgabe zufällt, der Kennung die Sitzung zuzuordnen. Zudem ist Vorsicht geboten, da diese Kennung bei jedem Verweis wieder angehängt wird. Außerdem ist es für den Benutzer sehr unschön, diese Kennungen zu sehen, zumal sie in die Bookmarks übernommen werden. Dies führt zu dem Problem, dass eine Sitzung angesprochen werden kann, die gar nicht mehr existiert. Dies ist ein sehr schwerwiegendes Problem, da die Anhängsel ja nicht wie Cookies automatisch veralten. Þ Versteckte Felder (engl. hidden fields): In HTML-Seiten lassen sich versteckte Informatio-
nen in Formularen anlegen, die beim Versenden automatisch mitgeschickt werden. Dies sieht etwa so aus:
Diese versteckten Informationen können auch genutzt werden, um eine Sitzungs-ID mitzuschicken. Der Vorteil ist, dass wir wieder keine Cookies benötigen und die URL nicht länger wird; der Nachteil ist, dass die Information immer dynamisch mit eingebaut werden muss.
14.9.2 Sitzungen in JSPs Verbindet sich ein Browser zum ersten Mal mit einer JSP, so erzeugt der Servlet-Container automatisch eine neue Sitzung und sendet standardmäßig einen Cookie zurück. Client und Server tauschen dann bei allen weiteren Anfragen diesen Cookie aus, sodass der Server den Client wiedererkennen kann. Wenn der Benutzer Cookies ablehnt, müssen wir eine zweite Implementierung anbieten, die Sitzungsinformationen an die URL anhängt, aber das soll jetzt kein Thema sein.
1110
14.10
Servlets
14.9.3 Auf Session-Dateien zurückgreifen Der Cookie, den der Server automatisch generiert, enthält eine ID, und diese ID ist mit einem Assoziativspeicher verbunden. In diesen Assoziativspeicher können wir Schlüssel/WertePaare setzen oder Werte über die Schlüssel erfragen. Für den Assoziativspeicher gibt es in der EL die implizite Variable sessionScope – sie bietet alle Daten einer Sitzung. Zusammenfassend lässt sich festhalten, dass die unterschiedlichen impliziten EL-Objekte pageScope, requestScope, sessionScope und applicationScope alle jeweils Zugriffe auf Daten in unterschiedlichen Gültigkeitsbereichen ermöglichen.
Beispiel Lege eine Variable über ein Scriptlet in den Session-Scope, und lies sie mit der EL wieder aus:
Die URL in der Session was: ${sessionScope.url}.
Die erste Zeile macht deutlich, dass für das Setzen (das Gleiche gilt für das Löschen) auf Scriptlets zurückgegriffen werden muss oder auf die JSTL, mit der das Setzen so aussehen würde: . Die Variable session ist eine JSPVariable vom Typ HttpSession und bietet Methoden wie setAttribute(), removeAttribute(). In realistischen Programmen wird eine JSP keine Daten verändern, sondern nur Servlets bzw. ein Framework.
Beispiel Beende eine Session:
Beenden wir die Sitzung – etwa nach einem Logout – nicht selbst, kommt ein Timeout und sie wird automatisch beendet.
14.10
Servlets
Wir kommen nun noch einmal auf unser Eingangsbeispiel für ein Servlet zurück, das eine einfache Ausgabe erzeugt: Listing 14.18: com/tutego/web/servlet/SchnarchServlet.java package com.tutego.web.servlet; import java.io.IOException;
1111
14
14
JavaServer Pages und Servlets
import javax.servlet.http.*; public class SchnarchServlet extends HttpServlet { @Override protected void doGet( HttpServletRequest req, HttpServletResponse res ) throws IOException { res.getWriter().println( "'Chr! Schnarch! Razong! Chr! Chr! Rapüh!'" ); res.getWriter().println( "(Disneys beste Comics, Band 5, S. 218)" ); } }
Alle Servlets implementieren die Schnittstelle javax.servlet.Servlet beziehungsweise erweitern die Klasse GenericServlet oder HttpServlet. Ein HttpServlet enthält wichtige Arbeitsmethoden für das Protokoll HTTP. Eine Erweiterung von GenericServlet ist eher unüblich, es sei denn, Nicht-HTTP-Protokolle wie FTP werden angeboten: abstrat class javax.servlet.http.HttpServlet extends GenericServlet implements Serializable Þ protected void service(HttpServletRequest req, HttpServletResponse resp)
Empfängt alle HTTP-Requests und leitet sie aufgrund der unterschiedlichen HTTP-Methoden auf die jeweiligen doXXX()-Methoden weiter. Þ protected void doDelete(HttpServletRequest req, HttpServletResponse resp)
Wird von der service()-Methode aufgerufen, wenn ein HTTP-DELETE kommt. Þ protected void doGet(HttpServletRequest req, HttpServletResponse resp)
Wird von der service()-Methode aufgerufen, wenn ein HTTP-GET kommt. Þ protected void doOptions(HttpServletRequest req, HttpServletResponse resp)
Wird von der service()-Methode aufgerufen, wenn ein HTTP-OPTIONS kommt. Þ protected void doPost(HttpServletRequest req, HttpServletResponse resp)
Wird von der service()-Methode aufgerufen, wenn ein HTTP-POST kommt. Þ Protected void doPut(HttpServletRequest req, HttpServletResponse resp)
Wird von der service()-Methode aufgerufen, wenn ein HTTP-PUT kommt. Þ protected void doTrace(HttpServletRequest req, HttpServletResponse resp)
Wird von der service()-Methode aufgerufen, wenn ein HTTP-TRACE kommt.
1112
14.10
Servlets
Lebenszyklus Spricht der Client am Webserver ein Servlet an, so bildet der Servlet-Container ein Exemplar der Servlet-Klasse (in unserem Fall SchnarchServlet) und ruft nach der Initialisierung auf dem Objekt die Methode service() auf. Die service()-Methode delegiert beim HttpServlet je nach HTTP-Methode zu den doXXX()-Methoden, also etwa doGet() bei einer GET-Anfrage. Alle doXXX()-Methoden haben zwei Parameter: Þ HttpServletRequest: Repräsentiert die Anfrage. Es lassen sich zum Beispiel Parameter oder
Header erfragen, die der Client zum Server schickt. Þ HttpServletResponse: Repräsentiert das Ergebnis. Es lassen sich zum Beispiel Daten zurück
zum Client schicken, genauso Antwort-Header (etwa Content-Type) setzen. Am wichtigsten ist die Methode getWriter(), die uns eine Referenz auf ein Writer-Objekt liefert, damit wir die HTML-Elemente für die Seite abschicken. Für Binärdaten können wir uns auch einen normalen OutputStream besorgen, damit wir zum Beispiel Bilder schicken können.
Header und Content-Typ Mit setHeader() lassen sich weitere Header setzen.
14
response.setHeader( "Content-Type", "text/html");
Die Methode erhält als Argument zwei Zeichenketten: den Header und den dazugehörigen Wert. Da der Header Content-Type jedoch so häufig benötigt wird, bietet die Schnittstelle HttpServletResponse dafür die eigene Methode setContentType() an: response.setContentType( "text/html" );
Um reine (Nur-)Textausgaben zu erzeugen, setzen wir den Content-Header mit text/plain.
Zentrale Methoden von HttpServletRequest Die interessanteren Methoden der Schnittstelle HttpServletRequest sind: interface javax.servlet.http.HttpServletRequest extends ServletRequest Þ String getHeader(String name) Þ Enumeration getHeaderNames() Þ Enumeration getHeaders(String name) Þ int getIntHeader(String name) Þ long getDateHeader(String name)
1113
14
JavaServer Pages und Servlets
Þ String getPathInfo() Þ String getPathTranslated() Þ String getQueryString() Þ String getRequestURI() Þ String getServletPath() Þ HttpSession getSession() Þ HttpSession getSession(boolean create) Þ Cookie[] getCookies()
Die pfadorientierten Methoden sind am besten an einem Beispiel erklärt: Anfrage auf /geo/new/welcome.jsp/update bei dem Kontextpfad geo getRequestURI()
/geo/new/welcome.jsp/udate
getContextPath()
/geo
getServletPath()
/new/welcome.jsp
getPathInfo()
/update
Tabelle 14.9: Pfad-Methoden und was sie liefern
Das HttpServletRequest von ServletRequest ist zentral, denn bei ServletRequest sind die wichtigen Methoden zur Erfragen der Parameter: interface javax.servlet.ServletRequest Þ String getParameter(String name) Þ Map getParameterMap() Þ Enumeration getParameterNames() Þ String[] getParameterValues(String name)
Zentrale Methoden bei HttpServletResponse Daten, die vom Servlet zurück zum Client gehen, werden über das HttpServletResponse-Objekt gesetzt. Die interessanten Methoden sind: interface javax.servlet.http.HttpServletResponse extends ServletResponse Þ void addHeader(String name, String value) Þ void addDateHeader(String name, long date)
1114
14.10
Servlets
Þ void addIntHeader(String name, int value) Þ void addCookie(Cookie cookie) Þ String encodeRedirectURL(String name) Þ void sendError(int sc) Þ void sendError(int sc, String msg) Þ void sendRedirect(String location) Þ void setDateHeader(String name, long date) Þ void setHeader(String name, String value) Þ void setIntHeader(String name, int value) Þ void setStatus(int sc)
Die zentrale Methode, um an den Ausgabestrom zu kommen, stammt aus dem Basistyp ServletResponse. Die wichtigen Methoden sind: interface javax.servlet.ServletResponse Þ ServletOutputStream getOutputStream()
14
Þ PrintWriter getWriter() Þ void setCharacterEncoding(String charset) Þ void setContentLength(int len) Þ void setContentType(String type) Þ void setLocale(Locale locale) Þ void flushBuffer() Þ void reset()
14.10.1
Servlets compilieren
Um Servlets zu übersetzen, muss das Jar-Archiv servlet.jar im Pfad sein. Dazu können wir entweder den CLASSPATH anpassen oder das Archiv einfach in das jre/lib/ext-Verzeichnis der Java SE kopieren; das Archiv liegt Tomcat im Ordner lib bei. Bei der Enterprise-Version von Java (Java EE) ist die Bibliothek schon im Pfad eingebunden. Wir erinnern uns: Eine Webapplikation besteht aus einem Verzeichnis WEB-INF mit den optionalen Verzeichnissen classes und lib. Die übersetzten Klassen müssen in das Verzeichnis classes. Falls das Servlet in einem Paket liegt, muss diese Paketstruktur natürlich auch auf die Verzeichnisstruktur abgebildet werden.
1115
14
JavaServer Pages und Servlets
Die Java EE Version von Eclipse bindet das Archiv selbstständig ein und übersetzt die Klasse automatisch im richtigen Verzeichnis. Wir legen einfach das Servlet im Quellcodeordner ab, und es wird somit automatisch unter WEB-INF/classes compiliert.
14.10.2
Servlet-Mapping
Um nun den Server zur Ausführung unserer Servlets zu bewegen, gibt es zwei Möglichkeiten: Þ Deployment-Descriptor web.xml im Verzeichnis WEB-INF jeder Webapplikation Þ Standard-Servlet-Mapping unter /servlet/
Für ein Servlet, das über File 폷 New 폷 Other... 폷 Web 폷 Servlet angelegt wird, stehen die Einträge automatisch im Deployment-Descriptor web.xml.
Der Deployment-Descriptor web.xml Soll der Invoker nicht zum Einsatz kommen, müssen wir für jede Webapplikation eine Datei web.xml im Verzeichnis WEB-INF anlegen. Sie dient dazu, die Webapplikation zu vervollständigen. Der Deployment-Descriptor zählt die Servlets auf und weist ihnen Pfade zu. web.xml ist eine klassische XML-Datei, die validiert wird. Im Wurzelelement finden sich jetzt die spannenden Einträge, wie für unser SchnarchServlet: Listing 14.19: WEB-INF/web.xml
SchnarchServlet com.tutego.web.servlet.SchnarchServlet
SchnarchServlet /SchnarchServlet
1116
14.10
Servlets
index.html index.jsp
Damit ist alles komplett. Die Angabe von http://localhost:8080/web/SchnarchServlet präsentiert unser Servlet und seine Ausgabe.
Standard-Servlet-Mapping Im Fall des Standard-Servlet-Mappings wird ein Servlet unter der URI servlet/SERVLETNAME zugänglich. Um diese Möglichkeit einzuschalten, müssen wir die globale Konfigurationsdatei conf/web.xml modifizieren und an zwei Stellen das sogenannte Invoker-Servlet aktivieren.
14.10.3
Der Lebenszyklus eines Servlets
Der Container für Servlets registriert eine Anfrage durch den Client und lädt das Servlet in den Speicher. Da Servlets normale Klassen sind, übernimmt ein spezieller Klassenlader diese Aufgabe. Die Abarbeitung findet anschließend in einem Thread statt, der die Methoden des Servlet-Objekts aufruft. Über die Schnittstelle Servlet werden drei elementare Methoden für die Initialisierung, die Abarbeitung der Anfragen und die Beendigung vorgeschrieben. Der Ablauf dieser Methoden heißt Lebenszyklus eines Servlets. Die folgende Aufzählung zeigt alle Methoden, die die Schnittstelle Servlet für alle Java-Servlets vorschreibt. interface javax.servlet.Servlet Þ void init(ServletConfig config)
Wird zu Beginn eines Dienstes aufgerufen. Þ void service(ServletRequest req, ServletResponse res)
Der Container leitet die Anfrage an das Servlet an diese Stelle. Þ void destroy()
Wird am Ende eines Servlets vom Container genau einmal aufgerufen. Þ ServletConfig getServletConfig()
Liefert ein ServletConfig-Objekt, das Initialisierungs- und Startparameter kapselt. Þ String getServletInfo()
Liefert Informationen über das Servlet, wie Autor, Version und Copyright.
1117
14
14
JavaServer Pages und Servlets
Ein HttpServlet ist eine besondere Implementierung der Servlet-Schnittstelle. Die Klasse implementiert service(ServletRequest req, ServletResponse res), doch leitet es dann an service(HttpServletRequest req, HttpServletResponse resp) weiter, was wiederum zu den doXXX()Methoden geht.
14.10.4
Mehrere Anfragen beim Servlet und die Thread-Sicherheit
In der Regel nutzt der Container pro Anfrage einen Thread, der dann die service()-Methode des Servlet-Objekts betritt und die Anfrage bearbeitet. Es gibt demnach für mehrere Aufträge keine unterschiedlichen Exemplare des Servlets, sondern lediglich unterschiedliche Threads bei einem Servlet-Exemplar. Aus diesem Grund ist zu bedenken, dass die Dienste seiteneffektfrei sein müssen. Es ist unsere Aufgabe, die Methode so weit zu synchronisieren, dass es keine negativen Auswirkungen der Parallelität gibt. Die Synchronisation wirkt sich natürlich auf die Ausführungsgeschwindigkeit nachteilig aus, sodass auf die passende Granularität zu achten ist.
14.10.5
Servlets und Sessions
JSP gehören ganz automatisch zu einer Sitzung. Bei Servlets ist dies nicht der Fall. Wir benötigen also eine Möglichkeit, die uns Zugriff auf die Sitzung gibt. Das ist die Methode getSession() in dem aktuellen HttpServletRequest-Objekt. Sie liefert null, wenn noch keine Sitzung verwaltet wird, da der Client zum ersten Mal auf ein Servlet zugreift. Wenn der Client zum ersten Mal zugreift, müssen wir dies erkennen und automatisch ein Sitzungsobjekt initiieren. Für diese Aufgabe gibt es eine Abkürzung, die wie folgt aussieht: public void doGet( HttpServletRequest request, HttpServletResponse response ) throws ServletException, IOException { HttpSession session = request.getSession( true ); ... out = response.getWriter(); ... }
Wir müssen also nicht request.getSession() != null überprüfen und dann manuell ein Sitzungsobjekt aufbauen, sondern können getSession(true) nutzen, das automatisch eine HttpSession anlegt.
1118
14.10
Servlets
interface javax.servlet.http.HttpServletRequest extends ServletRequest Þ HttpSession getSession()
Liefert die aktuelle Session, die mit der Anfrage assoziiert ist. Wenn es keine Session gab, wird automatisch eine angelegt. Þ HttpSession getSession(boolean create)
Wie getSession(), nur dass getSession(false) nicht automatisch eine neue Session anlegt, wenn es keine mit der Sitzung assoziierte gibt.
14.10.6
Weiterleiten und Einbinden von Servlet-Inhalten
Mit einem RequestDispatcher-Objekt kann sich ein Servlet zu einem anderen Servlet verbinden, oder es können Ausgaben von anderen Servlets in den aktuellen Datenstrom mit eingebunden werden. Die angebotenen Methoden vom Dispatcher sind include() und forward(). Um an den aktuellen RequestDispatcher zu gelangen, wird die Methode getServletDispatcher() aufgerufen, die eine Methode der Klasse ServletContext ist. Die Webseite, die eingebunden ist oder an die weitergeleitet wird, ist durch eine URL spezifiziert, die die Methode getServletDispatcher() als Argument bekommt. Den Methoden forward() und include() werden dann request und response übergeben. Ein Servlet soll eine einfache Fußzeile generieren, die ein anderes Servlet einbindet: public class FooterServlet extends HttpServlet { public void service( HttpServletRequest request, HttpServletResponse response ) throws ServletException, IOException { response.setContentType( "text/html" ); PrintWriter out = response.getWriter(); out.println( "Copyright © 2012" ); } }
Damit ein zweites Servlet die Ausgabe einbinden kann, inkludieren wir seine Ausgabe. Konzentrieren wir uns auf die service()-Methode: public void service( HttpServletRequest request, HttpServletResponse response ) throws ServletException, IOException
1119
14
14
JavaServer Pages und Servlets
{ response.setContentType( "text/html" ); PrintWriter out = response.getWriter(); ServletContext con = getServletContext(); out.println( "Der Telefonmann meldet sich wieder" ); RequestDispatcher rq = con.getRequestDispatcher( "FooterServlet" ); rq.include( request, response ); } interface javax.servlet.RequestDispatcher Þ void forward(ServletRequest request,ServletResponse response)
throws ServletException, IOException
Die Anfrage wird an ein anderes Servlet, eine andere JSP oder eine andere HTML-Seite weitergeleitet. Eine ServletException kann auftreten, wenn das Ziel eine Ausnahme auslöst. Þ void include(ServletRequest request,ServletResponse response)
throws ServletException, IOException
Bindet den Inhalt eines Servlets, einer JSP oder einer Webseite in den aktuellen Datenstrom (»response«) ein. Das ServletResponse-Objekt kann keinen Header setzen (um zum Beispiel den Statuscode zu ändern). Änderungen werden ignoriert.
14.11
Zum Weiterlesen
Zum Thema Webtechnologien hat Oracle viel auf den Webseiten http://java.sun.com/ products/jsp/ und http://www.oracle.com/technetwork/java/index-jsp-135475.html veröffentlicht. Allerdings reicht das Wissen nicht aus, um wirklich moderne Webapplikationen zu entwickeln. Vielmehr sind JSP und Servlets die Basis jeder HTTP-getriebenen Anwendung. Tag-Libraries sind die Gewürze, die JSPs erst richtig schmackhaft machen. Servlets dienen (neben der seltenen Generierung von binären Dokumenten) lediglich dazu, als Front-Controller (http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html) Anfragen vom Client entgegenzunehmen und an die Ansicht weiterzuleiten. Diese Weiterleitung selbst zu schreiben, erübrigt sich mit der Masse an MVC-Frameworks; die Notwendigkeit beschreibt das Dokument »Designing Enterprise Applications« (http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html). Als Standard-Framework hat sich JavaServer Faces (http://www.oracle.com/technetwork/java/javaee/javaserverfaces139869.html) herauskristallisiert. Webanwendungen nur mit einem einfachen Editor zu schreiben, ist aufwändig und fehlerträchtig. Entwickler-Teams sollten sich von Tools unter die Arme greifen lassen, um zum Bei-
1120
14.11
Zum Weiterlesen
spiel den Pageflow visuell zu modellieren und die Konfigurationsdateien schnell über Wizards zu generieren. Im Eclipse-Umfeld macht das JavaServer Faces Tooling Project (http:// www.eclipse.org/webtools/jsf/), das ein Teil vom WTP ist, eine gute Figur. Webanwendungen wirken auf den ersten Blick – mit einigen Klicks – so, als wären sie leicht zu entwickeln, sind aber bei genauerem Hinsehen in puncto Lastverteilung/Clustering (Tomcats Clustering wird immer besser) und Ausfallsicherheit bei großen Sites mit Sicherheit nicht trivial. Besonders die Sicherheit (Web Application Security) vernachlässigen Entwickler gern bis zum Schluss, um dann Teile, wie unzureichend geprüfte Eingaben oder Authentifizierung, anpassen zu müssen. Peinlich war zum Beispiel die Situation für die Firma Gateway, die jedem registrierten Benutzer eine sechsstellige ID zuwies und als Identifizierung an den Server schickte. Natürlich war es kein großes Problem, diese ID anders zu generieren und Informationen anderer Benutzer abzurufen. Der zeitlose Report »The Ten Most Critical Web Application Security Vulnerabilities« (http://prdownloads.sourceforge.net/owasp/OWASPTopTen2004.pdf) sensibilisiert für die Problematik. Injizierungsfehler (wie SQL-Injection, mit Beispielen etwa unter http:// www.unixwiz.net/techtips/sql-injection.html beschrieben) und Cross-Site-Scripting (http:// de.wikipedia.org/wiki/Cross-Site_Scripting) sind mittlerweile Fehler-Klassiker, die es zu vermeiden gilt.
14
1121
Kapitel 15 Applets »Mode ist, was man selbst trägt. Altmodisch ist, was die anderen tragen.« – Oscar Wilde (1854–1900)
Applets sind kleine Java-Programme, die in einem Webbrowser ablaufen. Sie gehören zu den Java-Programmen der ersten Stunde. Referenziert eine Web-Seite ein Applet, so startet der Browser eine virtuelle Maschine und führt das Applet aus.
15.1
Applets in der Wiege von Java 15
Haben sich in den Anfangsjahren die Browser-Hersteller selbst darum gekümmert, die Applets in ihren Browsern um Laufen zu bringen, hat sich das heute gewandelt. Oracle liefert die Java Plug-In Technology (kurz Java Plug-In) aus, was die Browser bei der Ausführung von Applets auf den gleichen Stand bringt. Das hat den Vorteil, dass die Java-Technologie auch zum Internet Explorer kommt, da ja Microsoft seine JVM nicht mehr aktualisiert. (Microsoft lieferte für Windows XP immerhin noch eine eigene JVM aus, obwohl sie auf dem Stand von Java 1.1 stehen blieb, aber XP ist ja auch nicht mehr Stand der Dinge.) Früher lief die virtuelle Maschine im Browser selbst, in neuen Java-Versionen läuft die Java-Anwendung in einem eigenen Prozess.
15.1.1
Applets heute
Obwohl Applets Java an die Spitze der Programmiersprachen brachten, sind sie heute nur noch selten zu sehen. Es gibt zwar Ausnahmen, wie den Routenplaner http://www. de.map24.com/ oder diverse Aktien-Chart-Analysen, doch im Allgemeinen sind Applets von öffentlichen Webseiten weitestgehend verschwunden. Der Grund, warum Java-Applets weniger attraktiv für den Konsumenten sind, liegt nicht darin, dass die clientseitige Darstellung und Logik unwichtig geworden ist, sondern vielmehr an anderen Gründen:
1123
15
Applets
Þ Mit HTML, CSS sowie JavaScript lassen sich heutzutage viele Aufgaben lösen, die 1995 un-
lösbar waren. Dagegen wirken compilierte Java-Programme nicht gerade wie Raketentechnik. Während bei Java-Applets erst eine JVM gestartet werden muss, was natürlich eine gewisse Zeit kostet, sind JavaScript und HTML sofort bereit. Starke JavaScript-Bibliotheken ermöglichen tolle Effekte und mit performanten JavaScript-Engines wie der quelloffenen V8 von Google oder TraceMonkey der Mozilla Foundation eine schnelle Verarbeitung. Þ Java ist als allgemeine Programmiersprache entworfen worden, aber nicht als einfache Pro-
grammiersprache für grafische Effekte. Hier liegt der Vorteil von Adobe Flash oder auch Microsoft Silverlight. Mit starken Tools können Designer großartige Oberflächen entwerfen, und die Verbreitung des Flash-Players ist phänomenal.1 Zudem erweitert Adobe die Multimedia-Technologie Flash, die Programmiersprache ActionScript sowie die Produktpalette zur Entwicklung kontinuierlich. Oracle versucht mit der Plattform JavaFX (http:// www.oracle.com/technetwork/java/javafx/overview/index.html) dagegenzusetzen, aber JavaFX kann wohl eher Swing für Rich-Clients ablösen und wird wohl im Internet ein Exot bleiben. Þ Ist Java installiert, steht auf den Rechnern eine moderne und schnelle Java-Laufzeitumge-
bung für Applets über ein Browser-Plugin zur Verfügung. Das Problem beginnt aber, wenn Anwender Applets nutzen möchten (oder müssen), aber kein JVM installiert ist. HTML, CSS und JavaScript sind immer Teil des Browsers, und in der Regel ist auch Flash installiert. Dagegen ist der Bezug einer JVM langwierig, und viele Megabyte Daten müssen vom OracleServer geladen werden. (Microsoft lieferte zwar früher für den IE eine JVM mit, doch wegen immer wieder auftretender Sicherheitsprobleme sollten Anwender Microsofts JVM deinstallieren. Microsoft liefert für Vista kein Java mit aus, und daher muss sowieso Oracles JVM installiert werden.2)
Hinweis Wir wollen im Folgenden davon ausgehen, dass nicht die Java-Laufzeitumgebung 1.1 von Microsoft installiert ist, sondern ein vollwertiges Java von Oracle. Ist Oracles JVM installiert, ersetzt sie – falls diese installiert war – die JVM von Microsoft, und aktuelle Java-Programme lassen sich ausführen.
15.1.2
(J)Applet und Applikationen
Verfügen normale Applikationen, die von der Kommandozeile gestartet werden, über eine statische main()-Methode, ist das bei Applets anders. Sie erweitern zwingend die Klasse 1
http://www.adobe.com/products/player_census/flashplayer/version_penetration.html
2
http://windowshelp.microsoft.com/Windows/en-US/Help/59c3a93d-1342-43a6-a01a-f720c7a17ffc1033.mspx
1124
15.1
Applets in der Wiege von Java
javax.swing.JApplet oder java.applet.Applet und implementieren Callback-Methoden statt
einer main()-Methode. (Hybride Programme, die sowohl Applikation als auch Applet sind, sind ebenfalls möglich. Diese Sorte Programm erweitert einfach die Klasse (J)Applet und implementiert eine statische main()-Methode.) Ein Applet unterliegt hohen Sicherheitsbestimmungen – eine auf dem Client-Rechner liegende Datei kann zum Beispiel nicht gelöscht werden, und schon der lesende Zugriff ist unzulässig. Vom Sicherheitsstandpunkt aus betrachtet, kontrolliert der SecurityManager die Handlungen der Software.
15.1.3
Das erste Hallo-Applet
Ein Programm wird leicht zu einem Applet, wenn es die Klasse Applet erweitert. Als Einstieg soll ein kleines Beispiel-Applet dienen. Listing 15.1: HelloWorldApplet.java import java.applet.Applet; import java.awt.Graphics;
15
public class HelloWorldApplet extends Applet { /* @Override */ public void paint( Graphics g ) { g.drawString( "Hallo Welt!", 50, 25 ); } }
Die beiden ersten import-Anweisungen binden die notwendigen Informationen über Applets und über Zeichenmethoden ein. Das HelloWorldApplet erweitert die Klasse Applet, denn so wird ein Applet erzeugt. Eine statische main()-Methode kommt nicht vor, und es muss eine Methode paint() überschrieben werden, die den Bildschirmaufbau übernimmt.3 Der Webbrowser oder Applet-Viewer ruft diese Methode per Callback auf.
3
Das gilt nicht für JApplet. Dort ist das Überschreiben von paint() oder paintComponent() unüblich, da im Allgemeinen eine eigene, sich zeichnende Komponente auf das JApplet gesetzt wird.
1125
15
Applets
Abbildung 15.1: Das erste Applet im Browser
Damit der Viewer weiß, was zu machen ist, gibt der HTML-Code einen Hinweis auf die Klasse, die in die Seite eingebettet wird. Dies wird über ein spezielles Tag erreicht. Listing 15.2: index.html
Neben dem Namen der Klasse übermittelt das Applet-Tag der virtuellen Maschine auch die Maße des Fensters, in dem das Applet zeichnen kann. Ab Java 1.1 lassen sich gepackte Dateien im Jar-Format übermitteln. Die Angabe der Klasse in der Code-Anweisung sollte keine Leerzeichen beinhalten. Die Endung .class ist nicht in jedem Browser erforderlich, wird aber empfohlen.
Abbildung 15.2: UML-Diagramm von Applet und AppletContext
1126
15.2
Die Applet-API
Fehler in Applets finden Werden Applets vom Browser nicht ausgeführt, weil es Fehler in unserem Programm gibt, so bietet die Java Console (http://www.java.com/en/download/help/javaconsole.xml) die Möglichkeit, Log-Informationen anzusehen und so die Fehler genauer zu studieren.
15.2
Die Applet-API
15.2.1
Die Zyklen eines Applets
Beim Start eines Applets werden unterschiedliche Methoden vom Browser automatisch aufgerufen. Es beginnt mit dem Aufruf der Methode init(). Dort sollten Initialisierungen erfolgen. init() wird nur einmal aufgerufen, wenn die Seite vom Browser geladen wird. Nach der Initialisierung folgt ein Wechsel der Methoden start() und stop() immer dann, wenn ein Applet im Browser sichtbar ist oder von der Seite verschwindet, etwa wenn der Anwender über die Schieberegler einen anderen Bereich auswählt, in dem das Applet nicht liegt. Beim Verlassen der Seite wird abschließend destroy() aufgerufen. Dort können Ressourcen freigegeben werden.
15 15.2.2
Parameter an das Applet übergeben
Dem Applet können Parameter im Applet-Tag übergeben werden. Dazu wird im -Element ein -Element eingebettet. Im Folgenden zeichnet ein Applet einen grünen oder roten Kasten, in Abhängigkeit davon, ob eine URL korrekt aufgebaut ist.
Abbildung 15.3: Unsere Beispielanwendung appletCheckUrl.html Listing 15.3: appletCheckUrl.html
Java-Seminare
1127
15
Applets
Java-Seminare Falsch
Das Applet nimmt den Parameter an und prüft den gültigen Aufbau der URL über eine MalformedURLException. Listing 15.4: CheckUrlApplet.java import java.applet.Applet; import java.awt.Color; import java.awt.Graphics; import java.net.MalformedURLException; import java.net.URL; public class CheckUrlApplet extends Applet { private boolean urlOk = false; @Override public void init() { try { urlOk = new URL( getParameter("url" ) ) != null; } catch ( MalformedURLException e ) { /* urlOk is false */ } } @Override public void paint( Graphics g ) { g.setColor( urlOk ? Color.GREEN : Color.RED ); g.fillRect( 0, 0, 10, 10 ); } }
Interessant wäre natürlich, wenn das Applet gleich die URL auf Erreichbarkeit prüfen würde. Relativ einfach ergeben sich dann folgende Zeilen:
1128
15.2
Die Applet-API
try { urlOk = ((HttpURLConnection)new URL( getParameter("url" ) ). openConnection()).getResponseCode() == HttpURLConnection.HTTP_OK; } catch ( IOException e ) { /* urlOk is false */ }
Doch bei der Prüfung von üblichen Links kommt es zu einem Fehler! Aus Sicherheitsgründen kann ein Applet nur auf den Rechner zugreifen, von dem es geladen wurde, nicht auf andere. Ohne explizite Sicherheitserweiterungen kann so ein allgemeines Applet zum Prüfen eines Links nicht geschrieben werden.
15.2.3
Wie das Applet den Browser-Inhalt ändern kann *
Das Applet kann mit showDocument() auf den Inhalt der Seite Einfluss nehmen. So lassen sich Applets bauen, die eine Baumstruktur der Seite anzeigen und dann zum Inhalt verweisen, falls eine Seite ausgewählt wird. Verwendet werden hier die Methoden von AppletContext. In Kurzform: getAppletContext().showDocument( new URL("http://tutego.com/") );
Oder, falls ein spezieller Frame mit Namen angesprochen ist:
15
getAppletContext().showDocument( new URL("http://tutego.org"), "Framename" ); class java.applet.Applet extends Panel Þ AppletContext getAppletContext()
Liefert den Kontext des Applets. Dieser Kontext erlaubt es dem Applet herauszufinden, in welcher Umgebung, also auf welcher Web-Seite, es sich bewegt. interface java.applet.AppletContext Þ void showDocument(URL url)
Ersetzt den Inhalt auf der aktuellen Seite durch eine neue Seite von der angegebenen URL. Þ void showDocument(URL url, String target)
Ersetzt den Inhalt auf der aktuellen Seite durch eine neue Seite von der angegebenen URL. Dabei wird das Dokument in einem Frame abgelegt, dessen Name zusätzlich festgelegt ist. Für target sind erlaubt: _self (Seite, die das Applet enthält), _parent (bettet die neue Seite in die Vaterseite des Applets ein; falls diese nicht existiert, verhält es sich wie _self), _top (im Top-Level-Frame anzeigen; falls dieser nicht existiert, wie _self), _blank (erzeugt ein neues Fenster), und wenn der Name nicht mit den Konstanten übereinstimmt, wird die Anzeige in einen Frame gelegt, der diesen Namen trägt.
1129
15
Applets
15.2.4
Den Ursprung des Applets erfragen
Greift ein Applet auf Daten des Servers zu und ist ihm die Adresse nicht bekannt, so kann es nachfragen. Die Applet-Klasse stellt die Methoden getCodeBase() und getDocumentBase() zur Verfügung. class java.applet.Applet extends Panel Þ URL getCodeBase()
Liefert die Basis-URL des Applets. Þ URL getDocumentBase()
Liefert die URL der Webseite, die das Applet enthält. Auf dem URL-Objekt liefert getHost() eine String-Repräsentation der URL. So kommen wir mit der Methode getCodeBase().getHost() an den Hostnamen und auch an die Daten des Servers.
Beispiel Applets können problemlos von Webseiten geklaut werden. Um dem einen Riegel vorzuschieben, können wir verlangen, dass die Zeichenkette von getDocumentBase().getHost() immer die Webseite unseres Servers repräsentiert. String web = getDocumentBase().getHost(); if ( ! "www.tutego.com".equals(web) ) { // hier meckern, dass was nicht stimmt. }
Wir könnten die Überprüfung auch über ein InetAddress-Objekt realisieren. class java.net.URL implements Serializable, Comparable Þ String getHost()
Liefert den Hostnamen des URL-Objekts. Handelt es sich um das »file«-Protokoll, so ist der Rückgabewert ein leerer String.
Beispiel Baue eine URL-Verbindung zu einer Grafikdatei auf. Wir benutzen hier zunächst die Methode getDocumentBase(), um an die URL des Servers zu gelangen, und anschließend den URL-Konstruktor, der uns relativ zur Basisadresse eine Pfadangabe erlaubt.
1130
15.2
Die Applet-API
Beispiel (Forts.) URL u1 = getDocumentBase(); try { URL u2 = new URL( u1, "image.gif" ); ... } catch ( MalformedURLException e ) { ... }
15.2.5
Datenaustausch zwischen Applets *
Sind mehrere Applets auf einer Webseite untergebracht, gibt es Fälle, in denen die Applets Daten austauschen wollen. Zwei Lösungen sind populär: Þ Da alle Applets in einer einzigen JVM laufen, lässt sich über statische Attribute auf die an-
deren Elemente zugreifen. Dies spricht jedoch gegen die Datenkapselung und ist sehr unfein. Diese Technik hat einen weiteren Schwachpunkt: Statische Variablen hängen eng mit dem Klassenlader zusammen, und hier traten in der Vergangenheit bei einigen Browsern Probleme auf. Þ Eleganter ist da schon die Möglichkeit über die Schnittstelle AppletContext, die es ermög-
licht, einen Verweis auf das Applet über den Namen zu bekommen. class java.applet.Applet extends Panel Þ AppletContext getAppletContext()
Bestimmt die Umgebung eines Applets.
Applets über den AppletContext erfragen Mit dem AppletContext gibt es zwei Möglichkeiten, an das Applet zu gelangen: Þ das Applet über einen Namen ansprechen Þ eine Aufzählung aller Applets erfragen
Um einen Namen zu vergeben, wird das name-Attribut im -Tag genutzt, etwa so:
1131
15
15
Applets
Eine Verbindung der Methoden getAppletContext() aus Applet und getApplet() aus AppletContext führt zu folgender Zeile: Applet anotherApplet = applet.getAppletContext().getApplet( "applet" );
Die zweite Variante war, sich mit getApplets() eine Enumeration aller Applets einer Seite zu besorgen: Applet otherApplet = null; Enumeration applets = getAppletContext.getApplets(); while ( applets.hasMoreElements() ) { otherApplet = (Applet) applets.nextElement(); if ( otherApplet != this ) break; // Jetzt können wir etwas mit dem anderen Applet machen // if ( otherApplet instanceof Applet2 ) //
...
} interface java.applet.AppletContext Þ Applet getApplet(String name)
Sucht das Applet namens name in dem Dokument, das durch den AppletContext gegeben ist. Der Name kann durch das HTML-Tag gesetzt sein. Falls kein Applet dieses Namens existiert, liefert die Methode null. Þ Enumeration getApplets()
Findet alle Applets, die durch AppletContext angegeben sind.
Praktische Kommunikation Das Applet können wir gegebenenfalls in eine Unterklasse casten. Dann lassen sich alle Methoden aufrufen und die Variablen auslesen. Leider funktionieren beide vorgestellten Methoden nur, wenn die Applets in dem gleichen Frame liegen. Liegen sie in verschiedenen Frames, findet zumindest die Netscape-Methode getApplet() das Applet leider nicht. Hier bleibt aber noch die Variante über statische Variablen übrig. Eine weitere Möglichkeit, Applets über verschiedene Frames kommunizieren zu lassen, führt über eine JavaScript-Funktion. Sie fungiert als Brücke, was etwa so aussieht: top.frames[1].document.applet["applet"].method().
1132
15.2
Die Applet-API
Das folgende Beispiel zeigt zwei Applets, Applet1 und Applet2, auf einer Webseite. Zunächst der HTML-Code: Listing 15.5: TwoAppletsCommunication.html
Es folgen die Implementierungen für die beiden Applets: Listing 15.6: Applet1.java import java.applet.Applet; import java.awt.*; public class Applet1 extends Applet
15
{ private TextField inputText = new TextField( "", 10 ); public void init() { add( inputText ); add( new Button( "Sende an Applet2" ) ); } public boolean action( Event ev, Object arg ) { if ( ev.target instanceof Button ) { Applet2 applet2 = (Applet2) getAppletContext().getApplet( "applet2" ); if ( applet2 != null ) { applet2.appendTheText( inputText.getText().trim() ); return true;
1133
15
Applets
} } return false; } } Listing 15.7: Applet2.java import java.applet.Applet; import java.awt.TextArea; public class Applet2 extends Applet { private TextArea textBox = new TextArea( 5, 40 ); public void init() { add( textBox ); } public void appendTheText( String s ) { textBox.append( s + "\n" ); } }
Da bei verschiedenen Frames getAppletContext() jedoch das andere Applet nicht zurückgeben muss, bleibt nur noch die Variante über die statische Variable. Glücklicherweise lassen sich mit Beobachtermustern aus auch elegante Benachrichtigungen realisieren.
15.2.6
Was ein Applet alles darf *
Ein Applet unterliegt bestimmten Sicherheitsbeschränkungen, die eine Java-Security-Einheit überprüft. In Kapitel 23, »Sicherheitskonzepte«, werden wir diese näher beleuchten. Viele der bekannten Fehler in Java, die potenzielle Sicherheitslücken darstellen, sind mittlerweile behoben. Schon das Auffinden setzt eine gründliche Kenntnis der Java-Quelltexte voraus, beispielsweise der Fehler mit der Host-Adresse: Wenn ein Benutzer ein Applet von tutego.com liest, darf dieses Applet nur mit diesem Host eine Verbindung aufbauen und mit
1134
15.2
Die Applet-API
keinem anderen. Doch leider gab es in den Quelltexten von Java einen Fehler, sodass das Applet nur den Rechnernamen des Hosts vergleicht, nicht aber die IP-Adresse. Ein bösartiges Applet kann nun dem DNS (Domain Name Server) eine falsche Zuordnung von Rechnername und IP-Adresse vorspielen, und nun verhält sich tutego.com wie www.ganz-boese.com.
15.2.7
Ist Java im Browser aktiviert? *
Wenn unser Browser Java-Applets ausführen soll, aber Java gar nicht aktiviert ist, dann lassen sich einige interaktive Benutzeraktionen nicht durchführen. Wir sollten daher zumindest eine Meldung anbieten, dass der Browser Java gerade nicht aktiviert hat. Dies kann beabsichtigt oder nicht beabsichtigt sein. Natürlich kommt Java dafür nicht infrage, aber eine SkriptSprache mit einem ähnlichen Namen: JavaScript. Ab JavaScript-Version 1.1 bietet uns der Interpreter die Funktion javaEnabled() an, sodass wir eine Weiterschaltung vornehmen können: if ( !navigator.javaEnabled() ) { self.location.href = "nix_mit_java.html"; }
Für diese Lösung muss natürlich JavaScript aktiviert sein. Für einige Surfer ist selbst dies schon eine Sicherheitslücke, und wenn JavaScript deaktiviert ist, lässt sich hier nichts mehr machen. Falls JavaScript aktiviert ist, kommen wir dem Benutzer einen Schritt entgegen, sodass er nicht mehr manuell angeben muss, ob Java aktiv ist oder nicht. Von dieser Technik sollten wir auch Gebrauch machen, denn nicht immer hat der Benutzer bewusst Java abgeschaltet. Im Beispiel oben haben wir eine Seite angesteuert, wobei natürlich andere Anweisungen denkbar sind. Doch diese Form ist sinnvoll, denn wir können Benutzern eine Kurzbeschreibung darüber liefern, wie Java im Browser aktiviert wird. Zusammen mit der Browservariante ist eine browsergenaue Beschreibung einsetzbar.
15.2.8
Applet unter Firefox (Netscape) oder Microsoft Internet Explorer? *
Kann der Browser ein Applet aus irgendwelchen Gründen nicht ausführen, so sind die Meldungen an den Benutzer meist mager. Oft beschränken sie sich auf eine Exception-Angabe in der Statuszeile. Dies mag keiner mehr sehen. Doch leider verschärfen inkompatible Browser die Situation. Was hier Abhilfe schafft, ist ein kleines Programm, das zunächst herausfindet, auf welchem Browser das Applet läuft. Dann können unter Umständen browser- und versionsabhängige Varianten ausgeführt werden. Wir verwenden einen Trick, der auch beim Erkennen von Prozessortypen angewendet wird: Wir versuchen, Klassen zu laden oder Methoden aufzurufen, die es für den jeweils anderen
1135
15
15
Applets
Browser nicht gibt. Der Internet Explorer hat zum Beispiel eine private Klasse com.ms. applet.GenericAppletContext, und Mozilla hat eine Klasse netscape.applet.MozillaAppletContext. Löst die JVM beim Laden der Klasse eine Exception aus, wissen wir Bescheid, um welchen Browser es sich handelt. Versuchen wir, über die selbst gebastelten Methoden isNetscape() und isMicrosoft() etwas über unsere Laufzeitumgebung herauszufinden. Listing 15.8: BrowserDetector.java import java.applet.Applet; public class BrowserDetector extends Applet { public void init() { if ( isNetscape() ) System.out.println( "Netscape, Firefox, ... Browser." ); if ( isMicrosoft() ) System.out.println( "Microsoft Browser." ); } public static boolean isNetscape() { try { Class.forName( "netscape.applet.MozillaAppletContext" ); } catch ( ClassNotFoundException e ) { return false; } return true; } public static boolean isMicrosoft() { try { Class.forName( "com.ms.applet.GenericAppletContext" ); } catch ( ClassNotFoundException e ) { return false; } return true; } }
1136
15.3
Webstart
Die Idee lässt sich natürlich auch anwenden, um Java-Versionen zu testen; es wird einfach eine Klasse erfragt, die bei einer neuen Java-Version hinzugekommen ist, bei Java 2 etwa Point2D.
Tipp Da nicht immer sichergestellt sein kann, dass Java in einer vernünftigen Version (>= 1.2) auf dem Client-Rechner der Benutzer installiert ist, lässt sich ein Test-Applet vorschalten, das zunächst die Java-Version prüft. Anschließend kann dieses Eingangs-Applet über getAppletContext().showDocument() auf eine andere Seite mit einem Applet verweisen. Für unterschiedliche Browser und Java-Installationen können somit unterschiedliche Applets auf die Situation eingehen.
15.3
Webstart
Bevor Software auf dem Rechner läuft, wird sie in der Regel installiert. Dazu legen die Hersteller der Software ein spezielles Installationsprogramm bei – unter Windows oft die InstallShields. Das Installationsprogramm legt passende Verzeichnisse an und initialisiert etwa die Registrierdatenbank unter Windows. Etwas anders sieht das bei Java-Programmen aus. Die Installation erfordert zuerst eine Java-Laufzeitumgebung. Anschließend kann das Programm entpackt und gestartet werden. Wünschenswert ist jedoch eine Art Umgebung, wie sie bei Java-Applets definiert ist. Ein Java-Applet läuft innerhalb eines Browsers in einem speziellen Sicherheitsmodus, und es wäre günstig, wenn dies auch für alle anderen Applikationen möglich wäre. Das bedeutet: Eine beliebige Applikation kann von einer Webseite geladen und auf dem lokalen Rechner ausgeführt werden. Die Applikation soll sich nicht von anderen Applikationen unterscheiden, die lokal installiert sind. Damit der Start möglich ist, ist die Oracle-Technologie Webstart nötig. Webstart deckt die Bereiche Installation, Start und Update durch ein eigenes Protokoll ab, das Java Network Launcher Protocol (JNLP). Die Technologie wurde auf der JavaOne 2000 erstmals vorgestellt. Neben der offiziellen Webseite widmet sich auch die (nicht mehr ganz so frische) Unofficial Java Web Start/JNLP FAQ unter http://lopica.sourceforge.net/faq.html dem Thema.
15.4
Zum Weiterlesen
Erstaunlicherweise gab es unter Java 6 Update 10 noch größere Änderungen in der AppletProgrammierung. So können Applets mittlerweile aus Web-Seiten herausgezogen werden,
1137
15
15
Applets
und Applets können problemlos den DOM-Baum der Seite modifizieren, in der sie laufen. Mehr Informationen zu diesen Themen gibt es in Oracles Java-Tutorial unter http://download.oracle.com/javase/tutorial/deployment/applet/index.html. Es gibt auch von Oracle eine JavaScript-API, die das korrekte HTML für ein Applet generiert, sodass Entwickler nicht das eigentlich veraltete nutzen müssen – Weiteres dazu unter http://download.oracle.com/ javase/6/docs/technotes/guides/jweb/deployment_advice.html#deplToolkit.
1138
Kapitel 16 Datenbankmanagement mit JDBC »Alle Entwicklung ist bis jetzt nichts weiter als ein Taumeln von einem Irrtum in den anderen.« – Henrik Ibsen (1828–1906)
Das Sammeln, Zugreifen auf und Verwalten von Informationen ist im »Informationszeitalter« für die Wirtschaft eine der zentralen Säulen. Während früher Informationen auf Papier gebracht wurden, bietet die EDV hierfür Datenbankverwaltungssysteme (DBMS, engl. database management systems) an. Diese arbeiten auf einer Datenbasis, also auf Informationseinheiten, die miteinander in Beziehung stehen. Die Programme, die die Datenbasis kontrollieren, bilden die zweite Hälfte der DBMS. Die Netzwerk- oder hierarchischen Datenmodelle sind mittlerweile den relationalen Modellen – kurz gesagt, Tabellen, die miteinander in Beziehung stehen – gewichen. Mittlerweile gibt es neben den relationalen Modellen auch andere Speicherformen für Datenbanken. Immer populärer werden objektorientierte Datenbanken und XML-Datenbanken. Auch mit ihnen werden wir uns kurz beschäftigen.
16.1
Relationale Datenbanken
16.1.1
Das relationale Modell
Die Grundlage für relationale Datenbanken sind Tabellen mit ihren Spalten und Zeilen. In der Vertikalen sind die Spalten und in der Horizontalen die Zeilen angegeben. Eine Zeile (auch Tupel genannt) entspricht einem Element einer Tabelle, eine Spalte (auch Attribut genannt) einem Eintrag einer Tabelle.
1139
16
16
Datenbankmanagement mit JDBC
Lfr_Code
Lfr_Name
Adresse
Wohnort
004
Hoven G. H.
Sandweg 50
Linz
009
Baumgarten R.
Tankstraße 23
Hannover
011
Strauch GmbH
Beerenweg 34a
Linz
013
Spitzmann
Hintergarten 9
Aalen
...
...
...
...
Tabelle 16.1: Eine Beispieltabelle
Jede Tabelle entspricht einer logischen Sicht des Benutzers. Die Zeilen einer Relation stellen die Datenbankausprägung dar, während das Datenbankschema die Struktur der Tabelle – also Anzahl, Name und Typ der Spalten – beschreibt. Wenn wir nun auf diese Tabellen Zugriff erhalten wollen, um damit die Datenbankausprägung zu erfahren, benötigen wir Abfragemöglichkeiten. Java erlaubt mit JDBC den Zugriff auf relationale Datenbanken.
16.2
Datenbanken und Tools
Vor dem Glück, eine Datenbank in Java ansprechen zu können, steht die Inbetriebnahme des Datenbanksystems (für dieses Kapitel ist das fast schon der schwierigste Teil). Nun gibt es eine große Anzahl von Datenbanken – manche sind frei und Open Source, manche sehr teuer –, sodass sich dieses Tutorial nur auf eine Datenbank beschränkt. Das Rennen macht in dieser Auflage die pure Java-Datenbank HSQLDB, die sehr leicht ohne Administratorrechte läuft und leistungsfähig genug ist. Da JDBC aber von Datenbanken abstrahiert, ist der Java-Programmcode natürlich auf jeder Datenbank lauffähig.
Hinweis Ab dem JDK 6 ist im Unterverzeichnis db, also etwa C:\Program Files\Java\jdk1.6.0\db, die Datenbank Java DB (http://developers.sun.com/javadb/) integriert. Sie basiert auf Apache Derby, dem früheren Cloudscape von IBM.
1140
16.2
16.2.1
Datenbanken und Tools
HSQLDB
HSQLDB (http://hsqldb.org/) ist ein pures Java-RDBMS unter der freien BSD-Lizenz. Die Datenbank lässt sich in zwei Modi fahren: als eingebettetes Datenbanksystem und als Netzwerkserver. Im Fall eines eingebauten Datenbanksystems ist lediglich die Treiberklasse zu laden und die Datenbank zu bestimmen, und schon geht’s los. Wir werden für die folgenden Beispiele diese Variante wählen. Auf der Download-Seite http://sourceforge.net/projects/hsqldb/files/ von SourceForge befindet sich ein Archiv wie hsqldb-2.2.5.zip (8,2 MiB), das wir auspacken, zum Beispiel nach c:\Programme\hsqldb. Unter C:\Programme\hsqldb\bin\ befindet sich ein Skript runManagerSwing.bat, das ein kleines Datenbank-Frontend öffnet. Im folgenden Dialog Connect setzen wir 1. den Typ auf HSQL Database Engine Standalone und 2. die JDBC-URL auf jdbc:hsqldb:file:c:\TutegoDB (statt c:\TutegoDB einen anderen Pfad eintragen, wohin die Datenbank erzeugt werden soll). Der Teil hinter file: gibt also den Pfad zu der Datenbank an, wobei der Pfad relativ oder absolut sein kann. Liegt die Datenbank im EclipseWorkspace, kann später die absolute Angabe entfallen. Existiert die Datenbank nicht, wird sie unter dem angegebenen Pfad angelegt – das machen wir im ersten Schritt –, existiert sie, wird sie zum Bearbeiten geöffnet.
16
Abbildung 16.1: Verbindung aufbauen zur Datenbank
Nach dem Beenden des Dialogs mit OK fügt im Menü Options die Operation Insert Test Data einige Tabellen mit Dummy-Daten ein und führt ein SQL-SELECT aus, das uns den Inhalt der Customer-Tabelle zeigt. Beenden wir anschließend das Swing-Programm mit File 폷 Exit. Im Dateisystem hat der Manager jetzt eine .log-Datei angelegt – zu ihr gesellt sich später noch eine .script-Datei –, eine .properties-Datei und eine .lck-Datei. Für den Datenbankzugriff aus Java ist nur das Archiv hsqldb.jar aus dem lib-Verzeichnis von HSQLDB in den Klassenpfad aufzunehmen.
1141
16
Datenbankmanagement mit JDBC
Abbildung 16.2: SQL-Kommandos absetzen und Resultate einsehen
16.2.2
Weitere Datenbanken *
Die Anzahl der Datenbanken ist zwar groß, aber es gibt immer wieder Standard-Datenbanken und freie Datenbank-Management-Systeme.
MySQL MySQL (http://www.mysql.de/) ist ein häufig eingesetzter freier und schneller Open-SourceDatenbank-Server. Er wird oft im Internet in Zusammenhang mit dynamischen Webseiten eingesetzt; das Zusammenspiel zwischen Linux, Apache, MySQL, PHP (LAMP-System) ist hoch gelobt. Herausragende Eigenschaften sind die Geschwindigkeit und die Bedienbarkeit. Die MySQL-Datenbank spricht der unter der LGPL stehende JDBC-Treiber MySQL Connector/J (http://dev.mysql.com/downloads/connector/j/) an. Nach dem Entpacken muss das Jar-Archiv des Treibers in den Klassenpfad aufgenommen werden. Er unterstützt die JDBC 4.0-API. Sun Microsystems hat im Februar 2008 MySQL übernommen, und heute gehört es zu Oracle.
PostgreSQL Die PostgreSQL-Datenbank (http://www.postgresql.org/) ist ebenfalls quelloffen, läuft auf vielen Architekturen und unterstützt weitgehend den SQL-Standard 92. Gespeicherte Prozeduren, Schnittstellen zu vielen Programmiersprachen, Views und die Unterstützung für Geoinformationssysteme (GIS) haben das unter der BSD-Lizenz stehende PostgreSQL sehr beliebt gemacht. Es gibt JDBC 4-Treiber unter http://jdbc.postgresql.org/.
1142
16.2
Datenbanken und Tools
H2 Die Beispiele im Buch basieren auf der HSQLDB-Datenbank, da sie so schön einfach ist. Eine andere leistungsfähige und einfach einzusetzende pure Java-Datenbank ist H2 (http:// www.h2database.com). Auch sie ist standalone oder eingebettet lauffähig und verfügt gegenüber HSQLDB noch über einige Extra-Features. H2 hat eine schöne Web-Oberfläche zur Konfiguration und für Abfragen und unterstützt alle wichtigen SQL-Eigenschaften wie Trigger, Joins, dazu abgesicherte Verbindungen und Volltextsuche. H2 hält außerdem den Speicherverbrauch klein. Weiterhin lässt sich ein ODBC-Treiber (von PostgreSQL) nutzen, um H2 auch unter Windows-Programmen (etwa Access) als Datenbank zu nutzen.
Oracle Database 10g Express Edition (Oracle Database XE) Um die Verbreitung ihrer Produkte weiter zu erhöhen, ist die Firma Oracle dazu übergegangen, eine vollwertige freie Version zum Download oder als CD anzubieten. Wer den Download nicht scheut, der kann unter http://www.oracle.com/technology/software/products/database/ index.html die Oracle Database XE für Windows, Mac OS X, Linux und weitere Unix-Systeme herunterladen. Die JDBC-Treiber sind auf dem neuen Stand.
DB2 Universal Database Express/DB2 Express-C Von IBM stammt die etwas eingeschränkte, aber freie Version von DB2 mit exzellenter JavaUnterstützung. Unter http://tutego.de/go/db2express lässt sich die Datenbank für Windows und Linux herunterladen.
Microsoft SQL Server und JDBC-Treiber Mit SQL Server 2008 Express (http://www.microsoft.com/express/Database/) bietet Microsoft eine freie Datenbank. Auch für die nicht-freie Version, den Microsoft SQL Server, bietet Microsoft unter http://msdn.microsoft.com/data/ref/jdbc/ einen aktuellen JDBC 3-Treiber. Er benötigt mindestens Java 5 und ist auf verschiedenen Betriebssystemen lauffähig.
Microsoft Access Microsoft Access ist keine freie Software, aber auf vielen Windows-Systemen installiert. Damit lässt sich mit wenigen Handgriffen eine Datenbank zusammenbauen, die dann anschließend über die JDBC-ODBC-Bridge aus Java zugänglich ist. Viele Anwender haben das Office-Paket von Microsoft zu Hause installiert und so schon eine Datenbank zur Verfügung. Eine einfache Datenbank ist schnell gebaut: Nach dem Start von Access erscheint automatisch ein Dialog mit dem Eintrag Leere Access-Datenbank (alternativ lässt sich eine neue Datenbank unter dem Menüpunkt Datei 폷 Neu ... einrichten). Wir wählen den ersten Eintrag
1143
16
16
Datenbankmanagement mit JDBC
Datenbank und speichern die Datenbank unter einem aussagekräftigen Namen. Access benötigen wir nicht mehr direkt, weil die Kommunikation mit der Datenbank anschließend über den ODBC-Manager läuft. Dieser setzt dann auf dem SQL-Kern von Access auf. Im ODBCManager muss dafür die Datenquelle angemeldet werden.
ODBC einrichten und Access damit verwenden Die meisten Datenbanken öffnen einen TCP/IP-Port, und die Programme kommunizieren über ein definiertes Netzwerkprotokoll. Access ist dazu nicht in der Lage, und so muss eine Access-Datenbank als ODBC-Datenquelle bei einer Zentrale angemeldet werden; im nächsten Schritt kommuniziert ein spezieller Java-Datenbanktreiber mit dieser ODBC-Zentrale. Zum Einrichten gehen wir zunächst in die Systemeinstellungen (Start 폷 Einstellungen 폷 Systemsteuerung) und suchen ab Windows 2000 im Verzeichnis Verwaltung nach dem Symbol Datenquellen (ODBC). Nach dem Start öffnet sich ein Dialog mit dem Titel ODBCDatenquellen-Administrator. Wir gehen auf Hinzufügen, um eine neue Benutzer-Datenquelle hinzuzufügen. Im Dialog mit dem Titel Neue Datenquelle erstellen wählen wir den Microsoft Access-Treiber aus und gehen auf Fertigstellen. Ein Dialog öffnet sich, und wir tragen unter Datenquellenname einen Namen für die Datenquelle ein. Unter diesem Namen können wir in Java später die Datenbank ansprechen. Der Name der Datei hat nichts mit dem Namen der Datenquelle gemeinsam. Optional können wir noch eine Beschreibung hinzufügen. Wichtig ist nun die Verbindung zur physikalischen Datenbank. Im umrandeten Bereich Datenbank aktivieren wir über die Schaltfläche Auswählen einen Datei-Selektor. Hier hangeln wir uns bis zur in Access erstellten Datei durch und tragen sie ein. Nun müssen wir nur noch einige Male OK anklicken, und wir sind fertig. Wenn der Administrator nicht meckert, können wir nun ein JDBC-Programm starten.
Abbildung 16.3: Auswählen einer Datenbank
1144
16.2
16.2.3
Datenbanken und Tools
Eclipse-Plugins zum Durchschauen von Datenbanken
Es gibt fast genauso viele Tools zum Administrieren von Datenbanken wie Datenbanken selbst. Zwar bringt NetBeans direkt ein Plugin zum Durchstöbern von Datenbanken mit, doch leider nicht die Eclipse IDE – auch nicht in der Ausgabe Eclipse IDE for Java EE Developers. So muss ein extra Plugin installiert werden. Von der Eclipse-Foundation gibt es Eclipse Data Tools Platform (DTP) und eine Webseite http://www.eclipse.org/datatools/. Frei und in Java (aber kein Eclipse-Plugin) ist SQuirreL (http://squirrel-sql.sourceforge.net/).
Eclipse Data Tools Platform (DTP) Die DTP wird über den Online-Update-Mechanismus installiert. Wir wählen Help 폷 Install New Software... und geben bei work with die URL http://download.eclipse.org/datatools/ updates/ ein. Wir aktivieren Add... und bestätigen den nächsten Dialog mit OK. Es folgt ein Dialog mit Versionen, aus denen wir die letzte DTP-Version auswählen können, etwa Eclipse Data Tools Platform SDK 1.9.0.
16
Abbildung 16.4: Auswählen des DTP-Plugings
1145
16
Datenbankmanagement mit JDBC
Nach ein paar Ja-Next-Dialogen wird Eclipse neu gestartet, und das Plugin ist installiert. Wir wechseln anschließend die Perspektive mit Window 폷 Open Perspective 폷 Other... und wählen dann Database Development. Es gibt in der Perspektive einige neue Ansichten. Eine ist Data Source Explorer, die sich auch durch Window 폷 Show View 폷 Data Source Explorer für andere Perspektiven aktivieren lässt. In der Ansicht wählen wir im Zweig Database Connections über das Kontextmenü den Eintrag New... So lässt sich eine neue Datenbankverbindung einrichten. Im folgenden Dialog wählen wir HSQLDB aus der Liste. Next bringt uns zu einem neuen Dialog. Rechts neben dem Auswahlfeld bei Drivers ist eine unscheinbare Schaltfläche mit einem Kreis und +-Symbol.
Abbildung 16.5: Treiberdetails bestimmen
Nach dem Aktivieren öffnet sich ein weiterer Dialog mit dem Titel New Driver Definition. Aus der Liste wählen wir unter Database den HSQLB JDBC Driver aus und gehen auf den zweiten Reiter, auf Jar List. Mit Add JAR/Zip... kommt ein Auswahldialog, und wir navigieren zu hsqldb.jar.
Abbildung 16.6: Jar-Datei auswählen
1146
16.2
Datenbanken und Tools
Nach diesem Eintrag aktivieren wir den dritten Reiter, Properties. Wir tragen Folgendes ein: Þ Connection URL: die JDBC-URL für die angelegte Datenbank, etwa jdbc:hsqldb:file:c:/Tu-
tegoDB Þ Database Name: ein beliebiger Name, der nur zur Anzeige dient, etwa tutegoDB Þ Driver Class: die Treiberklasse org.hsqldb.jdbcDriver Þ Unter User ID tragen wir »sa« ein.
16 Abbildung 16.7: Verbindungsdaten eintragen
Mit Ok bestätigen wir den Dialog, und anschließend sollte der Klick auf die Schaltfläche Test Connection bezeugen, dass alles gut geht und es keine Probleme mit den Parametern gab. Finish schließt den Dialog, und nach einer erfolgreichen Verbindung sind in der Ansicht die Datenbank sowie ihre Schemas zu sehen. Um eine SQL-Abfrage auszuführen, öffnen wir den Dialog unter File 폷 New 폷 Other... 폷 SQL Development 폷 SQL File, klicken auf Next und geben einen Dateinamen wie test für eine Skriptdatei an. Im unteren Bereich des Dialogs lässt sich direkt die Datenbank auswählen. Wählen wir für Database server type den Eintrag HSQLDB_1.8, für Connection profile name anschließend New HSQLDB und abschließend als Database name aus dem Auswahlmenü PUBLIC. Finish schließt den Dialog, legt eine Datei test.sqlpage an und öffnet diese in einem neuen Editor für SQL-Anweisungen. Tragen wir dort Folgendes ein: SELECT * FROM Customer
Das Kontextmenü im SQL-Editor bietet Execute All. In der Ansicht SQL Results sind die Ergebnisse dann abzulesen.
1147
16
Datenbankmanagement mit JDBC
Abbildung 16.8: Die drei Ansichten »Database Explorer«, »Data Output« und der Editor für das SQL Scrapbook
Tipp Mit der rechten Maustaste lassen sich im Kontextmenü Edit in SQL Query Builder... die Abfragen auch etwas mehr grafisch visualisieren. Wenn wir unsere Beispiele beendet haben, sollten wir im Data Source Explorer die Verbindung wieder schließen; dazu ist auf unserer Datenbank in der Ansicht Database Explorer im Kontextmenü Disconnect zu wählen.
16.3
JDBC und Datenbanktreiber
JDBC ist die inoffizielle Abkürzung für Java Database Connectivity und bezeichnet einen Satz von Schnittstellen, um relationale Datenbanksysteme von Java zu nutzen. Die erste JDBC-Spezifikation gab es im Juni 1996. Die Schnittstellen und wenigen Klassen sind ab dem JDK 1.1 im Core-Paket integriert. Die JDBC-API und ihre Treiber erreichen eine wirksame Abstraktion von relationalen Datenbanken, sodass durch die einheitliche Programmierschnittstelle die Funktionen differierender Datenbanken in gleicher Weise genutzt werden können. Das Lernen von
1148
16.3
JDBC und Datenbanktreiber
verschiedenen Zugriffsmethoden für unterschiedliche Datenbanken der Hersteller entfällt. Wie jedoch diese spezielle Datenbank nun wirklich aussieht, verheimlicht uns die Abstraktion. Jede Datenbank hat ihr eigenes Protokoll (und eventuell auch Netzwerkprotokoll), doch die Implementierung ist nur dem Datenbanktreiber bekannt. Das Modell von JDBC setzt auf dem X/OPEN-SQL-Call-Level-Interface (CLI) auf und bietet somit die gleiche Schnittstelle wie Microsofts ODBC (Open1 Database Connectivity). Dem Programmierer gibt JDBC Methoden, um Verbindungen zu Datenbanken aufzubauen, Datensätze zu lesen oder neue Datensätze zu verfassen. Zusätzlich können Tabellen aktualisiert und Prozeduren auf der Serverseite ausgeführt werden.
Hinweis Ein JDBC-Treiber muss nicht unbedingt relationale Datenbanken ansprechen, obwohl das der häufigste Fall ist. Mit dem freien xlSQL (https://xlsql.dev.java.net/) steht ein JDBC-Treiber bereit, der auf Excel-Tabellen beziehungsweise CSV-Dateien arbeitet, und Oracle bietet mit Synopsis (http://www.sunopsis.com/corporate/us/products/jdbcforxml/) ein Produkt, das statt relationaler Datenbanken XML-Dokumente verwendet.
Implementierung der JDBC-API Um eine Datenbank ansprechen zu können, müssen wir einen Treiber haben, der die JDBCAPI implementiert und zwischen dem Java-Programm und der Datenbank vermittelt. Jeder Treiber ist üblicherweise anders implementiert, denn er muss die datenbankunabhängige JDBC-API auf die konkrete Datenbank übertragen. Oracle veröffentlicht unter http://developers.sun.com/product/jdbc/drivers Treiber zu allen möglichen Datenbanken. Eine Suchmaske erlaubt die Eingabe einer Datenbank und die Auswahl eines gewünschten Typs.
16.3.1
Treibertypen *
Oracle definiert vier Treiber-Kategorien, die wir im Folgenden beschreiben. Sie unterscheiden sich im Wesentlichen darin, ob sie über einen nativen Anteil verfügen oder nicht.
Typ 1: JDBC-ODBC-Brücke ODBC (Open Database Connectivity Standard) ist ein Standard von Microsoft, der den Zugriff auf Datenbanken über eine genormte Schnittstelle möglich macht. ODBC ist insbesondere in
1
Microsoft und Open? Eine ungewohnte Kombination ...
1149
16
16
Datenbankmanagement mit JDBC
der Windows-Welt weit verbreitet, und für jede ernst zu nehmende Datenbank gibt es einen Treiber. Da es am Anfang der JDBC-Entwicklung keine Treiber gab, haben sich JavaSoft und Intersolv (seit 2000 Merant) etwas ausgedacht: eine JDBC-ODBC-Brücke, die die Aufrufe von JDBC in ODBC-Aufrufe der Clientseite umwandelt. Da die Performance oft nicht optimal und die Brücke nicht auf jeder Plattform verfügbar ist, stellt diese JDBC-Anbindung häufig eine Notlösung dar. Und weil ODBC eine systembezogene Lösung ist, hat der Typ-1-Treiber native Methoden, was die Portierung und seinen Einsatz – etwa über das Netz – erschwert. Die JDBCODBC-Brücke implementiert seit Version 1.4 den JDBC 2-Standard.
Hinweis Die Geschwindigkeit des Zugriffs über die JDBC-ODBC-Brücke hängt von vielen Faktoren ab, ist aber im Allgemeinen nicht so gut. Der Grund ist, dass die Abfrage unter JDBC bis zur Datenbank viele Schichten durchläuft. Jede der Schichten übersetzt die Abfragen für die nächste Schicht. Zusätzlich kommen zum Zeitaufwand noch Inkompatibilitäten und Fehler hinzu. Somit hängt das Gelingen der JDBC-ODBC-Brücke von vielen Schichten ab und ist oft nicht so performant wie eine native Implementierung.
Typ 2: native plattformeigene JDBC-Treiber Diese Treiber übersetzen die JDBC-Aufrufe direkt in Aufrufe der Datenbank-API. Dazu enthält der Treiber Programmcode, der native Methoden aufruft. Treiber vom Typ 1 oder 2 sind nicht portabel, da sie zum einen für die JDBC-ODBC-Brücke auf die Plattform-Bibliothek für ODBC zurückgreifen müssen und zum anderen auf plattformspezifische Zugriffsmöglichkeiten für die Datenbank angewiesen sind. Damit ist der Nachteil verbunden, dass Applets mit diesen Treibern nichts anfangen können. Ein Applet erlaubt es nicht, nativen Code von anderen Quellen zu laden und auszuführen. Das ist nicht leicht, wenn etwa ein Macintosh mit Power-PC-Prozessor einen binären Treiber für eine MS-SQL-Datenbank installieren möchte. Die Quintessenz daraus: Applets können damit keine Verbindung zu einer externen Datenquelle aufbauen.
Typ 3: universeller JDBC-Treiber Der universelle JDBC-Treiber ist ein in Java programmierter Treiber, der beim Datenbankzugriff auf den Client geladen wird. Der Treiber kommuniziert mit der Datenbank nicht direkt, sondern mit einer Softwareschicht, die zwischen der Anwendung und der Datenbank sitzt: der Middleware. Damit erfüllen Typ-3-Treiber eine Vermittlerrolle, denn erst die Middleware leitet die Anweisungen an die Datenbank weiter. Für Applets und Internet-Dienste hat ein
1150
16.3
JDBC und Datenbanktreiber
Typ-3-Treiber den großen Vorteil, dass seine Klassendateien oft kleiner als Typ-4-Treiber sind, da ein komprimiertes Protokoll eingesetzt werden kann. Über das spezielle Protokoll zur Middleware ist auch eine Verschlüsselung der Verbindung möglich. Kaum eine Datenbank unterstützt verschlüsselte Datenbankverbindungen. Da zudem das Middleware-Protokoll unabhängig von der Datenbank ist, müssen auf der Clientseite für einen Datenbankzugriff auf mehrere Datenbanken auch nicht mehr alle Treiber installiert werden, sondern im günstigsten Fall nur noch ein Typ-3-Treiber von einem Anbieter. Die Ladezeiten sind damit deutlich geringer.
Typ 4: direkte Netzwerktreiber Diese Treiber sind vollständig in Java programmiert und kommunizieren direkt mit dem Datenbank-Server. Sie sprechen mithilfe des datenbankspezifischen Protokolls direkt mit der Datenbank über einen offenen IP-Port. Dies ist in einer Direktverbindung die performanteste Lösung. Sie ist jedoch nicht immer realisierbar, etwa bei Datenbanken wie MS Access, dBase oder Paradox, die kein Netzwerkprotokoll definieren.
16.3.2
JDBC-Versionen *
Mit den Java-Versionen ist auch die Versionsnummer von JDBC gestiegen:
16 Þ Am Anfang stand JDBC 1.0, das Sun im Jahre 1997 in Java 1.1 integrierte. JDBC 1.0 basiert auf
SQL-92. Þ Die nächste Spezifikation ist die JDBC 2.0 API. Sie berücksichtigt SQL-99 (SQL-3). Die Spezi-
fikation der Version 2 setzt sich aus zwei Teilen zusammen: einer JDBC 2.0 core API und einer JDBC 2.0 Optional Package API. Die Core-API im Paket java.sql erweitert das Ur-JDBC um Batch-Updates und SQL-3-Datentypen. Das JDBC Optional Package liegt im Paket javax.sql und bietet unter anderem Data-Source, Connection-Pooling und verteilte Transaktionen. Während das Core-Paket fester Teil von Java 1.2 war, ist das optionale Paket in Java 1.2 noch echt optional und erst in Java 1.3 fest integriert. Für fast alle Datenbanken gibt es JDBC-2.0-Treiber. Þ JDBC 3.0 ist Teil von Java 1.4. Es integriert die JDBC 2.1 core API, das JDBC 2.0 Optional Pa-
ckage und nimmt neu unter anderem hinzu: Savepoints in Transaktionen, Wiederverwendung von Prepared-Statements, JDBC-Datentypen BOOLEAN und DATALINK, Abrufen automatisch generierter Schlüssel, Änderungen von LOBs und mehrere gleichzeitig geöffnete ResultSets. Þ In Java 5 hat sich nicht viel an JDBC geändert. Es ist immer noch JDBC 3.0, doch sind JDBC-
RowSet-Implementierungen hinzugekommen.
1151
16
Datenbankmanagement mit JDBC
Þ In JDBC 4.0, das in Java 6 Einzug gehalten hat, werden Treiber – wenn mit einer speziellen
Mata-Datei vorbereitet – automatisch angemeldet. Weiterhin gibt es XML-Datentypen aus SQL:2003 und Zugriff auf die SQL-ROWID. Þ Ein kleines Update auf JDBC 4.1 bringt Java 7 mit sich. Die API unterstützt etwa das neue
Sprachfeature try-mit-Ressourcen.
Hinweis Viele JDBC 4-Treiber gibt es im Moment noch nicht. Die aktuellen Treiber für die Datenbanken Oracle 11, Java DB (Apache Derby), DB 2 und MySQL implementieren einige JDBC 4-Eigenschaften, wenngleich nicht alle. http://developers.sun.com/product/jdbc/drivers zählt bislang keinen JDBC 4-Treiber auf. Für JDBC 3 gibt es immerhin mehrere.
Der Grad der SQL-Unterstützung Auch wenn uns der neueste Treiber einer Datenbank vorliegt, heißt das nicht, dass er auch alle JDBC-Möglichkeiten ausschöpft. Zum einen kann das daran liegen, dass die Datenbank diese Möglichkeiten gar nicht bietet – etwa Savepoints – oder dass der Treiber nicht hinreichend aktuell ist. Einige Möglichkeiten lassen sich über die Metadaten einer Datenbank erfragen. Dazu zählt zum Beispiel, ob ein Treiber beziehungsweise eine Datenbank den vollen ANSI-92-Standard unterstützt. Die Metadaten liefern über die Methoden supportsANSI92XXXSQL() den Hinweis, ob die Datenbank ANSI 92 Entry Level (gilt immer), Intermediate SQL oder Full SQL unterstützt. Auch für ODBC gibt es unterschiedliche Level: Minimum SQL Grammar, Core SQL Grammar und Extended SQL Grammar. Weitere Informationen bietet die Webseite http:// java.sun.com/products/jdbc/driverdevs.html.
16.4 Eine Beispielabfrage 16.4.1
Schritte zur Datenbankabfrage
Wir wollen kurz die Schritte skizzieren, die für einen Zugriff auf eine relationale Datenbank mit JDBC erforderlich sind: 1. Einbinden der JDBC-Datenbanktreiber in den Klassenpfad 2. unter Umständen Anmelden der Treiberklassen 3. Verbindung zur Datenbank aufbauen 4. eine SQL-Anweisung erzeugen
1152
16.4
Eine Beispielabfrage
5. SQL-Anweisung ausführen 6. das Ergebnis der Anweisung holen, bei Ergebnismengen über diese iterieren 7. die Datenbankverbindung schließen Wir beschränken uns im Folgenden auf die Verbindung zum freien Datenbanksystem HSQLDB.
16.4.2 Ein Client für die HSQLDB-Datenbank Ein Beispiel soll zu Beginn die Programmkonzepte für JDBC veranschaulichen, bevor wir im Folgenden das Java-Programm weiter sezieren. Das Programm in der Klasse FirstSqlAccess nutzt die Datenbank TutegoDB, die sich im Suchpfad befinden muss; wir können ebenso absolute Pfade bei HSQLDB angeben, etwa C:/TutegoDB. Bei der Parametrisierung »jdbc:hsqldb:file:...« von HSQLDB liest die Datenbank beim ersten Start die Daten aus der Datei ein, verwaltet sie im Speicher und schreibt sie am Ende des Programms wieder in eine Datei zurück. Da wir die Datenbank schon früher mit Demo-Daten gefüllt haben, lässt sich jetzt eine SQLSELECT-Abfrage absetzen: Listing 16.1: com/tutego/insel/jdbc/FirstSqlAccess.java
16
package com.tutego.insel.jdbc; import java.sql.*; public class FirstSqlAccess { public static void main( String[] args ) { try { Class.forName( "org.hsqldb.jdbcDriver" ); } catch ( ClassNotFoundException e ) { System.err.println( "Keine Treiber-Klasse!" ); return; }
1153
16
Datenbankmanagement mit JDBC
Connection con = null; try { con = DriverManager.getConnection( "jdbc:hsqldb:file:TutegoDB;shutdown=true", "sa", "" ); Statement stmt = con.createStatement(); //
stmt.executeUpdate( "INSERT INTO CUSTOMER " +
//
"VALUES(50,'Christian','Ullenboom','Immengarten 6','Hannover')" ); ResultSet rs = stmt.executeQuery( "SELECT * FROM Customer" ); while ( rs.next() ) System.out.printf( "%s, %s %s%n", rs.getString(1), rs.getString(2), rs.getString(3) ); rs.close(); stmt.close(); } catch ( SQLException e ) { e.printStackTrace(); } finally { if ( con != null ) try { con.close(); } catch ( SQLException e ) { e.printStackTrace(); } } }
}
Dem Beispiel ist in diesem Status schon die aufwändige Fehlerbehandlung anzusehen. Das Schließen vom ResultSet und Statement ist vereinfacht, aber okay, weil das finally auf jeden Fall die Connection schließt. Ab Java 7 kann auch try-mit-Ressourcen die Verbindung automatisch schließen.
1154
16.4
Eine Beispielabfrage
Hinweis Es ist möglich, auch ohne ODBC-Eintrag Zugriff auf eine Access-Datenbank aufzubauen – nützlich ist das zum Beispiel dann, wenn der Name der Datenbank erst später bekannt wird. con = DriverManager.getConnection( "jdbc:odbc:Driver="+ "{Microsoft Access Driver (*.mdb)};DBQ=c:/daten/test.mdb", "name", "pass" );
Ein ähnlicher String kann auch für den Zugriff auf eine dBase-Datenbank genutzt werden, für die ein ODBC-Treiber angemeldet ist: jdbc:odbc:Driver={Microsoft dBase Driver (*.dbf)};DBQ=c:\database.dbf
16.4.3
Datenbankbrowser und eine Beispielabfrage unter NetBeans
Wer mit NetBeans arbeitet, der kann einfach mit der ab Java 6 mitgelieferten Datenbank Java DB arbeiten, denn NetBeans bringt eine Beispieldatenbank für Java DB mit. Im Folgenden soll 1. die Beispieldatenbank gestartet, 2. die Datenbank mit der Browser untersucht und 3. ein Java-Programm geschrieben werden, das diese Datenbank anspricht.
16
Beispieldatenbank starten Ist NetBeans gestartet, wählen wir im Menü Window 폷 Services. Links kommt in der Darstellung ein Punkt Databases hinzu, wobei unser Interesse der Beispieldatenbank dient, zu der wir mit Connect über das Kontextmenü eine Verbindung aufbauen wollen.
Abbildung 16.9: Demo-Datenbank starten
1155
16
Datenbankmanagement mit JDBC
In der Ausgabe ist zu erkennen, dass die Datenbank gestartet und bereit für Verbindungen ist.
Abbildung 16.10: Ausgabe nach dem Start der Datenbank
SQL-Anweisungen absetzen Links ist anschließend der Baum mit vielen Informationen gefüllt, und alle Tabelleninformationen sind zugänglich. Mit der rechten Maustaste und dem Kontextmenü lassen sich anschließend SQL-Anweisungen über Execute Command... an die Datenbank absetzen.
Abbildung 16.11: SQL-Abfragen starten
1156
16.4
Eine Beispielabfrage
Es öffnet sich ein SQL-Editor, der Tastaturvervollständigung beherrscht und sogar in die Datenbank schaut, um Tabellen und Spaltennamen korrekt zu vervollständigen.
16 Abbildung 16.12: Ergebnis einer SQL-Abfrage
JDBC-Beispiel Das JDBC-Beispiel von eben können wir leicht auf die NetBeans-Datenbank übertragen. Drei Dinge müssen wir anpassen: Þ Der Treiber muss im Klassenpfad stehen. Þ Die Treiberklasse ist org.apache.derby.jdbc.ClientDriver. Das explizite Laden kann aber
entfallen, da Java einen JDBC 4-Treiber selbstständig findet, wenn er im Klassenpfad steht. Þ Die Datenbank-URL ist jdbc:derby://localhost:1527/sample.
Die letzten beiden Dinge sind schnell im Quellcode angepasst. Um den Treiber in den Klassenpfad zu setzen, wählen wir links im Projekt bei Libraries das Kontextmenü und dann Add Jar/Folder...
1157
16
Datenbankmanagement mit JDBC
Abbildung 16.13: Java-Archive hinzufügen
Aus dem JDK-Installationsverzeichnis unter db/lib wählen wir derbyclient.jar.
Abbildung 16.14: derbyclient.jar auswählen
Öffnen fügt das Jar-Archiv hinzu. Wir wollen das SELECT noch etwas anpassen, und dann folgt: Listing 16.2: com/tutego/insel/jdbc/FirstSqlAccess.java package com.tutego.insel.jdbc; import java.sql.*; public class SecondSqlAccess { public static void main( String[] args ) { Connection con = null;
1158
16.5
Mit Java an eine Datenbank andocken
try { con = DriverManager.getConnection( "jdbc:derby://localhost:1527/sample", "app", "app" ); Statement stmt = con.createStatement(); ResultSet rs = stmt.executeQuery( "SELECT NAME, ADDRESSLINE1, PHONE FROM Customer" ); while ( rs.next() ) System.out.printf( "%s, %s %s%n", rs.getString(1), rs.getString(2), rs.getString(3) ); rs.close(); stmt.close(); } catch ( SQLException e ) {
16
e.printStackTrace(); } finally { if ( con != null ) try { con.close(); } catch ( SQLException e ) { e.printStackTrace(); } } } }
16.5
Mit Java an eine Datenbank andocken
Zum Aufbau einer Datenbankverbindung und zur Herstellung einer Connection gibt es zwei Möglichkeiten: Þ Direkt über den DriverManager: Die Verbindungsdaten stehen im Quellcode (entweder di-
rekt, oder sie werden über Konfigurationsdateien bestimmt). Diesen Weg zeigte das Beispiel bisher.
1159
16
Datenbankmanagement mit JDBC
Þ Über einen zentralen Namensdienst: Im JNDI ist eine vorkonfigurierte Datenquelle
(DataSource) abgelegt, die wir entnehmen und über die wir eine Verbindung aufbauen. Im Java-Enterprise-Bereich ist das übliche Vorgehen der zweite Weg über eine DataSource. Wir wollen uns doch zunächst mit dem DriverManager beschäftigen, bevor wir zur DataSource und zum JNDI kommen. Alle verwendeten Klassen und Schnittstellen für den Datenbankteil liegen unter java.sql.*. Wenn wir mit einem Namensdienst arbeiten, sind Typen aus dem Paket javax.naming nötig.
16.5.1
Der Treiber-Manager *
Alle Datenbanktreiber werden an einer zentralen Stelle, dem Treiber-Manager, gesammelt. Die Zentrale ist in Java durch die Klasse DriverManager gegeben. Die Methoden der Klasse sind statisch, da sich ein Exemplar dieser Klasse nicht erzeugen lässt; der Konstruktor ist privat. Die wichtigste Methode des Treiber-Managers ist statisch und heißt getConnection(). Mit ihr können wir eine Verbindung zur Datenbank aufbauen. Es lassen sich aber auch alle angemeldeten Treiber erfragen.
16.5.2
Den Treiber laden
Vor der Ausführung der JDBC-Befehle muss ein passender Datenbanktreiber geladen werden. Der Datenbanktreiber ist eine Java-Klasse, die beim Treiber-Manager angemeldet sein muss.
Hinweis Seit Java 6 werden die Treiberklassen – soweit das vom Treiberproduzenten vorbereitet ist – automatisch geladen. Der Entwickler muss den Namen der Treiberklassen nicht mehr kennen. Intern funktioniert das über Service Provider. Für eigene automatisch zu ladende Klassen ist java.util.ServiceLoader einen Blick wert. Vor Java 6 und bei nicht vorbereiteten Datenbanken ist die Treiberklasse von Hand einzubinden. Zwei Möglichkeiten sind populär: Þ Die Property jdbc.drivers enthält den Namen des Datenbanktreibers. Auf der Kommando-
zeile lässt sich die Variable mit dem Schalter -D einfach setzen: $ java -Djdbc.drivers=org.hsqldb.jdbcDriver Þ Die zweite Möglichkeit bietet der Aufruf von Class.forName(driverclassname), die eine Trei-
berklasse lädt. Sie trägt sich automatisch beim Treiber-Manager ein.
1160
16.5
Mit Java an eine Datenbank andocken
final class java.lang.Class implements Serializable, GenericDeclaration, Type, AnnotatedElement Þ static Class forName(String className) throws ClassNotFoundException
Sucht, lädt und bindet die Klasse mit dem qualifizierten Namen className ins Laufzeitsystem ein. Die statische Methode liefert ein Class-Objekt zurück, falls sie die Klasse laden kann, andernfalls quittiert sie einen Fehler mit einer ClassNotFoundException. Die Programmzeilen für das manuelle Laden der Klasse org.hsqldb.jdbcDriver sind somit: Listing 16.3: com/tutego/insel/jdbc/DriverManagerDemo.java, Ausschnitt try { Class.forName( "org.hsqldb.jdbcDriver" ); } catch ( ClassNotFoundException e ) { // Blöd: Treiber konnte nicht geladen werden. e.printStackTrace(); }
Da wir die Klasse nur laden, aber die Referenz auf den Klassen-Deskriptor nicht benötigen, belassen wir es bei einem Aufruf und beachten den Rückgabewert nicht. Diese Class.forName() löst eine ClassNotFoundException aus, falls die Klasse nicht gefunden wurde, der Treiber also nicht geladen werden konnte.
Hinweis Ein Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); ist zum Laden des JDBC-ODBC-Treibers nicht nötig, da er schon initialisiert ist.
Datenbank
Klassenname für den JDBC-Treiber
Adabas D
de.sag.jdbc.adabasd.Adriver
Borland JDataStore
com.borland.datastore.jdbc.DataStoreDriver
Borland Interbase
interbase.interclient.Driver
DB2/Derby
com.ibm.db2.jcc.DB2Driver
Informix
com.informix.jdbc.IfxDriver
IDS Server
ids.sql.IDSDriver
Tabelle 16.2: Übersicht der jeweiligen voll qualifizierten Klassennamen für den JDBC-Treiber
1161
16
16
Datenbankmanagement mit JDBC
Datenbank
Klassenname für den JDBC-Treiber
Microsoft SQL Server
com.microsoft.jdbc.sqlserver.SQLServerDriver
mSQL
COM.imaginary.sql.msql.MsqlDriver
MySQL
com.mysql.jdbc.Driver
Oracle
oracle.jdbc.driver.OracleDriver
Pointbase
com.pointbase.jdbc.jdbcUniversalDriver
PostgreSQL
org.postgresql.Driver
Sybase
com.sybase.jdbc2.jdbc.SybDriver
Tabelle 16.2: Übersicht der jeweiligen voll qualifizierten Klassennamen für den JDBC-Treiber (Forts.)
16.5.3
Eine Aufzählung aller Treiber *
Die statische Methode DriverManager.getDrivers() liefert eine Aufzählung der angemeldeten Treiber. Die folgenden Zeilen geben einfach den Klassennamen aus – die Treiber implementieren nicht unbedingt eine sinnvolle toString()-Methode, sodass wir uns mit dem Klassennamen begnügen: Listing 16.4: com/tutego/insel/jdbc/DriverManagerDemo.java, Ausschnitt for ( Enumeration e = DriverManager.getDrivers(); e.hasMoreElements(); ) System.out.println( e.nextElement().getClass().getName() );
Die Elemente, die durch die Enumeration ausgelesen werden, sind Treiberobjekte vom Typ Driver. Jeder Datenbanktreiber implementiert diese Schnittstelle. Mit dem manuell geladenen Treiber org.hsqldb.jdbcDriver und dem Standard-JDBC-ODBC-Treiber verbunden ist die Ausgabe: sun.jdbc.odbc.JdbcOdbcDriver org.hsqldb.jdbcDriver
16.5.4
Log-Informationen *
Zu Testzwecken bietet es sich an, Informationen des Treibers und der Datenbank in einen speziellen Ausgabekanal zu schreiben. Wir können die Log-Informationen so umlenken, dass sie in den Standardausgabestrom geschrieben werden. Das macht die statische Methode setLogWriter(), die einen PrintWriter als Parameter erwartet:
1162
16.5
Mit Java an eine Datenbank andocken
Listing 16.5: com/tutego/insel/jdbc/DriverManagerDemo.java, Ausschnitt DriverManager.setLogWriter( new PrintWriter( System.out ) ); Class.forName( "org.hsqldb.jdbcDriver" );
Da damit die Log-Ausgaben in den Standard-Ausgabekanal kommen, ist die Ausgabe für das Laden des HSQLDB-Treibers: JdbcOdbcDriver class loaded registerDriver: driver[className=sun.jdbc.odbc.JdbcOdbcDriver,sun.jdbc.odbc.ð JdbcOdbcDriver@173a10f] DriverManager.initialize: jdbc.drivers = null JDBC DriverManager initialized registerDriver: driver[className=org.hsqldb.jdbcDriver,org.hsqldb.jdbcDriver@530daa]
Nicht nur Treiber und SQL-Klassen nutzen den Log-Stream, auch wir können Zeichenketten ausgeben. Dazu dient die statische Methode println(), die als Parameter nur einen String annimmt. println() ist so implementiert, dass bei einem nicht gesetzten Log-Stream die Ausgabe unterbleibt. class java.sql.DriverManager Þ static void setLogWriter(PrintWriter out)
Setzt den Log-Writer und startet damit das Logging. Mit dem Argument null wird das Logging wieder ausgeschaltet. Þ static PrintWriter getLogWriter()
Liefert den angemeldeten Log-Writer. Þ static void println(String message)
Schreibt eine Meldung in den Log-Stream.
16.5.5
Verbindung zur Datenbank auf- und abbauen
Nach dem Laden des Treibers können wir eine Verbindung zur Datenbank mithilfe des Connection-Objekts aufbauen, das DriverManager.getConnection() zurückgibt. Der Methode wird eine Datenbank-URL mitgegeben und optional Benutzername und Passwort.
Die Datenquelle angeben Alle Datenquellen sind durch eine besondere URL qualifiziert, die folgendes Format besitzt: jdbc:Subprotokoll:Datenquellenname
1163
16
16
Datenbankmanagement mit JDBC
Die Datenbank definieren jeweils unterschiedliche Subprotokolle, und die Angabe des Servernamens ist auch immer individuell: Datenbank
Subprotokoll
Beispiel
Derby
derby:net
jdbc:derby:net://host:1527/
IBM DB2
db2
jdbc:db2://database
HSQLDB
hsqldb
jdbc:hsqldb:file:database
Interbase
interbase
jdbc:interbase://host/dabase.gdb
MySQL
Mysql
jdbc:mysql://host/database
ODBC-Datenquellen
Odbc
jdbc:odbc:database
Oracle Thin
oracle:thin
jdbc:oracle:thin:@host:1243:database
Sybase
sybase:Tds
jdbc:sybase:Tds:host:1234/database
Tabelle 16.3: Protokoll-URLs einiger Datenbanken
Verbindung aufnehmen Der Aufruf von DriverManager.getConnection() liefert – wenn alles gut geht – ein ConnectionObjekt, das die Verbindung mit der Datenbank repräsentiert.
Beispiel Verbinde mit einer Datenbank, die den Namen »TutegoDB« trägt (im Fall von ODBC wurde der Name im Datenquellen-Administrator festgelegt und hat nichts mit dem Dateinamen zu tun): con = DriverManager.getConnection( "jdbc:hsqldb:file:TutegoDB;shutdown=true", "sa", "" );
Die statische Methode getConnection() erwartet bis zu drei Parameter: Die URL der Datenbank, zu der die Verbindung aufgenommen werden soll, ist der Pflichtparameter. Der Anmeldename und das Passwort sind optional und können auch leere Strings ("") sein, wenn eine Authentifizierung keine Rolle spielt. Meldet getConnection() keinen Fehler, so liefert sie uns eine geöffnete Datenbankverbindung. class java.sql.DriverManager Þ static Connection getConnection(String url) throws SQLException
Versucht, eine Verbindung zur Datenbank aufzubauen. Die Klasse DriverManager sucht dabei einen passenden Treiber aus der Liste der registrierten JDBC-Treiber für die Datenbank.
1164
16.5
Mit Java an eine Datenbank andocken
Þ static Connection getConnection(String url, String user, String password)
throws SQLException
Versucht, eine Verbindung zur Datenbank aufzubauen. user und password werden für die Verbindung zur Datenbank verwendet. Þ static Connection getConnection(String url, Properties info)
throws SQLException
Versucht, eine Verbindung zur Datenbank aufzubauen. Im Properties-Objekt können die Felder user und password sowie weitere Informationen vorhanden sein.
16
Abbildung 16.15: Klassendiagramm für DriverManager
Verbindung beenden Da eine Verbindung zu schließen ist (und nicht der DriverManager), finden wir eine Methode close() beim Connection-Objekt. Verbindungen zu schließen ist immens wichtig, sodass dieser Teil im Allgemeinen im finally-Block steht: Listing 16.6: com/tutego/insel/jdbc/FirstSqlAccess.java, Ausschnitt Connection con = null; try { con = DriverManager.getConnection( ... ); ... } catch ( SQLException e ) { e.printStackTrace();
1165
16
Datenbankmanagement mit JDBC
} finally { if ( con != null ) try { con.close(); } catch ( SQLException e ) { e.printStackTrace(); } } interface java.sql.Connection extends Wrapper, AutoCloseable Þ void close() throws SQLException
Schließt die Verbindung zur Datenbank. Auch hier kann eine SQLException auftauchen.
Wartezeit einstellen Wenn wir uns mit der Datenbank verbinden, lässt sich noch eine Wartezeit in Sekunden einstellen, die angibt, wie lange der Treiber für die Verbindung mit der Datenbank warten darf. Gesetzt wird dieser Wert mit setLoginTimeout(), und entsprechend wird er mit getLoginTimeout() ausgelesen. Standardmäßig ist dieser Wert 0. class java.sql.DriverManager Þ static void setLoginTimeout(int seconds)
Setzt die Zeit, die maximal gewartet wird, wenn der Treiber sich mit einer Datenbank verbindet. Þ static int getLoginTimeout()
Liefert die Wartezeit in Sekunden.
Wie der Treiber gefunden wird – hinter den Kulissen von getConnection() * Es lohnt sich, einmal hinter die Kulissen der Methode getConnection() zu blicken. Das DriverManager-Objekt wird veranlasst, die Verbindung zu öffnen. Dabei versucht es, einen passenden Treiber aus der Liste der JDBC-Treiber auszuwählen. Sein Treiber verwaltet die Klasse DriverManager in einem privaten Objekt DriverInfo. Dieses enthält ein Treiber-Objekt (Driver), ein Objekt (securityContext) und den Klassennamen (className). Bei getConnection() geht der DriverManager die Liste der DriverInfo-Objekte ab und versucht, sich über die connect()-Methode anzumelden. Bemerkt der Treiber, dass er mit der URL nicht viel anfangen kann, gibt er null zurück, und getConnection() versucht es mit dem nächsten Treiber. Ging alles daneben und konnte keiner der angemeldeten Treiber etwas mit dem Subprotokoll anfangen, so bekommen wir eine SQLException("No suitable driver", "08001").
1166
16.6
Datenbankabfragen
16.6 Datenbankabfragen Mit einer gelungenen Verbindung und dem Connection-Objekt in der Hand lassen sich SQLKommandos absetzen, und die Datenbank kann gesteuert werden.
16
Abbildung 16.16: Klassendiagramm für »Connection«
1167
16
Datenbankmanagement mit JDBC
16.6.1
Abfragen über das Statement-Objekt
Für alle SQL-Abfragen und Manipulationen der Datenbank sind Anweisungsobjekte von der Connection zu erfragen. JDBC bietet drei Typen von Anweisungsobjekten: Þ normale Anweisungen vom Typ Statement Þ vorbereitete Anweisungen (Prepared Statement) vom Typ PreparedStatement Þ gespeicherte Prozeduren (Stored Procedures) vom Typ CallableStatement
Für einfache Anweisungen liefert uns die Methode createStatement() ein Statement-Objekt, mit dem sich im nächsten Schritt Abfragen stellen lassen.
Beispiel Hole ein Statement-Objekt für einfache Abfragen: Statement stmt = con.createStatement();
Die Methode kann – wie fast alle Methoden aus dem SQL-Paket – eine SQLException auslösen.
interface java.sql.Connection extends Wrapper, AutoCloseable Þ Statement createStatement() throws SQLException
Liefert ein Statement-Objekt, um SQL-Anweisungen zur Datenbank zu schicken.
SQL-Anweisungen ausführen Das Statement-Objekt nimmt mit der Methode executeQuery() eine Zeichenfolge mit einer SQL-SELECT-Anweisung entgegen und mit executeUpdate() eine Anweisung für eine UPDATE-, INSERT- oder DELETE-Operation.
Beispiel Erfrage alle Spalten der Tabelle »Customer«: String query = "SELECT * FROM Customer"; ResultSet rs = stmt.executeQuery( query );
Der Aufruf liefert uns die Ergebnisse als Zeilen in Form eines ResultSet-Objekts.
1168
16.6
Datenbankabfragen
Hinweis Der JDBC-Treiber überprüft die SQL-Anweisungen nicht, sondern leitet sie fast ungesehen an die Datenbank weiter. Sind die SQL-Abfragen falsch, lassen sich Fehler schwer entdecken. Daher bietet es sich an, zum Testen erst die Kommandos auf der Konsole auszugeben. Insbesondere bei zusammengesetzten Ausdrücken finden sich so leichter Fehler.
interface java.sql.Statement extends Wrapper, AutoCloseable Þ ResultSet executeQuery(String sql) throws SQLException
Führt ein SQL-Statement aus, das für die Ergebnisliste ein einzelnes ResultSet-Objekt zurückgibt. Wird die gleiche SQL-Anweisung mehrmals ausgeführt, lohnt es sich, ein PreparedStatement zu konstruieren.
16.6.2 Ergebnisse einer Abfrage in ResultSet Um mit der Auswertung vom ResultSet beginnen zu können, muss der Treiber die Informationen von der Datenbank bezogen haben. Ein Aufruf der next()-Methode von ResultSet setzt den internen Cursor auf die erste Zeile der geladenen Ergebnisse. Mit diversen Methoden von ResultSet können wir die unterschiedlichen Spalten ansprechen und die Zeilen auswerten. Um weitere Zeilen zu erhalten, nutzen wir wieder next(). Die Methode gibt false zurück, falls es keine neue Zeile mehr gibt.
Beispiel Gehe mit einer while-Schleife durch die gesamte Ergebnisliste, und gib das Ergebnis der Spalten 1, 2 und 3 auf dem Bildschirm aus: ResultSet rs = stmt.executeQuery( "SELECT * FROM Customer" ); while ( rs.next() ) System.out.printf( "%s, %s, %s%n", rs.getString(1), rs.getString(2), rs.getString(3) );
Der numerische Parameter steht für den Spaltenindex, der bei 1 beginnt. Wird der Methode getString() ein String übergeben, so bestimmt er den Namen der Spalte. Die Methode executeQuery() liefert immer ein ResultSet-Objekt (bis auf den Fehlerfall, der zu einer SQLException führt), auch wenn das ResultSet keine Zeilen enthält. So lassen sich über das ResultSet immer noch Metadaten abfragen.
1169
16
16
Datenbankmanagement mit JDBC
interface java.sql.ResultSet extends Wrapper, AutoCloseable Þ boolean next() throws SQLException
Der erste Aufruf muss next() sein, damit der Cursor auf die erste Zeile gesetzt wird. Die folgenden Aufrufe setzen den Cursor immer eine Zeile tiefer. Falls es keine Zeilen mehr gibt, liefert die Methode false.
getXXX(int) und getXXX(String) Da die Spalten verschiedene Datentypen besitzen können, bietet die Schnittstelle ResultSet für jeden Datentyp eine entsprechende Methode getXXX() an – XXX ist ein Datentyp wie int. Zwei Ausführungen der Methode getXXX() sind verfügbar: Bei der ersten Variante ist eine Ganzzahl als Parameter aufgeführt. Dieser Parameter gibt die Spalte der Operation an. Die zweite Variante erlaubt es, den Namen der Spalte anzugeben. Da alle Spalten immer als String ausgelesen werden können, ist es möglich, einfach getString() zu verwenden. Im Folgenden soll der Typ String stellvertretend für andere Typen wie int, double usw. stehen. interface java.sql.ResultSet extends Wrapper, AutoCloseable Þ String getString(int column) throws SQLException
Liefert aus der aktuellen Zeile den Inhalt der Spalte column als String. Die erste Spalte ist mit 1 adressiert. Þ String getString(String columnName) throws SQLException
Liefert in der aktuellen Zeile den Inhalt der Spalte mit dem Namen columnName als String.
Hinweis Üblicherweise ist es performanter, ein Spaltenelement über den Index anstatt über den Spaltennamen zu erfragen. Gibt es zwei Spalten mit dem gleichen Namen, liefert die mit dem Namen aufgerufene Methode immer die erste Spalte.
16.6.3 Java und SQL-Datentypen Jeder Datentyp in SQL hat einen mehr oder weniger passenden Datentyp in Java. Die Klasse java.sql.Types identifiziert alle SQL-Typen. So konvertiert der JDBC-Treiber bei jeder getXXX()Methode diese zu einem Datentyp, doch nur dann, wenn diese Konvertierung möglich ist. So lässt er es nicht zu, bei einer String-Spalte die getInteger()-Methode auszuführen. Umgekehrt
1170
16.6
Datenbankabfragen
lassen sich alle Datentypen als String auslesen. Die folgende Tabelle zeigt die Übereinstimmungen. Einige SQL-Datentypen können durch mehrere Zugriffsmethoden geholt werden: Ein INTEGER lässt sich mit getInt() oder getBigDecimal() holen und TIMESTAMP mit getDate(), getTime() oder getTimestamp(). Java-Methode
SQL-Typ
getInt()
INTEGER
getLong()
BIG INT
getFloat()
REAL
getDouble()
FLOAT
getBignum()
DECIMAL
getBigDecimal()
NUMBER
getBoolean()
BIT
getString()
VARCHAR
getString()
CHAR
getAsciiStream()
LONGVARCHAR
getDate()
DATE
getTime()
TIME
getTimestamp()
TIME STAMP
getObject()
jeder Typ
16
Tabelle 16.4: Datentypen in SQL und ihre Entsprechung in Java
In der Regel passen die Typen recht gut in das Java-System. So liefert getInt() ein int und getString() ein String-Objekt. Für einige Daten wurden jedoch spezielle Klassen entworfen; am
auffälligsten ist die Klasse java.sql.Date, auf die wir gleich noch zu sprechen kommen. Ist ein Eintrag in der Datenbank mit NULL belegt, so liefert die Methode eine null-Referenz. interface java.sql.ResultSet extends Wrapper, AutoCloseable Þ String getString(int columnIndex) Þ String getString(String columnLabel)
Liefert den Wert in der Spalte als Java-String. Þ boolean getBoolean(int columnIndex) Þ boolean getBoolean(String columnLabel)
Liefert den Wert in der Spalte als Java-boolean.
1171
16
Datenbankmanagement mit JDBC
Þ byte getByte(int columnIndex) Þ byte getByte(String columnLabel)
Liefert den Wert in der Spalte als Java-byte. Þ short getShort(int columnIndex) Þ short getShort(String columnLabel)
Liefert den Wert in der Spalte als Java-short. Þ int getInt(int columnIndex) Þ int getInt(String columnLabel)
Liefert den Wert in der Spalte als Java-int. Þ long getLong(int columnIndex) Þ long getLong(String columnLabel)
Liefert den Wert in der Spalte als Java-long. Þ float getFloat(int columnIndex) Þ float getFloat(String columnLabel)
Liefert den Wert in der Spalte als Java-float. Þ double getDouble(int columnIndex) Þ double getDouble(String columnLabel)
Liefert den Wert in der Spalte als Java-double. Þ BigDecimal getBigDecimal(int columnIndex, int scale) Þ BigDecimal getBigDecimal(String columnLabel, int scale)
Liefert den Wert in der Spalte als java.lang.BigDecimal-Objekt. Þ byte[] getBytes(int columnIndex) Þ byte[] getBytes(String columnLabel)
Liefert den Wert in der Spalte als Byte-Feld. Es besteht aus uninterpretierten Rohdaten. Þ Date getDate(int columnIndex) Þ Date getDate(String columnLabel)
Liefert den Wert in der Spalte als java.sql.Date-Objekt. Þ Time getTime(int columnIndex) Þ Time getTime(String columnLabel)
Liefert den Wert in der Spalte als java.sql.Time-Objekt. Þ Timestamp getTimestamp(int columnIndex) Þ Timestamp getTimestamp(String columnLabel)
Liefert den Wert in der Spalte als java.sql.Timestamp-Objekt. Þ InputStream getAsciiStream(int columnIndex)
1172
16.6
Datenbankabfragen
Þ InputStream getAsciiStream(String columnLabel)
Die Methode ermöglicht über einen InputStream Zugriff auf den Inhalt der Spalte. Nützlich ist dies für den Datentyp LONGVARCHAR. Der JDBC-Treiber konvertiert die Daten mitunter in das ASCII-Format. Þ InputStream getBinaryStream(int columnIndex) Þ InputStream getBinaryStream(String columnLabel)
Die Methode erlaubt es, auf den Inhalt der Spalte als InputStream zuzugreifen. Nützlich ist dies für den Datentyp LONGVARBINARY. Der JDBC-Treiber konvertiert die Daten mitunter in das ASCII-Format. Bevor aus einer anderen Spalte Daten ausgelesen werden, müssen die Daten vom Stream gelesen werden. Ein weiterer Aufruf schließt selbstständig den Datenstrom. Die Methode available() liefert die Rückgabe null, sofern keine Daten anliegen. Alle getXXX()-Methoden können eine SQLException in dem Fall auslösen, dass etwas mit der Datenbank nicht stimmt. Der throws-Ausdruck ist also in der Aufzählung nicht explizit angegeben.
16.6.4 Date, Time und Timestamp Datenbankseitig können Datumswerte im SQL-Typ DATE, TIME und TIMESTAMP abgelegt sein: Þ DATE speichert ein Datum, also Tag, Monat und Jahr. Die Textrepräsentation hat die Form
»YYYY-MM-DD«. Þ TIME speichert eine Zeit im 24-Stundenformat, also Stunden, Minuten und Sekunden. Se-
kunden können einen Sekundenbruchteil haben, sodass die Genauigkeit in die Nanosekunden geht. Die Darstellung ist »hh:mm:ss« bzw. »hh:mm:ss.nnnnnnn«. Þ TIMESTAMP verbindet DATE und TIME.
Unterschiedliche Datenbanken erlauben weitere Spezialitäten wie TIMESTAMP WITH TIME ZONE, was hier aber keine Rolle spielen soll. Zur Abbildung der SQL-Typen auf Java sieht JDBC drei entsprechende Klassen vor: SQL-Typ
Java-Klasse
DATE
java.sql.Date
TIME
java.sql.Time
TIMESTAMP
java.sql.Timestamp
Tabelle 16.5: Datum-/Zeittypen in SQL und ihre Entsprechung in Java
Es fällt auf, dass alle drei JDBC-Klassen von der Basisklasse java.util.Date erben. Das hat unterschiedliche Konsequenzen. Im Einzelnen:
1173
16
16
Datenbankmanagement mit JDBC
Þ Die Klasse java.sql.Date repräsentiert das SQL-DATE. Die Basisklasse java.util.Date ist na-
türlich etwas merkwürdig und kollidiert mit dem liskovschen Substitutionsprinzip, da die Unterklasse Eigenschaften wegdefiniert, die die Oberklasse bietet. Denn ein java.util.Date ist ja für Datum und Zeit verantwortlich, wobei java.sql.Date nur Tag, Monat, Jahr speichert. Wenn also ein java.sql.Date mit Zeitinformationen gefüllt wird, so wird beim Abspeichern in die Datenbank diese Zeit auf null gesetzt. Das nennt die API-Dokumentation »Normalisierung«. Þ Die Klasse Time repräsentiert ein SQL-TIME. Die Basisklasse java.util.Date ist genauso wi-
dersprüchlich, denn hier wird der Datumsteil ausgeblendet, und nur der Zeitanteil ist erlaubt. Þ Für den SQL-Typ TIMESTAMP fasst die Java-Klasse Timestamp die Datums- und Zeitangaben mit
einer Genauigkeit von Nanosekunden zusammen. Das ist wichtig zu beachten, denn bei einer Umwandlung eines Timestamp in ein java.util.Date gehen die Nanosekunden verloren, da java.util.Date diese Genauigkeit nicht bietet. Die Klasse Timestamp erbt von Date und fügt intern ein int nano-Attribut hinzu.
Die Verwandtschaft von java.sql.Date und java.util.Date Ein Datenbankprogramm, das die Klasse java.sql.Date nutzt und ebenfalls java.util eingebunden hat, wird bei der Compilierung zu einem Fehler führen, da der Compiler den Bezug auf die Klasse Date nicht zuordnen kann. Denkbar sind zwei Lösungen: Wird util nur deswegen eingebunden, weil Datenstrukturen, aber nicht die Date-Klasse genutzt werden, dann ließe sich die import-Deklaration umbauen, sodass die von util genutzten Klassen direkt in import genannt werden, etwa import java.util.ArrayList. Bei vielen benutzten Klassen aus dem util-Paket ist aber eine andere Lösung einfacher. Wir setzen vor die Klasse, die uns Ärger bereitet, einfach die volle Qualifizierung, schreiben also zum Beispiel: java.sql.Date date = rs.getDate( "birthday" );
Konvertierung von java.sql.Date in java.util.Date und umgekehrt Ein weiteres Problem betrifft die Konvertierung der beiden Klassen. Wollen wir beispielsweise eine Zeichenkette aus der Eingabe in eine Datenbank schreiben, dann haben wir das Problem, dass das Parsen mittels DateFormat nur ein java.util.Date liefert. Wir müssen also erst mit getTime() die Zeit erfragen und auf das SQL-DATE übertragen: java.sql.Date sqlDate = new java.sql.Date( java_util_Date.getTime() );
Der Konstruktor von java.sql.Date() mit den Millisekunden ist auch der einzige Konstruktor, der nicht veraltet ist. Daneben hat die Klasse java.sql.Date aber noch drei andere Methoden:
1174
16.6
Datenbankabfragen
class java.sql.Date extends java.util.Date Þ static Date valueOf(String s)
Wandelt einen String im JDBC-Stil (also »yyyy-mm-dd«) in ein Date-Objekt um. Þ String toString()
Liefert das Datum im JDBC-Datenformat. Þ void setTime(long date)
Setzt das Datum mit den Millisekunden.
16.6.5 Unicode in der Spalte korrekt auslesen Der Aufruf von getString() führt bei Unicode-kodierten Zeichenfolgen in der Datenbank unter Umständen zu Problemen. Bemerkbar macht sich dies durch seltsame Zeichen wie »?« oder Hexadezimal »0x3f«, die im String anstelle der Sonderzeichen auftauchen. Das liegt oft daran, dass der JDBC-Treiber die Kodierung nicht kennt und einfach jedes ASCII-Byte in ein Char umwandelt, obwohl in der Datenbank Umlaute als 2-Byte-Unicode oder Latin-1 kodiert werden. Bei eigenen Datenbanken funktioniert es, die Kodierung beim Verbindungsaufbau ausdrücklich zu setzen, um damit eine Konvertierung vorzuschreiben. getString() sollte dann die richtige Zeichenkette liefern. Bei anderen Datenbanken funktioniert es wiederum, den Text als Byte-Feld zu holen und dann ausdrücklich umzukodieren. Das Folgende ist etwa eine Lösung für PostgreSQL: new String( rs.getBytes(1), "ISO-8859–1" )
16.6.6 Eine SQL-NULL und wasNull() bei ResultSet Ist der Wert einer Spalte eine SQL-NULL, so ist bei einer Abfrage mit der getXXX()-Methode Vorsicht geboten. Eine Methode wie getString() liefert standardmäßig null, und getInt(), getLong(), getFloat(), getDouble() und weitere Methoden liefern 0; getBoolean() liefert ein false, und bei anderen Methoden sieht es ähnlich aus – keine Methode löst eine Ausnahme aus. Die Behandlung von Nullwerten ist in JDBC recht ungewöhnlich gelöst. Wir würden erwarten, dass es eine Methode isNull(column) auf einem ResultSet-Objekt gibt, die uns ja oder nein liefert hinsichtlich der Frage, ob ein Spalteninhalt unbelegt ist. Dass die Methode wasNull() heißt, ist vielleicht noch zu verkraften, aber dass sie parameterlos ist, erstaunt.
1175
16
16
Datenbankmanagement mit JDBC
Beispiel Die allgemeine Vorgehensweise für einen SQL-NULL-Test am Beispiel einer String-Abfrage ist: String s = rs.getString( column ); if ( rs.wasNull() ) System.out.println( "SQL-NULL" );
interface java.sql.ResultSet extends Wrapper, AutoCloseable Þ boolean wasNull()
Ermittelt, ob die Spalte ein SQL-NULL enthält. Vorher muss eine getXXX()-Methode für die Spalte aufgerufen werden!
16.6.7 Wie viele Zeilen hat ein ResultSet? * Um herauszufinden, wie viele Zeilen ein ResultSet liefern kann, lassen sich trickreiche JDBC 2Eigenschaften nutzen. Soll in der Variablen row die Anzahl der Zeilen stehen, schreiben wir: rs.last(); int rows = rs.getRow(); rs.beforeFirst();
Bei dieser Programmierung muss natürlich ein Treiber JDBC 2-fähig sein und scrollbare Cursor unterstützen, das heißt Cursor, die auch rückwärts laufen können. Gleichzeitig muss dann aber auch beim Aufbau eines Statement-Objekts ein scrollbarer Cursor angemeldet werden: stmt = con.createStatement( ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_UPDATABLE );
Unterstützt ein Treiber kein JDBC 2, kann immer noch über eine Zeile wie SELECT COUNT(*) erfragt werden, wie viele Ergebnisse die Datenbank produziert.
16.7
Elemente einer Datenbank hinzufügen und aktualisieren
Bisher haben wir executeQuery() benutzt, um Abfragen zu verfassen. Es lassen sich jedoch auch Einfüge-Operationen vornehmen, denn Tabelleninhalte bleiben nicht unveränderlich.
1176
16.7
Elemente einer Datenbank hinzufügen und aktualisieren
Das SQL-Kommando INSERT fügt Daten ein, und UPDATE aktualisiert sie. Damit Spalten verändert werden können, müssen wir in zwei Schritten vorgehen: 1. eine SQL-Anweisung mit einem UPDATE aufbauen und 2. anschließend executeUpdate() aufrufen. Damit wird die Änderung wirksam. Dies ist eine andere Statement-Methode, bisher kannten wir nur executeQuery(). Neben den Methodennamen gibt es aber noch einen anderen Unterschied: executeUpdate() liefert als Rückgabewert ein int, das angibt, wie viele Zeilen von der Änderung betroffen sind.
Beispiel Folgende SQL-Anweisung ändert die Adresse eines Lieferanten einer fiktiven Relation: String updateString = "UPDATE Lieferanten SET Adresse = " + "'Uferstraße 80' WHERE Adresse LIKE 'Uferstrasse 78'"; stmt.executeUpdate( updateString );
Die Methode gibt uns immer zurück, wie viele Zeilen von den Änderungen betroffen sind. Sie ist 0, falls das SQL-Statement nichts bewirkt. interface java.sql.Statement
16
extends Wrapper, AutoCloseable Þ int executeUpdate(String sql) throws SQLException
Führt eine SQL-Anweisung aus, die Manipulationen an der Datenbank vornimmt. Die SQLAnweisungen sind in der Regel INSERT-, UPDATE- oder DELETE-Anweisungen. Zurückgegeben wird die Anzahl der veränderten Zeilen, oder null, falls eine SQL-Anweisung nichts verändert hat.
16.7.1
Batch-Updates
Das Einfügen und Ändern großer Mengen von Daten kostet viel Zeit, da für jede Modifikation ein INSERT oder UPDATE über ein Statement-Objekt abgewickelt werden muss. Eine Verbesserung stellen Batch-Updates dar, die in einem Rutsch gleich eine ganze Reihe von Daten zur Datenbank transferieren. Statt mit execute() und deren Varianten zu arbeiten, nutzen wir die Methode executeBatch(). Damit zuvor die einzelnen Aktionen dem Statement-Objekt mitgeteilt werden können, bietet die Klasse die Methoden addBatch() und clearBatch() an. Die Datenbank führt die Anweisungen in der Reihenfolge aus, wie sie im Batch-Prozess eingefügt wurden. Ein Fehler wird über eine BatchUpdateException angezeigt.
1177
16
Datenbankmanagement mit JDBC
Beispiel Wir fügen einige Einträge der Datenbank als Batch hinzu. con sei unser Connection-Objekt: int[] updateCounts = null; try { Statement s = con.createStatement(); s.addBatch( "INSERT INTO Lieferanten VALUES (x,y,z)" ); s.addBatch( "INSERT INTO Lieferanten VALUES (a,b,c)" ); s.addBatch( "INSERT INTO Lieferanten VALUES (d,e,f)" ); updateCounts = s.executeBatch(); } catch ( BatchUpdateException e ) { /* Behandeln! */ } catch ( SQLException e ) { /* Behandeln! */ }
Nach dem Abarbeiten von executeBatch() erhalten wir als Rückgabewert ein int-Feld mit den Ergebnissen der Ausführung. Dies liegt daran, dass in der Batch-Verarbeitung ganz unterschiedliche Anweisungen vorgenommen werden können und jede davon einen unterschiedlichen Rückgabewert verwendet. Soll der gesamte Ablauf als Transaktion gewürdigt werden, so setzen wir im try-Block den AutoCommit-Modus auf false, damit nicht jede SQL-Anweisung als einzelne Transaktion gewertet wird. Im Fall eines Fehlers müssen wir im catch-Block ein Rollback ausführen. Übertragen wir dies auf das obere Beispiel, dann müssen nur die beiden Anweisungen für die Transaktion eingesetzt werden: try { con.setAutoCommit( false ); Statement s ..... ... } catch ( BatchUpdateException e ) { con.rollback(); }
1178
16.7
16.7.2
Elemente einer Datenbank hinzufügen und aktualisieren
Die Ausnahmen bei JDBC, SQLException und Unterklassen
Normale Ausnahmen in Java tragen lediglich eine Nachricht, die sich mit getMessage() erfragen lässt. Da bei Datenbanken aber viele Dinge schiefgehen können, hätten die Architekten der JDBC-API viel zu tun, wenn sie für jede mögliche Ausnahme eine Exception-Klasse bereitstellen wollten. Doch wegen der schier unüberschaubaren Anzahl an Fehlern haben sie sich für ein anderes Modell entschieden.
JDBC-Fehlerbasisklasse SQLException Zunächst einmal gibt es für JDBC-Ausnahmen den Basistyp SQLException. Zusätzlich speichert jedes SQLException-Objekt Fehlercodes, die der JDBC-Treiber der Datenbank setzen und so über den konkreten Fehler informieren kann. Die genauen Informationen einer SQL-Ausnahme sind über drei Methoden zugänglich: Þ String getMessage(): eine textuelle Beschreibung des Fehlers Þ String getSQLState(): Einen String mit dem SQL-Status. Hier gibt es zwei Konventionen.
Einmal kann es ein SQL-Status nach der SQL-CLI-Spezifikation der Open Group (vor über zehn Jahren hieß sie X/Open) sein – oder ein SQL:2003-Code. Beide sind datenbankunabhängig. Nach welcher Spezifikation der Code formuliert ist, sagt die Methode getSQLStateType() vom DatabaseMetaData-Objekt. Der Open-Group-Standard ist üblich. Þ int getErrorCode(): Ein Fehler-Code vom JDBC-Treiber. Er kommt vom Hersteller der Daten-
bank bzw. vom Datenbanktreiber. Er ist datenbankabhängig. Der Open-Group-SQL-Status ist eigentlich eine Zahl, aber als String verpackt. Im Optimalfall ist der Code »00000«, was »Alles paletti« heißt. Die ersten beiden Ziffern stehen für die Fehlerklasse. 01 ist eine Warnung, 02 sagt, dass Daten fehlen, usw.2
Eine Verkettung unglücklicher Tatsachen Eine SQLException hat eine Besonderheit, die sonst keine Ausnahme in der Java-Bibliothek aufweist. Sie implementiert die Schnittstelle Iterable: class java.sql.SQLException extends Exception implements Iterable
2
Unter ftp://ftp.software.ibm.com/ps/products/db2/info/vr6/htm/db2m0/db2state.htm bekommen Leser einen Überblick.
1179
16
16
Datenbankmanagement mit JDBC
Das heißt, dass eine SQLException ein Bündel von Ausnahmen repräsentieren kann und nicht nur genau eine. Welche JDBC-Ausnahmen noch an der SQLException hängen, liefert getNextException() bzw. steckt im Iterator der SQLException.
Beispiel Laufe alle Fehler ab: try { ... } catch ( SQLException e ) { for ( ; e != null; e = e.getNextException() ) { System.err.println( "Message:
" + e.getMessage() );
System.err.println( "SQL State: " + e.getSQLState() ); System.err.println( "Error Code: " + e.getErrorCode() ); } }
SQLWarning Nicht jeder Fehler bzw. jede Meldung der Datenbank ist gleich ein kritischer Fehler, der zum Abbruch der Datenbankoperationen führt. Die JDBC-API bietet mit der Klasse SQLWarning eine besondere Unterklasse von SQLException, doch wird sie nicht als Exception ausgelöst, sondern muss im Programm explizit über getWarnings() geholt werden. Die Typen Connection, ResultSet und Statement deklarieren diese Operation. Im besten Fall holen sich Entwickler alle Warnungen und loggen sie. Da die SQLWarning eine SQLException ist, ist auch die Verarbeitung von SQL-Code und Fehlercode gleich. Anstatt jedoch mit getNextException() zu arbeiten, bietet SQLWarning die Methode getNextWarning() um zur nächsten Warnung vorzustoßen. Werden die Meldungen nicht geholt, dann werden sie bei der Ausführung der nächsten SQL-Anweisung gelöscht.
Daten fehlen Für den SQL-Status »01004« und »22001« gibt es eine eigene Fehlerklasse, die DataTruncation. Sie ist ein spezieller Typ einer SQL-Warnung und wird immer dann erzeugt, wenn Daten während der Schreib- oder Leseoperationen verloren gingen. Die Meldung wird genauso geholt wie SQLWarning, nur wird mittels instanceof DataTruncation überprüft, ob es sich um DataTruncation handelt. Dies erfordert eine Typumwandlung von SQLWarning auf DataTruncation. Dann stehen Methoden wie getIndex() oder getTransferedSize() bereit, die aussagen, für welche
1180
16.7
Elemente einer Datenbank hinzufügen und aktualisieren
Spalte wie viel Bytes korrekt übertragen wurden. DataTruncation ist die einzige Unterklasse von SQLWarning.
16
Abbildung 16.17: Vererbungshierarchie der JDBC-Fehlerklassen
1181
16
Datenbankmanagement mit JDBC
16.8 ResultSet und RowSet * Ein ResultSet haben wir als Lieferanten von Zeileninformationen kennengelernt. Mit einem Cursor konnten wir über Zeilen laufen und auch scrollen, wenn positionierbare Cursor angemeldet waren. Updates waren ebenfalls möglich. Ein ResultSet ist allerdings kein Datencontainer, vergleichbar mit einer Liste, die alle Daten bei sich hat. Das ResultSet muss immer eine Verbindung mit der Datenbank haben, und ein Aufruf von next() könnte sich die Zeileninformationen immer von der Datenbank besorgen. Ein ResultSet ist also kein Container, der Daten speichert. Aus diesem Grund implementiert ResultSet auch nicht die Schnittstelle Serializable.
16.8.1
Die Schnittstelle RowSet
Mittlerweile gibt es die Schnittstelle javax.sql.RowSet, die von interessanten Klassen implementiert wird. Ein RowSet ist ein ResultSet – das heißt, die Schnittstelle RowSet erbt von ResultSet – und schreibt weiteres Verhalten vor. In erster Linie ist sie als Container für Daten gedacht. Da sie ein ResultSet ist, kann sie natürlich alles, was ein normales ResultSet auch kann: mittels getXXX() Daten besorgen und mit updateXXX() Daten aktualisieren. Aber als Container verhält sie sich wie eine JavaBean, und an sie lassen sich Listener hängen. Sie informieren, wann etwa Elemente eingeführt oder gelöscht werden. Falls es beispielsweise eine Visualisierung gibt, kann sie sich abhängig von den Veränderungen immer informieren lassen und die neuen Werte anzeigen. Zwar kann ein scrollendes ResultSet auch den Cursor nach oben bewegen und ihn an eine beliebige Position setzen, das RowSet kann das aber immer, auch wenn das ResultSet diese Eigenschaft nicht hat. Zusätzlich lässt sich ein RowSet auch serialisieren und ist prinzipiell nicht an Datenbanken gebunden, und die Daten können auch von einer Excel-Tabelle kommen. Jedes RowSet hat seine eigenen Metadaten, die durch ein RowSetMetaDataImpl-Objekt implementiert werden.
16.8.2 Implementierungen von RowSet Um ein RowSet aufzubauen, gibt es unterschiedliche Implementierungen. Da es ein Aufsatz auf die JDBC-API ist, ist es auch nicht mit einem Treiber verbunden, sondern kann unabhängig vom Treiber implementiert werden – die Umsetzung ist generisch. Auch gibt es nicht nur ein RowSet, sondern wir unterscheiden zwischen verschiedenen Typen, die als Unterschnittstellen von javax.sql.RowSet im Paket javax.sql.rowset deklariert sind: Þ JDBCRowSet ist ein kleiner Wrapper um das ResultSet, um es als JavaBean zugänglich zu ma-
chen. Eine Verbindung zur Datenbank muss bestehen.
1182
16.8
ResultSet und RowSet *
Þ Ein CachedRowSet benötigt initial eine Verbindung zur Datenbank, um mit einer SQL-Anwei-
sung automatisch alle Daten zu lesen. Anschließend ist keine Verbindung zur Datenbank nötig, wobei geänderte Daten später zurückgespielt werden können. Das ist perfekt in solchen Fällen, in denen Daten auf ein mobiles Endgerät wandern, dort Änderungen erfahren und diese später wieder eingespielt werden sollen. Þ Ein WebRowSet erweitert CachedRowSet und bildet Daten und Operationen in XML ab, um sie
zum Beispiel für Web-Services übertragen zu können. Þ Das FilteredRowSet ist ein WebRowSet und ermöglicht eine zusätzliche Selektion mit Prädika-
ten. Þ Ein JoinRowSet ist ebenfalls ein spezielles WebRowSet, das Daten unterschiedlicher RowSet-
Schnittstellen wie über ein SQL-JOIN verbinden kann. Seit Java 7 liefert der RowSetProvider.createFactory() eine Implementierung von RowSetFactory, das mit unterschiedlichen createXXXRowSet()-Methoden die Row-Sets liefert. Vor Version 7 liefert Java zwar Implementierungen der RowSet-Schnittstellen mit, doch das waren com.sun.rowset.XXXSetImpl-Klassen. Einige Datenbankhersteller liefern eigene Implementierungen mit aus, die vor Java 7 dann explizit angesprochen werden mussten.
16.8.3 Der Typ CachedRowSet Um ein CachedRowSet aufzubauen, das keine dauerhafte Verbindung zur Datenbank benötigt, ist zunächst mit RowSetProvider.newFactory().createCachedRowSet() ein Implementierung von CachedRowSet aufzubauen. Anschließend ist dem Objekt zu sagen, welcher Datenbank welche Daten zu entnehmen sind. Wie üblich muss vorher der Treiber geladen sein: Listing 16.7: com/tutego/insel/jdbc/CachedRowSetDemo.java, main() CachedRowSet crset = RowSetProvider.newFactory().createCachedRowSet(); crset.setDataSourceName( "TutegoDS" ); crset.setCommand( "SELECT * FROM Customer" ); crset.execute();
Kommen die Daten nicht aus einer DataSource, bestimmt setUrl() die JDC-URL. In beiden Fällen können setUsername() und setPassword() den Benutzernamen und das Passwort angeben. Damit die Bean weiß, welche Daten sie aufnehmen soll, ist eine SQL-Anweisung zu formulieren. Der Aufruf execute() füllt das CachedRowSet (mit einem Logger lässt sich gut beobachten, dass die Datenbankverbindung auf- und dann wieder abgebaut wird). Falls eine Verbindung zur Datenbank schon besteht, kann bei execute() auch ein Connection-Objekt übergeben werden. Das CachedRowSet führt dann die gesetzte Anweisung über die bestehende Connection aus und überträgt die Daten aus der Datenbank in die Bean.
1183
16
16
Datenbankmanagement mit JDBC
Wie aus ResultSet bekannt ist, lässt sich mit next() durch die Ergebnismenge eines RowSet iterieren: while ( crset.next() ) System.out.println( crset.getString(1) ); crset.close();
Eine Position zurück geht previous(). Absolute Positionierung ist erlaubt und mit der Methode absolute(int position) möglich. Die aktuelle Zeile liefert getRow(), und die Anzahl geladener Zeilen liefert size(). Mit den updateXXX()-Methoden lassen sich Zeilen ändern. Vor einer Bewegung des Cursors muss updateRow() die Änderung bestätigen. Grundsätzlich müssen Änderungen mit setConcurrency() angekündigt sein, denn der Standardmodus ist ResultSet.CONCUR_READ_ONLY: crset.setConcurrency( ResultSet.CONCUR_UPDATABLE );
Änderungen werden an die Datenbank nur mit einer speziellen Methode zurückgeschrieben, die in der Regel am Ende aller Operationen aufgerufen wird: acceptChanges(). Spätestens dann muss es wieder eine Verbindung zur Datenbank geben. crset.acceptChanges();
Veränderte Werte werden dann in der Datenbank aktualisiert und überschrieben. Wiederum ist auch eine Variante mit einem Connection-Parameter implementiert, die die Daten zu einer existierenden Datenbankverbindung schreibt.
16.8.4 Der Typ WebRowSet Das WebRowSet schreibt zusätzlich zur Oberschnittstelle CachedRowSet nur zwei Arten von Operationen vor: readXml() und writeXml(). Die Lese-Methoden übertragen aus unterschiedlichen Datenquellen – etwa InputStream oder Reader – die Daten auf das WebRowSet. Die Schreibmethoden schreiben das RowSet in einen OutputStream oder Writer: Listing 16.8: com/tutego/insel/jdbc/WebRowSetDemo.java, main() WebRowSet data = RowSetProvider.newFactory().createWebRowSet(); data.setDataSourceName( "TutegoDS" ); data.setCommand( "SELECT * FROM Customer" ); data.setMaxRows( 2 ); data.execute(); data.writeXml( System.out ); data.close();
1184
16.8
ResultSet und RowSet *
Die (gekürzte) Ausgabe sieht so aus:
SELECT * FROM Customer 1008 TutegoDS true 1000 0 2
0
16
2 0 true ResultSet.TYPE_SCROLL_INSENSITIVE false Customer
com.sun.rowset.providers. RIOptimisticProvider Sun Microsystems Inc. 1.0 2 1
5
1185
16
Datenbankmanagement mit JDBC
1 false false false 0 true true 11 ID ID PUBLIC 10 0 CUSTOMER
4 INTEGER
... ... ... ...
0 Laura Steel 429 Seventh Av. Dallas
1 Susanne King 366 – 20th Ave.
1186
16.9
Vorbereitete Anweisungen (Prepared Statements)
Olten
16.9 Vorbereitete Anweisungen (Prepared Statements) Die SQL-Anweisungen, die mittels execute(), executeQuery() oder executeUpdate() an die Datenbank gesendet werden, haben bis zur Ausführung im Datenbanksystem einige Umwandlungen vor sich. Zuerst müssen sie auf syntaktische Korrektheit getestet werden. Dann werden sie in einen internen Ausführungsplan der Datenbank übersetzt und mit anderen Transaktionen optimal verzahnt. Der Aufwand für jede Anweisung ist messbar. Deutlich besser wäre es jedoch, eine Art Vorübersetzung für SQL-Anweisungen zu nutzen. Diese Vorübersetzung ist eine Eigenschaft, die JDBC unterstützt und die sich Prepared Statements nennt. »Vorbereitet« (engl. prepared) deshalb, weil die Anweisungen in einem ersten Schritt zur Datenbank geschickt und dort in ein internes Format umgesetzt werden. Später verweist ein Programm auf diese vorübersetzten Anweisungen, und die Datenbank kann sie schnell ausführen, da sie in einem optimalen Format vorliegen. Ein Geschwindigkeitsvorteil macht sich immer dann besonders bemerkbar, wenn Schleifen Änderungen an Tabellenspalten vornehmen. Dies kann durch die vorbereiteten Anweisungen schneller geschehen.
Hinweis Nicht jedes Datenbanksystem unterstützt Prepared Statements.
16.9.1
PreparedStatement-Objekte vorbereiten
Wie createStatement() auf einem Connection-Objekt ein Statement-Objekt aufbaut, so legt prepareStatement() ein PreparedStatement-Objekt an. Als Argument wird eine SQL-Zeichenkette
übergeben, die den gleichen Aufbau wie etwa ein executeUpdate() hat. Einen Unterschied werden wir jedoch feststellen: Bei den normalen Statement-Objekten können wir dynamische Einträge einfach in den String mit einbauen. Dies geht bei vorbereiteten Anweisungen nicht mehr. Woher sollte auch die Anweisung wissen, was der Benutzer in seine Eingabemaske tippt? Damit jetzt auch eine vorbereitete Anweisung Parameter enthalten kann, werden in die Zeichenkette Platzhalter mit einem Fragezeichen eingefügt.
1187
16
16
Datenbankmanagement mit JDBC
Beispiel Aufbau eines PreparedStatement-Objekts mit einem parametrisierten String: PreparedStatement updateLieferant = con.prepareStatement( "UPDATE Lieferanten SET Adresse = ? WHERE Adresse LIKE ?" );
Abbildung 16.18: PreparedStatement ist ein besonderes Statement.
1188
16.9
Vorbereitete Anweisungen (Prepared Statements)
Die Zeile instruiert die Datenbank, die Zeile zu interpretieren, in das interne Format umzusetzen und vorbereitet zu halten. Im nächsten Schritt muss die Anweisung für die Platzhalter Werte einsetzen.
16.9.2 Werte für die Platzhalter eines PreparedStatement Bevor die executeUpdate()-Methode die vorbereitete Anweisung abarbeitet, müssen die Platzhalter gefüllt werden. Dazu bietet das PreparedStatement-Objekt für die Datentypen jeweils eine setXXX()-Methode an, die den Wert für einen angegebenen Platzhalter setzt. So wird setInt(1,100) die Zahl 100 für das erste Fragezeichen einsetzen. Nach der Zuweisung ist das Objekt für die Ausführung bereit. executeUpdate() kann aufgerufen werden: PreparedStatement updateLieferant = con.prepareStatement( "UPDATE Lieferanten SET Adresse = ? WHERE Adresse LIKE ?" ); updateLieferant.setString( 1, "Uferstraße 80" ); updateLieferant.setString( 2, "Uferstrasse 78" ); updateLieferant.executeUpdate();
Vergleichen wir diese Zeilen mit der Lösung ohne PreparedStatement: String updateString = "UPDATE Lieferanten SET Adresse = 'Uferstraße 80' " +
16
"WHERE Adresse LIKE 'Uferstrasse 78'"; stmt.executeUpdate( updateString );
Die Anweisung ist zwar etwas kürzer, aber dadurch mit der notwendigen Übersetzungszeit verbunden, insbesondere dann, wenn sich die Werte ändern. In einer Schleife lässt sich nun immer wieder executeUpdate() aufrufen, und die schon gesetzten Parameter werden übernommen. Ein Aufruf von clearParameters() löscht alle Parameter. PreparedStatement updateLieferant = con.prepareStatement( "UPDATE Lieferanten SET Adresse = ? WHERE Adresse LIKE ?" ); updateLieferant.setString( 1, "Uferstraße 80" ); updateLieferant.setString( 2, "Uferstrasse 78" ); updateLieferant.executeUpdate(); updateLieferant.setString( 1, "Sommerstraße 23" ); updateLieferant.setString( 2, "Sommerstrasse 23" ); updateLieferant.executeUpdate();
1189
16
Datenbankmanagement mit JDBC
16.10 Transaktionen Transaktionen sind für Datenbanken ein sehr wichtiges Konzept, denn nur so bleibt die Integrität der Daten erhalten. Transaktionen sind mit einer atomaren Ausführung bei Threads vergleichbar, mit dem Unterschied, dass die Datenbank inmitten einer gescheiterten Transaktion die bisher veränderten Werte rückgängig macht. In der Standardverarbeitung in JDBC wird jede SQL-Anweisung für sich als Transaktion abgearbeitet. Dies nennt sich Auto-Commit. Um jedoch eine Folge von Anweisungen in einer Transaktion auszuführen, muss zunächst das Auto-Commit zurückgesetzt werden. Dann werden die Datenbankmanipulationen ausgeführt, und die Transaktion kann anschließend abgeschlossen (commit) oder zurückgesetzt (rollback) werden.
Beispiel Datenbankoperationen sollen in einer Transaktion ausgeführt werden: con.setAutoCommit( false ); // Datenbankmanipulationen vornehmen con.commit(); con.setAutoCommit( true );
// Standard wiederherstellen
Tritt ein Fehler auf, können wir mit con.rollback() die gestartete Transaktion zurücksetzen. Dann ist es lohnenswert, eine Ausnahmebehandlung zu schreiben und im catch das rollback() einzusetzen.
16.11
Metadaten *
Von einer Datenbank können verschiedene Informationen ausgelesen werden. Zum einen sind dies Informationen zu einer bestimmten Tabelle, zum anderen Informationen über die Datenbank selbst.
16.11.1
Metadaten über die Tabelle
Bei der Abfrage über alle Spalten müssen wir die Struktur der Datenbank kennen, insbesondere dann, wenn wir allgemeine Abfragen vornehmen und die passenden Daten herauslesen wollen. So liefert SELECT * FROM Item ein ResultSet mit der Anzahl der Spalten, wie sie die Tabelle Item hat. Doch bevor wir nicht die Anzahl und die Art der Spalten kennen, können wir nicht auf die Daten zugreifen.
1190
16.11
Metadaten *
Um diese Art von Informationen, sogenannte Metadaten, in Erfahrung zu bringen, befindet sich die Klasse ResultSetMetaData, mit der wir diese Informationen erhalten, unter den SQLKlassen. Metadaten können für jede Abfrage angefordert werden. So lässt sich unter anderem leicht herausfinden: Þ wie viele Spalten wir in einer Zeile abfragen können Þ wie der Name der Spalte lautet Þ welchen SQL-Typ die Spalte hat Þ ob NULL für eine Spalte in Ordnung ist Þ wie viele Dezimalzeichen eine Spalte hat
Einige Informationen über die Bestellelemente Um Anzahl und Art der Spalten einer Bestelltabelle herauszufinden, werden wir zunächst ein ResultSet mit stmt.executeQuery("SELECT * FROM Item") erzeugen und dann via getMetaData() ein ResultSetMetaData-Objekt erfragen. Das ResultSetMetaData-Objekt besitzt viele Methoden, um Aussagen über die Tabelle und Spalten zu treffen. So fragen wir mit getColumnCount() nach, wie viele Spalten die Tabelle hat. Anschließend lässt sich für jede Spalte der Name und Typ erfragen: Listing 16.9: com/tutego/insel/jdbc/TableMetaData.java, main()
16
Connection con = ((DataSource) new InitialContext().lookup( "TutegoDS" )).getConnection(); try { ResultSet rs = con.createStatement().executeQuery( "SELECT * FROM ITEM" ); ResultSetMetaData meta = rs.getMetaData(); int numerics = 0; for ( int i = 1; i >, um für alle Tabellen Entity-Beans zu generieren (siehe Abbildung 16.20).
1199
16
16
Datenbankmanagement mit JDBC
Abbildung 16.19: NetBeans-Dialog zum Anlegen neuer Entity-Klassen
Abbildung 16.20: Tabellen für den Quellcode-Generator hinzufügen
Nach Next erscheint ein neuer Dialog. Einstellungen sind nur beim Paket nötig. Ich wähle com.tutego.insel.jpa:
1200
16.13
JPA-Beispiel mit der NetBeans-IDE
Abbildung 16.21: Wählen des Paketnamens und Abschluss des Dialogs
Danach ist ein Finish fällig.
16 16.13.2
Die Quellen im Überblick
Der Generator hat eine ganze Reihe von Dateien generiert und Eintragungen gemacht: Þ Neue Java-Archive stehen im Klassenpfad. Sie enthalten die JPA-Annotationen und den
JPA-Provider EclipseLink (die Referenzimplementierung für JPA). Þ Die Entity-Bean-Klassen wurden generiert – ihr Name stammt vom Tabellennamen. Þ Ein META-INF-Verzeichnis führt die Datei persistence.xml auf.
Abbildung 16.22: Generierte Dateien
1201
16
Datenbankmanagement mit JDBC
Die Customer-Klasse repräsentiert die CUSTOMER-Tabelle. Ein Ausschnitt aus der Datei sieht so aus: @Entity @Table(name = "CUSTOMER") @NamedQueries({ @NamedQuery(name = "Customer.findAll", query = "SELECT c FROM Customer c"), @NamedQuery(name = "Customer.findByCustomerId", query = "SELECT c FROM Customer c
ð
WHERE c.customerId = :customerId"), ... @NamedQuery(name = "Customer.findByCreditLimit", query = "SELECT c FROM Customer c WHERE c.creditLimit = :creditLimit")}) public class Customer implements Serializable { private static final long serialVersionUID = 1L; @Id @Basic(optional = false) @Column(name = "CUSTOMER_ID") private Integer customerId; @Basic(optional = false) @Column(name = "ZIP") private String zip; ... public Customer() { } ... public Integer getCustomerId() { return customerId; } public void setCustomerId(Integer customerId) { this.customerId = customerId; }
1202
ð
16.13
JPA-Beispiel mit der NetBeans-IDE
public String getZip() { return zip; } public void setZip(String zip) { this.zip = zip; } ... }
Es lässt sich festhalten, dass es für jede Spalte in der Tabelle ein Attribut und Setter/Getter gibt. Die anderen Beans sehen im Prinzip genauso aus.
16.13.3
Persistence Unit
Die Datei im META-INF-Vezeichnis ist eine sogenannte PU-Datei (für Persistence Unit). Sie zählt alle Klassen auf und enthält die Zugangsdaten zur Datenbank.
16
Abbildung 16.23: Editor mit persistence.xml
Der Persistence-Unit-Name ist InselPU, und diesen Namen brauchen wir später noch.
1203
16
Datenbankmanagement mit JDBC
16.13.4
Ein JPA-Beispielprogramm
Der NetBeans-Editor hat extra einen eigenen Menüpunkt für JPA, sodass es einfach ist, ein kleines Beispiel aufzubauen. Beginnen wir mit einer Standard-Klasse. (Das geht in NetBeans über File 폷 New File... 폷 Java 폷 Java Class.) Nennen wir die Klasse JpaDemo. Daraufhin öffnet sich der Editor mit der neuen Klasse. import com.tutego.insel.jpa.Customer; import com.tutego.insel.jpa.DiscountCode; import javax.persistence.EntityManager; import javax.persistence.EntityManagerFactory; import javax.persistence.Persistence; public class JpaDemo { public static void main( String[] args ) { EntityManagerFactory emf = Persistence.createEntityManagerFactory( "InselPU" ); EntityManager em = emf.createEntityManager(); try { DiscountCode discountCode = em.find( DiscountCode.class, 'H' ); Customer customer1 = new Customer( 888 ); customer1.setName( "Chris" ); customer1.setZip( "999" ); customer1.setDiscountCode( discountCode ); em.getTransaction().begin(); em.persist( customer1 ); em.getTransaction().commit(); String query = "SELECT c FROM Customer c"; for ( Customer c : em.createQuery( query, Customer.class ).getResultList() ) System.out.println( c.getName() ); } catch ( Exception e ) { e.printStackTrace(); em.getTransaction().rollback();
1204
16.14
Zum Weiterlesen
} finally { em.close(); } } }
Das Programm besorgt sich Zugang zum OR-Mapper – vereinfacht gesagt repräsentiert als EntityManager-Objekt. Der EntityManager bietet Methoden wie persist() zum Speichern oder find() zum Suchen. Der erste JPA-Code erfragt ein DiscountCode-Objekt, was mit der ID 'H' in der Datenbank steckt. Mit diesem Discount-Code legen wir einen neuen Kunden an. Anschließend geben wir alle Kunden aus, und der neue Kunde ist natürlich dabei: JumboCom Livermore Enterprises Oak Computers Nano Apple HostProCom CentralComp Golden Valley Computers
16
Top Network Systems West Valley Inc. Ford Motor Co Big Car Parts New Media Productions Yankee Computer Repair Chris
Wenn es einen Fehler der Art »Exception in thread "main" javax.persistence.PersistenceException: Exception [EclipseLink-4003] (Eclipse Persistence Services – 2.2.0.v20110202-r8913): org.eclipse.persistence.exceptions.DatabaseException« gibt, dann fehlt der JDBC-Treiber für die Derby-Datenbank; Abschnitt 16.4.3 erklärt, wie er einzubinden ist.
16.14
Zum Weiterlesen
Direkter Datenbankzugriff über JDBC ist heutzutage selten. Gut entworfene Programme nutzen im Allgemeinen OR-Mapper, also Bibliotheken, die Java-Objekte auf die Datenbank-
1205
16
Datenbankmanagement mit JDBC
relationen abbilden. Eine Standard-API für objekt-relationale Abbildungen ist die Java Persistence API (JPA) – eine kurze Charakterisierung gibt es unter http://www.oracle.com/technetwork/java/javaee/documentation/index.html. Eine JPA-Implementierung heißt Provider, übernimmt die Abbildung auf die Datenbank und bietet Methoden zum Erzeugen, Lesen, Aktualisieren und Löschen von Datensätzen an (sogenannte CRUD-Operationen). JPA ist Teil von Java EE 5, aber auch ohne Enterprise Container verwendbar. Die beliebte Open-Source-Software Hibernate (http://www.hibernate.org/), die von JBoss (also Red Hat) finanziell unterstützt wird, implementiert die JPA und bietet darüber hinausgehende Funktionalität. Dass jedoch auch hier Ungemach von der Patentseite droht, diskutiert http://www.patentlyo.com/ patent/2006/06/red_hat_faces_p.html.
1206
Kapitel 17 Technologien für die Infrastruktur »Wenn einer keine Angst hat, hat er keine Phantasie.« – Erich Kästner (1899–1974)
17.1
Property-Validierung durch Bean Validation
In den Settern einer JavaBean konnten wir mithilfe der PropertyChangeEvents Änderungen melden. Gleichsam kann ein Listener gegen eine ungewünschte Belegung sein Veto einlegen. Wenn eine Property selbst einen bestimmten Wert nicht annehmen kann, kann sie gut eine IllegalArgumentException melden. Die Validierung innerhalb von Settern ist aber nur lokal und nicht besonders flexibel, wenn es zum Beispiel Abhängigkeiten zwischen den Properties gibt oder temporäre Falschbelegungen erlaubt sein sollten. So lässt sich ein anderer Weg einschlagen, nämlich dass zunächst eine Property mit allen möglichen Werten initialisiert werden darf (also auch das Alter einer Person mit 1000) und erst später das Objekt zu einem Validator gegeben wird, der schaut, ob Property-Belegungen erlaubt sind. Seit Java EE 6 gibt es hier einen Standard, der im JSR-303, »Bean Validation«, beschrieben ist. An die Properties werden Annotationen gesetzt, die zum Beispiel erlaubte Minimal-/Maximalwerte für Zahlen bestimmen oder reguläre Ausdrücke für gültige Stringbelegungen. Dieses Vorgehen ist deklarativ und kommt ohne Programmierung aus. Im zweiten Schritt wird ein Validierer auf die Bean angesetzt, der die Zustände selbstständig ausliest und auf die Einschränkungen testet.
Bezug der JSR-303-Referenz-Implementierung Jeder Java EE 6-Container bringt bereits eine Implementierung mit. Da Java 7 nicht mit einer Implementierung der JSR-303 daherkommt, muss sie extra installiert werden. Die Referenzimplementierung hat ihr Zuhause bei http://www.hibernate.org/subprojects/validator.html, und der Download befindet sich unter http://sourceforge.net/projects/hibernate/files/hibernate-validator. Im Zip-Archiv hibernate-validator-4.2.0.Final-dist.zip (etwa 16 MiB groß) stehen mehrere Jar-Dateien, die wir in den Klassenpfad aufnehmen müssen:
1207
17
17
Technologien für die Infrastruktur
Þ Zunächst ist es validation-api-1.0.0.GA.jar im Verzeichnis lib\required, das die neuen
Annotationen wie @NotNull, @Size, @Pattern, ... deklariert. Þ Dann folgt mit hibernate-validator-4.0.2.GA.jar die eigentliche Implementierung des
Frameworks.
Eine Person, die nie null heißen durfte Hat ein Spieler einen Namen und ein Alter, so lassen sich leicht erste Gültigkeitsregeln aufstellen. Der Name soll gesetzt sein, also nicht null sein, und das Alter soll zwischen 10 und 110 liegen. Genau diese sogenannten Constraints werden über Annotationen an die Objektvariablen oder Getter gesetzt. Listing 17.1: com/tutego/insel/bean/validation/Player.java, Player import javax.validation.constraints.*; public class Player { private String name; @Min(10) @Max(110) private int
age;
public void setName( String name ) { this.name = name; } @NotNull public String getName() { return name; } public void setAge( int age ) { this.age = age; }
1208
17.1
Property-Validierung durch Bean Validation
public int getAge() { return age; } }
Die Annotation @NotNull sagt aus, dass getName() nie null liefern darf, und @Min(10)/@Max(110) besagt, dass sich age zwischen 10 und 110 (jeweils inklusiv) bewegen muss. Dass @Min(10) vor @Max(110) geschrieben wird, ist unwichtig, denn die Reihenfolge beim Prüfen ist unbestimmt. Ob die Annotation an den Attributen oder Gettern der Property sitzt, ist egal; im ersten Fall greift das Validierungsframework direkt auf das Attribut zu, und sind die Getter annotiert, wird die getXXX()-Methode aufgerufen. Die Sichtbarkeit der Objektvariablen spielt keine Rolle. Statische Variablen können nicht annotiert und geprüft werden.
Durchführen der Validierung Das Beispiel zeigt die erste Hälfte der JavaBean Validation: die deklarative Angabe von gültigen Belegungen. Die zweite Hälfte von Validiation besteht aus einer API, damit die tatsächliche Überprüfung auch stattfinden kann und Fehler der einzelnen Properties erkannt werden. Listing 17.2: com/tutego/insel/bean/validation/PlayerValidatorDemo.java, main() Teil 1
17
Player p = new Player(); Validator validator = Validation.buildDefaultValidatorFactory().getValidator(); Set constraintViolations = validator.validate( p ); for ( ConstraintViolation violation : constraintViolations ) System.out.println( violation.getPropertyPath() + " " + violation.getMessage() );
Der Player wird nicht korrekt mit einem Namen und einem Alter initialisiert, sodass zwei Fehler zu erwarten sind. Die tatsächliche Überprüfung übernimmt ein Validator-Objekt, das über eine Fabrik erfragt wird. Der Validator besitzt eine validate()-Methode, die als Argument das zu validierende Objekt bekommt. Die Rückgabe ist eine Menge von Fehler-Objekten; gibt es keinen Fehler, ist die Menge leer. Da wir in unserem Beispiel zwei Fehler haben, iteriert die Schleife durch die Menge mit den ConstraintViolation-Objekten und gibt den Namen der Property und eine vordefinierte Fehlermeldung aus. Nach dem Start ergibt sich folgende Ausgabe (wobei die Ausgaben vom Logger ignoriert werden):
1209
17
Technologien für die Infrastruktur
age muss grössergleich 10 sein name kann nicht null sein
Dass die Ausgaben auf Deutsch sind, sollte uns nicht verwundern, denn die Implementierung ist internationalisiert. Der Validator hat also die beiden Fehler korrekt erkannt. In der Ausgabe sehen wir vom ConstraintViolation-Objekt die Rückgaben von getPropertyPath() und getMessage(). Die erste Methode liefert den Namen der Property, die zweite eine Standard-Meldung, die wir aber auch überschreiben können, indem wir in der Annotation die Eigenschaft message setzen, etwa so: @NotNull(message="muss ungleich null sein"). Zusätzliche Methoden von ConstraintViolation sind unter anderem getRootBean(), getRootBeanClass(), getLeafBean() und getInvalidValue(). Mit validate(p) setzen wir den Validator auf das ganze Player-Objekt an. Es lassen sich aber auch einzelne Properties validieren. Dazu wird validateProperty() eingesetzt, eine Methode, die erst das zu validierende Objekt erwartet und anschließend im String den Namen der Property. Listing 17.3: com/tutego/insel/bean/validation/PlayerValidatorDemo.java, main() Teil 2 Set ageViolation = validator.validateProperty( p, "age" ); if ( ! ageViolation.isEmpty() ) System.out.println( new ArrayList(ageViolation) .get( 0 ).getMessage() );
Die von validateProperty() zurückgegebene Menge ist entweder leer oder enthält Fehler. In der letzten Zeile kopieren wir zum Test die Fehlermenge in eine Liste und greifen auf den ersten Fehler zu. class javax.validation.Validation Þ static ValidatorFactory buildDefaultValidatorFactory()
Gibt die Standard-ValidatorFactory zurück. interface javax.validation.ValidatorFactory Þ Validator getValidator()
Liefert den Validator der Fabrik.
1210
17.1
Property-Validierung durch Bean Validation
interface javax.validation.Validator Þ Set validateProperty(T object, String propertyName,
Class... groups)
Validiert vom Objekt object die Eigenschaft propertyName. Optionale Gruppen (sie werden später vorgestellt) sind möglich. Þ Set validate(T object, Class... groups)
Validiert das gesamte Objekt. interface javax.validation.ConstraintViolation Þ String getMessage()
Liefert die Fehlernachricht. Þ T getRootBean()
Liefert die Hauptbean, die validiert wird. Þ T getLeafBean()
Liefert die tatsächliche Bean, bei der die Eigenschaft validiert wird. Þ Object getInvalidValue()
Liefert den fehlerhaften Wert.
Hinweis Das Validation-Framework kann ganze Objektgraphen beachten und so eine tiefe Validierung durchführen. Wenn etwa ein Game-Objekt einen Player referenziert und die Validierung auf dem Game ausgeführt wird, kann der Player mit überprüft werden. Automatisch wird diese tiefe Prüfung aber nicht durchgeführt. Die Game-Klasse muss an der Player-Referenz die Annotation @Valid tragen. Selbst wenn das Game in einer Datenstruktur (Feld, Map oder alles Iterable wie Collection) viele Player referenziert, werden alle Spieler in der Sammlung überprüft, wenn die Sammlung die @Valid-Annotation trägt.
Die Constraints im Überblick Unser Player nutzt drei Constraints, aber standardmäßig gibt es noch einige mehr. Zudem lassen sich eigene Constraints leicht programmieren. Die folgende Tabelle gibt einen Überblick über alle vordefinierten Contraints: Constraint-Annotation
Aufgabe
Gültig an den Typen
@Null
Die Referenz muss null bezie-
Referenzvariablen
@NotNull
hungsweise nicht null sein.
Tabelle 17.1: Die wichtigsten Annotationen von Bean-Validation
1211
17
17
Technologien für die Infrastruktur
Constraint-Annotation
Aufgabe
Gültig an den Typen
@AssertTrue
Das Element muss true bezie-
boolean/Boolean
@AssertFalse
hungsweise false sein.
@Min(value=)
Muss eine Zahl und größer/klei-
byte/Byte, short/Short,
@Max(value=)
ner oder gleich dem Wert sein.
int/Integer, long/Long, BigInteger, BigDecimal
@DecimalMin(value=)
Muss eine Zahl und größer/klei-
@DecimalMax(value=)
ner oder gleich dem Wert sein.
Double/Double und float/ Float sowie String, byte/ Byte, short/Short, int/ Integer, long/Long, BigInteger, BigDecimal
@Size([min=],[max=])
Die Größe muss sich in einem
String, Collection, Map, Feld
Intervall bewegen. Das Element muss eine gege-
String, byte/Byte, short/
bene Anzahl an Stellen besit-
Short, int/Integer, long/
zen.
Long, BigInteger, BigDecimal
@Past
Das Element ist ein Datum in
Date, Calendar
@Future
der Vergangenheit/Zukunft
@Digits(integer=,fraction=)
bezogen auf jetzt. @Pattern(regex=[,flags=])
Der String muss einem Pattern
String
gehorchen. Tabelle 17.1: Die wichtigsten Annotationen von Bean-Validation (Forts.)
Der Unterschied zwischen @Min/@Max und @DecimalMin/@DecimalMax ist der, dass im zweiten Fall ein String angegeben wird. So sind @Min(10) und @DecimalMax("10") gleichwertig. Bei @Digits ist die Angabe der Nachkommastellen nicht optional. Bei @Size können min/max alleine oder zusammen angegeben werden. Beim @Pattern ist flags optional. Ohne Flag wird nur der reguläre Ausdruck als String angegeben, etwa so: @Pattern(regexp="\\d*"). Falls Flags angegeben werden, entsprechen sie dem Flag der Pattern-Klasse, etwa @Pattern(regexp="\\d*", flags=Pattern.Flag.CASE_INSENSITIVE).
Hinweis Der Standard sieht double und float aufgrund von Rundungsproblemen nicht bei @Min/@Max/ @DecimalMin/@DecimalMax vor, wobei die tatsächliche Implementierung das durchaus berücksichtigen kann. Wer Einschränkungen auf Fließkommazahlen benötigt, muss also im Moment den Variablentyp auf java.math.BigDecimal setzen.
1212
17.1
Property-Validierung durch Bean Validation
Alle Annotationstypen deklarieren einen inneren Annotationstyp List, der eine Auflistung vom gleichen Contraint-Typ erlaubt. Die Verkettung erfolgt nach dem Oder-Prinzip. List ist sinnvoll, denn mehrfach kann die gleiche Annotation nicht an einem Element stehen.
Beispiel Die Zeichenkette ist entweder eine E-Mail oder eine Webadresse: @Pattern.List({ @Pattern(regexp="[\\w|-]+@\\w[\\w|-]*\\.[a-z]{2,3}"), @Pattern(regexp="https?://[-\\w]+(\\.\\w[-\\w]*)") }) String emailOrWeb;
Es ist naheliegend, diese beiden komplexen Ausdrücke nicht zu einem großen unleserlichen regulären Ausdruck zu vermengen. Die Liste ist auch sinnvoll, wenn jeder Teilausdruck zu unterschiedlichen Gruppen gehört – zu den Gruppen folgt jetzt mehr.
Validierung von Gruppen Ist ein Objekt korrekt, erfüllt es alle Validierungs-Constraints. Dieses Alles-oder-nichts-Prinzip ist jedoch etwas hart. Betrachten wir zwei Szenarien: Þ In der grafischen Oberfläche wird ein Spieler erfasst und später in der Datenbank gespei-
chert. Sein Name kann aber in der Oberfläche leer bleiben, da der Platz, falls nichts angegeben ist, mit einem Zufallsnamen gefüllt wird. Geht der Spieler jedoch in die Datenbank, so muss er auf jeden Fall einen Namen tragen. Je nach Lebenszkylus des Spielers sind also unterschiedliche Belegungen erlaubt. Þ Eine grafische Oberfläche zeigt einen Wizard über mehrere Seiten an. Auf der ersten Seite
muss zum Beispiel der Spieler seinen Namen angeben, auf der zweiten Seite sein Alter. Würde auf der ersten Seite der Spieler komplett validiert werden, wäre das Alter ja noch gar nicht gesetzt, und die Validierung würde einen Fehler melden. Da ein Objekt in den unterschiedlichsten Phasen korrekt sein kann, lassen sich Gruppen bilden. Um eine eigene Validierungsgruppe zu nutzen, wird 1. eine leere Java-Schnittstelle aufgebaut, 2. einer Annotation wie @NotNull ein Class-Objekt für die Validierungsschnittstelle mitgegeben und 3. der validate()-Methode die Validierungsschnittstelle als letzter Parameter bekannt gegeben. Führen wir das exemplarisch mit einem Spieler durch, der im ersten Schritt einen gültigen Namen haben muss und im zweiten Schritt ebenfalls ein gültiges Alter. Deklarieren wir zwei
1213
17
17
Technologien für die Infrastruktur
Schnittstellen in einer Klasse DialogPlayer. Um es kurz zu halten, verzichtet der DialogPlayer auf Setter/Getter. Listing 17.4: com/tutego/insel/bean/validation/DialogPlayer.java, main() public class DialogPlayer { public interface NameValidation { } public interface AgeValidation extends NameValidation { } @NotNull( groups = NameValidation.class ) public String name; @Min( value = 10, groups = AgeValidation.class ) @Max( value = 110, groups = AgeValidation.class ) public int age; }
Die ersten beiden Schritte sind hier in dem Spieler schon sichtbar. Die zwei Schnittstellen sind deklariert und als groups-Element bei den Validierungsannotationen angegeben. Das Validierungs-Framework erlaubt auch Vererbung, was das Beispiel bei interface AgeValidation extends NameValidation zeigt; AgeValidation basiert auf NameValidation, sodass der Name auf jeden Fall auch korrekt ist – also nicht null sein darf – und nicht nur allein das Alter sich zwischen 10 und 110 bewegt. Jeder Constraint kann zu mehreren Gruppen gehörten, aber das brauchen wir hier nicht. Standardmäßig gibt es auch eine Default-Gruppe, wenn keine eigene Gruppe definiert wird. Versteckt steht dann standardmäßig groups = Default.class. Im dritten Schritt gilt es, der validate()-Methode das Class-Objekt für die Gruppe mitzugeben. Listing 17.5: com/tutego/insel/bean/validation/DialogPlayerValidatorDemo.java, main(), Teil 1 Validator v = Validation.buildDefaultValidatorFactory().getValidator(); Set constraintViolations; DialogPlayer p = new DialogPlayer(); constraintViolations = v.validate( p, DialogPlayer.NameValidation.class ); for ( ConstraintViolation violation : constraintViolations ) System.out.println( violation.getPropertyPath() + " " + violation.getMessage() );
1214
17.1
Property-Validierung durch Bean Validation
Der DialogPlayer hat keinen Namen, daher ist die Ausgabe »name kann nicht null sein«. Weitere Fehler kommen nicht vor, denn DialogPlayer.NameValidation.class validiert nur alle Eigenschaften, die ein groups = NameValidation.class tragen. Und das trägt nur name. Setzen wir den Namen, und validieren wir neu: Listing 17.6: com/tutego/insel/bean/validation/DialogPlayerValidatorDemo.java, main(), Teil 2 p.name = "chris"; System.out.println( v.validate( p, DialogPlayer.NameValidation.class ).size() ); // 0
Es gibt keine Fehlermeldungen mehr, auch wenn das Alter nicht gesetzt ist. Validieren wir mit dem DialogPlayer.AgeValidation, gibt es wieder einen Fehler, da age noch auf 0 war: Listing 17.7: com/tutego/insel/bean/validation/DialogPlayerValidatorDemo.java, main(), Teil 3 constraintViolations = v.validate( p, DialogPlayer.AgeValidation.class ); for ( ConstraintViolation violation : constraintViolations ) System.out.println( violation.getPropertyPath() + " " + violation.getMessage() );
Die Ausgabe ist »age muss grössergleich 10 sein«. Dass AgeValidation einen Namen ungleich null und das Alter prüft, zeigt sich, wenn der name auf null gesetzt wird. Initialisieren wir das Alter, damit es nicht zwei Fehler, sondern nur einen Fehler wegen dem Namen gibt:
17
Listing 17.8: com/tutego/insel/bean/validation/DialogPlayerValidatorDemo.java, main(), Teil 4 p.name = null; p.age = 60; constraintViolations = v.validate( p, DialogPlayer.AgeValidation.class ); for ( ConstraintViolation violation : constraintViolations ) System.out.println( violation.getPropertyPath() + " " + violation.getMessage() );
Jetzt ist die Ausgabe nur »name kann nicht null sein«, da das Alter sich im korrekten Bereich befindet. Mit einem gesetzten Namen verschwinden alle Fehler: Listing 17.9: com/tutego/insel/bean/validation/DialogPlayerValidatorDemo.java, main(), Teil 5 p.name = "chris"; System.out.println( v.validate( p, DialogPlayer.NameValidation.class ).size() ); // 0
1215
17
Technologien für die Infrastruktur
Hinweis Den validateXXX()-Methoden kann nicht nur eine Validierungsgruppe mitgegeben werden, sondern über ein Varargs auch mehrere. Doch wenn es etwa validate(p, V1.class, V2.class) heißt, ist die Reihenfolge unbestimmt, auch wenn der Aufruf suggeriert, es würden erst die Eigenschaften aus V1 validiert und dann die aus V2. Um eine feste Reihenfolge vorzugeben, muss eine neue Schnittstelle deklariert werden, die eine Annotation GroupSequence trägt, in der die Reihenfolge bestimmt wird. @GroupSequence( {V1.class, V2.class} ) public interface OrderedValidation {}
Reihenfolgen sind auch nützlich, um schnelle Validierungen zuerst durchzuführen und anschließend Validierungen anzuwenden, die zeitaufwändiger sind.
Eigene Validatoren Die Anzahl der Standard-Validatoren ist beschränkt, doch Anforderungen nach etwa einem E-Mail-Validator ergeben sich schnell. Wir wollen – ohne auf die Details von eigenen Annotationstypen genau einzugehen – einen neuen Validierungsannotationstyp für E-Mail-Adressen schreiben. Beginnen wir mit einer Person, die ein Attribut email besitzt und deren E-Mail-Adresse geprüft werden soll. Die Variable email bekommt unsere eigene Annotation EMail. Listing 17.10: com/tutego/insel/bean/validation/PersonValidator.java, PersonValidator public class PersonValidator { public static class Person { @NotNull @EMail public String email; // = "[email protected]"; } public static void main( String[] args ) { Validator v = Validation.buildDefaultValidatorFactory().getValidator(); Person p = new Person();
1216
17.1
Property-Validierung durch Bean Validation
Set constraintViolations = v.validate( p ); for ( ConstraintViolation violation : constraintViolations ) System.out.println( violation.getPropertyPath() + " " + violation.getMessage() ); } }
Läuft das Programm, gibt es zwei Fehlermeldungen aus, da email gleich null ist und nicht dem entsprechenden Pattern gehorcht: email ist keine gültige E-Mail-Adresse email kann nicht null sein
Die Meldung »ist keine gültige E-Mail-Adresse« kommt von unserem eigenen Annotationstyp. Der ist wie folgt deklariert: Listing 17.11: com/tutego/insel/bean/validation/Email.java, EMail @Constraint( validatedBy = EMailValidator.class ) @Target({ METHOD, FIELD, ANNOTATION_TYPE }) @Retention( RUNTIME ) @Documented public @interface EMail
17
{ String message() default "ist keine gültige E-Mail-Adresse"; Class[] groups() default {}; Class c2 = new java.util.Date().getClass(); // oder Class c3 = Class.forName( "java.util.Date" ); System.out.println( c3 );
// class java.util.Date
} catch ( ClassNotFoundException e ) { e.printStackTrace(); }
Die Variante mit forName() ist sinnvoll, wenn der Klassenname bei der Übersetzung des Programms noch nicht feststand. Sonst ist die vorhergehende Technik eingängiger, und der Compiler kann prüfen, ob es den Typ gibt.
Beispiel Klassenobjekte für primitive Elemente liefert forName() nicht! Die beiden Anweisungen Class.forName("boolean") und Class.forName(boolean.class.getName()) führen zu einer ClassNotFoundException.
1229
18
Reflection und Annotationen
class java.lang.Object Þ final Class forName(String className) throws ClassNotFoundException
Liefert das Class-Exemplar für die Klasse oder Schnittstelle mit dem angegebenen voll qualifizierten Namen. Falls sie bisher noch nicht vom Programm benötigt wurde, sucht und lädt der Klassenlader die Klasse. Die Methode liefert niemals null zurück. Falls die Klasse nicht geladen und eingebunden werden konnte, gibt es eine ClassNotFoundException. Eine alternative Methode forName() ermöglicht auch das Laden mit einem gewünschten Klassenlader. Der Klassenname muss immer voll qualifiziert sein.
ClassNotFoundException und NoClassDefFoundError * Eine ClassNotFoundException lösen die Methoden forName() aus Class und loadClass() bzw. findSystemClass() aus ClassLoader immer dann aus, wenn der Klassenlader die Klasse nach ihrem Klassennamen nicht finden kann. Neben der Exception-Klasse gibt es ein NoClassDefFoundError – ein harter LinkageError, den das System immer dann auslöst, wenn die JVM eine im Bytecode referenzierte Klasse nicht laden kann. Nehmen wir zum Beispiel eine Anweisung wie new MeineKlasse(). Führt die JVM diese Anweisung aus, versucht sie den Bytecode von MeineKlasse zu laden. Ist der Bytecode für MeineKlasse nach dem Compilieren entfernt worden, löst die JVM durch den nicht geglückten Ladeversuch den NoClassDefFoundError aus. Auch tritt der Fehler auf, wenn beim Laden des Bytecodes die Klasse MeineKlasse zwar gefunden wurde, aber MeineKlasse einen statischen Initialisierungsblock besitzt, der wiederum eine Klasse referenziert, für die keine Klassendatei vorhanden ist. Während ClassNotFoundException häufiger vorkommt als NoClassDefFoundError, ist es im Allgemeinen ein Indiz dafür, dass ein Java-Archiv im Klassenpfad fehlt.
Umbenennungen der Klassennamen durch den Obfuscator Dass der Compiler automatisch Bytecode gemäß dieses veränderten Quellcodes erzeugt, führt nur dann zu unerwarteten Problemen, wenn wir einen Obfuscator über den Programmtext laufen lassen, der nachträglich den Bytecode modifiziert und damit die Bedeutung des Programms beziehungsweise des Bytecodes verschleiert und dabei Klassen umbenennt. Offensichtlich darf ein Obfuscator Klassen, deren Class-Exemplare abgefragt werden, nicht umbe-
1230
18.2
Metadaten der Klassen mit dem Class-Objekt
nennen; oder der Obfuscator müsste die entsprechenden Zeichenketten ebenfalls korrekt ersetzen (aber natürlich nicht alle Zeichenketten, die zufällig mit Namen von Klassen übereinstimmen).
18.2.2
Was das Class-Objekt beschreibt *
Ein Class-Exemplar kann eine Schnittstelle, eine Klasse, einen primitiven Datentyp oder auch einen Array-Typ beschreiben. Dies lässt sich durch die drei Methoden isInterface(), isPrimitive() und isArray() herausfinden. Wenn keine der drei Methoden für ein Class-Exemplar true liefert, repräsentiert das Objekt eine gewöhnliche Klasse. Dass es auch Class-Exemplare gibt, die die primitiven Datentypen von Java beschreiben, erstaunt zunächst. Damit ist es jedoch möglich, die Parameter- und Ergebnistypen beliebiger Java-Methoden einheitlich durch Class-Exemplare zu beschreiben. Dazu kodieren jede der acht Wrapper-Klassen, die zu den Datentypen boolean, byte, char, short, int, long, float und double gehören, und die spezielle Klasse für den Typ void eine Konstante TYPE. Benötigen wir ein Class-Objekt für den primitiven Typ int, so greifen wir mit Integer.TYPE (oder alternativ mit int.class) darauf zu. Alle Class-Exemplare für primitive Datentypen werden automatisch von der JVM erzeugt. Die Methode isPrimitive() gibt genau für diese neun besonderen ClassExemplare true zurück, sodass sie von Repräsentanten für echte Klassen unterschieden werden können.
Hinweis
18
Obwohl void kein Typ ist, meldet isPrimitive() dies: System.out.println( void.class.isPrimitive() ); // true
Das folgende Programmstück testet die Attribute von Class-Objekten systematisch durch. Wir benutzen die Methode getName(), um den Namen des Class-Objekts auszugeben. Im nächsten Unterkapitel mehr dazu. Das Class-Objekt für Felder setzt sich aus dem Basistyp und Paaren von eckigen Klammern zusammen, etwa double[][].class. Listing 18.2: com/tutego/insel/meta/CheckClassType.java, CheckClassType class CheckClassType { public static void main( String[] args ) { checkClassType( Observer.class ); checkClassType( Observable.class ); checkClassType( (new int[2][3][4]).getClass() );
1231
18
Reflection und Annotationen
checkClassType( Integer.TYPE ); } static void checkClassType( Class c ) { if ( c.isArray() ) System.out.println( c.getName() + " ist ein Feld." ); else if ( c.isPrimitive() ) System.out.println( c + " ist ein primitiver Typ."); else if ( c.isInterface() ) System.out.println( c.getName() + " ist ein Interface." ); else System.out.println( c.getName() + " ist eine Klasse." ); } }
Die Ausgabe des Programms ist nun: java.util.Observer ist ein Interface. java.util.Observable ist eine Klasse. [[[I ist ein Feld. int ist ein primitiver Typ. final class java.lang.Class implements Serializable, GenericDeclaration, Type, AnnotatedElement Þ boolean isInterface()
Liefert true, wenn das Class-Objekt eine Schnittstelle beschreibt. Þ boolean isArray()
Liefert true, wenn das Class-Objekt einen Array-Typ beschreibt. Þ boolean isPrimitive()
Testet, ob das Class-Objekt einen primitiven Datentyp beschreibt.
Komponententyp bei Feldern Die Methode getComponentType() liefert bei Feldern den Typ der Elemente als Class-Objekt. Steht das Class-Objekt für kein Feld, ist die Methodenrückgabe null.
1232
18.2
System.out.println( double[].class.getComponentType() );
Metadaten der Klassen mit dem Class-Objekt
// double
System.out.println( double[][].class.getComponentType() ); // class [D System.out.println( double.class.getComponentType() );
18.2.3
// null
Der Name der Klasse
Liegt zu einer Klasse das Class-Objekt vor, so können wir zur Laufzeit ihren voll qualifizierten Namen über die Methode getName() ausgeben. Da jeder Typ über einen Namen verfügt, führt diese Methode also jedes Mal zum Ziel: Listing 18.3: SampleName.java String n1 = new java.util.Date().getClass().getName(); System.out.println( n1 );
// java.util.Date
String n2 = java.util.RandomAccess.class.getName(); System.out.println( n2 );
// java.util.RandomAccess
String n3 = Deprecated.class.getName(); System.out.println( n3 );
// java.lang.Deprecated
String n4 = Thread.State.class.getName(); System.out.println( n4 );
// java.lang.Thread$State
Kodierung von Feldern * Schwieriger ist die Kodierung bei Array-Typen, die ja eine besondere Form von Klassen sind. getName() kodiert sie mit einer führenden »[«. Jede Klammer steht dabei für eine Dimension des Array-Typs. Nach den Klammern folgt in einer kodierten Form der Typ der Array-Elemente. So liefert System.out.println( int[][][].class.getName() );
// [[[I
System.out.println( (new int[2][3][4]).getClass().getName() ); // [[[I
den String »[[[I«, also einen dreidimensionalen Array-Typ mit Array-Elementen vom primitiven Typ int. Der Elementtyp ist wie folgt kodiert: Kürzel
Datentyp
B
Byte
C
Char
D
Double
Tabelle 18.1: Kodierung der Elementtypen
1233
18
18
Reflection und Annotationen
Kürzel
Datentyp
F
Float
I
Int
J
Long
LElementtyp;
Klasse oder Schnittstelle
S
Short
Z
Boolean
Tabelle 18.1: Kodierung der Elementtypen (Forts.)
Nimmt das Array Objektreferenzen auf, wird deren Typ in der Form »LKlassenname;« kodiert. So liefert (new Object[3]).getClass().getName() den String [Ljava.lang.Object;. Der Klassenbeziehungsweise Schnittstellenname ist wie üblich voll qualifiziert. Der String ist auch für Class.forName() von Bedeutung. Im Fall von Arrays liefert die Methode ein Class-Objekt für den Elementtyp. Die ersten Versuche, ein Class-Objekt für Felder zu beziehen, scheitern an einer ClassNotFoundException: Class.forName( "String[]" ); Class.forName( "java.lang.String[]" );
In der ersten Anweisung ist der Klassenname nicht voll qualifiziert, und auch in der zweiten Anweisung ist der String falsch aufgebaut. out.println( Class.forName("[Ljava.lang.String;") ); // class [Ljava.lang.String;
Steht die Frage an, ob ein Class-Objekt für ein Feld von Objekten steht oder für ein primitives Feld, lässt sich das Ergebnis von getName() auswerten: public static boolean isObjectArray( Class clazz ) { if ( clazz != null && clazz.isArray() ) return clazz.getName().startsWith( "[L" ); return false; }
So liefert: System.out.println( isObjectArray( Object[].class ) );
// true
System.out.println( isObjectArray( int[].class ) );
// false
System.out.println( isObjectArray( Object.class ) );
// false
1234
18.2
Metadaten der Klassen mit dem Class-Objekt
toString() Auch eine zweite Methode ist uns bekannt, um Class-Exemplare für Menschen lesbar auszugeben: die Methode toString(). Sie basiert im Kern auf getName(), fügt aber zusätzlich die Art der repräsentierten Klasse (normale Klasse, Schnittstelle oder primitiver Datentyp) ein: public String toString() { return (isInterface() ? "interface " : (isPrimitive() ? "" : "class ")) + getName(); } final class java.lang.Class implements Serializable, GenericDeclaration, Type, AnnotatedElement Þ String getName()
Liefert für ein Class-Exemplar als String den voll qualifizierten Namen der repräsentierten Klasse oder Schnittstelle beziehungsweise des repräsentierten Array-Typs oder des primitiven Datentyps. Þ String toString()
Liefert eine für Menschen lesbare String-Repräsentation des Class-Objekts.
18.2.4 instanceof mit Class-Objekten * Der binäre Operator instanceof testet, ob ein Objekt Exemplar einer Klasse oder der Oberklasse ist. Wenn das Ergebnis wahr ist, lässt sich das Objekt unter dem gegebenen Typ ansprechen, ist also zuweisungskompatibel. Der rechte Operator bei instanceof, der Typname, muss jedoch immer zur Übersetzungszeit bekannt sein und kann nicht dynamisch, etwa durch einen String, festgelegt werden. Ist der Typname zur Compilierzeit vielleicht unbekannt, kann das Class-Objekt helfen. Die Methode isInstance(Object) ist sozusagen ein dynamisches instanceof. Gilt mit dem Operator object instanceof ReferenceType
so heißt das mit der Methode: ReferenceType-Class-Objekt.isInstance( object )
Gewöhnungsbedürftig ist sicherlich die Tatsache, dass bei der Methode isInstance() die beiden Operanden umgedreht sind. Dazu ein paar Beispiele:
1235
18
18
Reflection und Annotationen
Listing 18.4: IsAssignableFrom.java, main() Component b = new JLabel(); out.println( b instanceof JLabel );
// true
out.println( JLabel.class.isInstance( b ) );
// true
out.println( Object.class.isInstance( b ) );
// true
out.println( Class.forName("java.awt.Component").isInstance( b ) );
// true
out.println( String.class.isInstance( b ) );
// false
Die Methode isInstance(object) ist natürlich ein wenig dadurch eingeschränkt, dass es immer ein Test-Objekt geben muss. Die Frage etwa, ob das Class-Objekt der Schnittstelle PublicKey eine »Ist-eine-Art-von-Serializable« ist, kann isInstance(object) nicht beantworten, denn dann müsste es vorher ein Objekt geben. Für diesen Fall bietet das Class-Objekt noch eine zweite Methode, isAssignableFrom(Class): Class clazz = Serializable.class; out.println( clazz.isAssignableFrom( String.class ) );
// true
out.println( clazz.isAssignableFrom( Thread.class ) );
// false
out.println( clazz.isAssignableFrom( PublicKey.class ) );
// true
Solange der Typname zur Übersetzungszeit bekannt ist, ist instanceof immer noch die beste Lösung. Doch wenn die Klasse nur durch ein Class-Objekt gegeben ist, bleibt immer noch isAssignableFrom(). Die Methode clazz.isInstance(obj) ist sozusagen eine Kurzform von clazz.isAssignableFrom(obj.getClass()).
18.2.5
Oberklassen finden *
Das Class-Exemplar für eine Klasse gibt Zugriff auf die Oberklasse, die Sichtbarkeitsstufe und weitere Informationen. Die Oberklasse ermittelt getSuperclass(). Die Methode gibt null zurück, falls das Class-Objekt eine Schnittstelle repräsentiert oder wir schon am oberen Ende der Hierarchie sind, also bei dem Class-Objekt für die Wurzelklasse Object. Das folgende Programm findet alle Oberklassen einer Klasse durch den wiederholten Aufruf der Methode getSuperclass(): Listing 18.5: com/tutego/insel/meta/ShowSuperclasses.java Class subclass
= javax.swing.JButton.class;
Class superclass = subclass.getSuperclass(); while ( superclass != null ) { String className = superclass.getName();
1236
18.2
Metadaten der Klassen mit dem Class-Objekt
System.out.println( className ); subclass
= superclass;
superclass = subclass.getSuperclass(); }
Wahrscheinlich wäre eine rekursive Variante noch eleganter, aber darauf kommt es jetzt nicht an. javax.swing.AbstractButton javax.swing.JComponent java.awt.Container java.awt.Component java.lang.Object final class java.lang.Class implements Serializable, GenericDeclaration, Type, AnnotatedElement Þ Class c = java.text.SimpleDateFormat.class; System.out.println( "class " + c.getName() + " {" ); for ( Field publicField : c.getFields() ) { String fieldName = publicField.getName();
1243
18
18
Reflection und Annotationen
String fieldType = publicField.getType().getName(); System.out.printf( "
%s %s;%n", fieldType, fieldName );
} System.out.println( "}" );
Dies ergibt die (gekürzte) Ausgabe: class java.text.SimpleDateFormat { int ERA_FIELD; int YEAR_FIELD; ... int SHORT; int DEFAULT; } final class java.lang.Class implements Serializable, GenericDeclaration, Type, AnnotatedElement Þ Field[] getFields()
Liefert ein Array mit Field-Objekten. Die Einträge sind unsortiert. Das Array hat die Länge 0, wenn die Klasse beziehungsweise Schnittstelle keine öffentlichen Variablen deklariert oder erbt. getFields() liefert automatisch auch Einträge für die aus Oberklassen beziehungsweise Schnittstellen geerbten öffentlichen Variablen. Þ Field getField(String name) throws NoSuchFieldException
Erfragt ein bestimmtes Feld. Die Klasse Field implementiert im Übrigen das Interface Member und ist eine Erweiterung von AccessibleObject. AccessibleObject ist die Basisklasse für Field-, Method- und Constructor-Objekte. Auch Method und Constructor implementieren das Interface Member, das zur Identifikation über getName() oder getModifiers() dient. Zusätzlich liefert getDeclaringClass() das ClassObjekt, das tatsächlich eine Variable oder Methode deklariert. Da geerbte Elemente in der Aufzählung mit auftauchen, ist dies der einzige Weg, um die Position der Deklaration in der Vererbungshierarchie exakt zu bestimmen. Mit dem Field-Objekt können wir vieles erfragen: den Namen des Attributs, den Datentyp und auch wieder die deklarierten Modifizierer. Werfen wir einen Blick auf die toString()Methode der Klasse Field: public String toString() { int mod = getModifiers(); return (((mod == 0) ? "" : (Modifier.toString(mod) + " ")) + getTypeName(getType()) + " "
1244
18.3
Attribute, Methoden und Konstruktoren
+ getTypeName(getDeclaringClass()) + "." + getName()); }
Beispiel Für die Schleife über die Field-Objekte von SimpleDateFormat und einen Aufruf von toString() liefern die Zeilen for ( Field publicField : c.getFields() ) System.out.println( " " + publicFields );
dann: class java.text.SimpleDateFormat { public static final int java.text.DateFormat.ERA_FIELD public static final int java.text.DateFormat.YEAR_FIELD ... public static final int java.text.DateFormat.SHORT public static final int java.text.DateFormat.DEFAULT }
final class java.lang.reflect.Field extends AccessibleObject implements Member
18
Þ Class getDeclaringClass()
Liefert das Class-Exemplar für die Klasse oder die Schnittstelle, in der die Variable deklariert wurde. Diese Methode ist Teil der Schnittstelle Member. Þ int getModifiers()
Liefert die deklarierten Modifizierer für die Variable. Þ String getName()
Liefert den Namen der Variable. Diese Methode ist Teil der Schnittstelle Member. Þ Class getType()
Liefert ein Class-Objekt, das dem Datentyp der Variable entspricht. Þ String toString()
Liefert eine String-Repräsentation. Am Anfang stehen die Sichtbarkeitsmodifizierer (public, protected oder private), und es folgen die weiteren Modifizierer (static, final, transient, volatile). Dann kommt der Datentyp, gefolgt vom voll qualifizierten Namen der deklarierenden Klasse, und schließlich der Name der Variable.
1245
18
Reflection und Annotationen
Abbildung 18.2: UML-Diagramm mit den Unterklassen von Member
18.3.2
Methoden einer Klasse erfragen
Um herauszufinden, über welche Methoden eine Klasse verfügt, wenden wir eine ähnliche Vorgehensweise an wie bei den Variablen: getMethods(). Diese Methode liefert ein Array mit Method-Objekten. Über ein Method-Objekt lassen sich Methodenname, Ergebnistyp, Parametertypen, Modifizierer und eventuell resultierende Exceptions erfragen. Wir werden später sehen, dass sich die durch ein Method-Exemplar repräsentierte Methode über invoke() aufrufen lässt.
1246
18.3
Attribute, Methoden und Konstruktoren
Hinweis Auch wenn zwei Klassen die gleiche Methode besitzen, muss doch ein Method-Objekt immer für jede Klasse erfragt werden. Method-Objekte sind immer mit dem Class-Objekt verbunden.
final class java.lang.Class implements Serializable, GenericDeclaration, Type, AnnotatedElement Þ Method[] getMethods()
Gibt ein Array von Method-Objekten zurück, die alle öffentlichen Methoden der Klasse/ Schnittstelle beschreiben. Geerbte Methoden werden mit in die Liste übernommen. Die Elemente sind nicht sortiert, noch gibt es keine Reihenfolge. Die Länge des Arrays ist null, wenn es keine öffentlichen Methoden gibt. Þ Method getMethod(String name, Class... parameterTypes)
throws NoSuchMethodException
Liefert zu einem Methodennamen und einer Parameterliste das passende Method-Objekt oder löst eine NoSuchMethodException aus. Besitzt die Methode keine Parameter – wie eine übliche getXXX()-Methode –, ist das Argument null und wird wegen der Varargs auf Class[] angepasst. Nachdem wir nun mittels getMethods() ein Array von Method-Objekten erhalten haben, lassen die Method-Objekte verschiedene Abfragen zu. So liefert getName() den Namen der Methode, getReturnType() den Ergebnistyp, und getParameterTypes() erzeugt ein Array von Class-Objekten, das die Typen der Methodenparameter widerspiegelt. Wir kennen dies schon von den Attributen. Wir wollen nun ein Programm betrachten, das alle Methoden und ihre Parametertypen sowie Ausnahmen ausgibt: Listing 18.8: com/tutego/insel/meta/ShowMethods.java package com.tutego.insel.meta; import java.lang.reflect.*; class ShowMethods { public static void main( String[] args ) { showMethods( java.awt.Color.BLACK ); }
1247
18
18
Reflection und Annotationen
static void showMethods( Object o ) { for ( Method method : o.getClass().getMethods() ) { String returnString = method.getReturnType().getName(); System.out.print( returnString + " " + method.getName() + "(" ); Class[] parameterTypes = method.getParameterTypes(); for ( int k = 0; k < parameterTypes.length; k++ ) { String parameterString = parameterTypes[k].getName(); System.out.print( " " + parameterString ); if ( k < parameterTypes.length – 1 ) System.out.print( ", " ); } System.out.print( " )" ); Class[] exceptions = method.getExceptionTypes(); if ( exceptions.length > 0 ) { System.out.print( " throws " ); for ( int k = 0; k < exceptions.length; k++ ) { System.out.print( exceptions[k].getName() ); if ( k < exceptions.length – 1 ) System.out.print( ", " ); } } System.out.println(); } } }
Die Ausgabe sieht gekürzt so aus: int hashCode( ) boolean equals( java.lang.Object ) java.lang.String toString( )
1248
18.3
Attribute, Methoden und Konstruktoren
... [F getRGBColorComponents( [F ) ... void wait( long ) throws java.lang.InterruptedException void notify( ) void notifyAll( )
Wir bemerken an einigen Stellen eine kryptische Notation, wie etwa »[F«. Dies ist aber lediglich wieder die schon erwähnte Kodierung für Array-Typen. So gibt getRGB-Components() ein float-Array zurück und erwartet ein float-Array als Argument. final class java.lang.reflect.Method extends AccessibleObject implements GenericDeclaration, Member Þ Class getDeclaringClass()
Liefert das Class-Exemplar für die Klasse oder die Schnittstelle, in der die Methode deklariert wurde. Diese Methode ist Teil der Schnittstelle Member. Þ String getName()
Liefert den Namen der Methode. Diese Methode ist Teil der Schnittstelle Member. Þ int getModifiers()
Liefert die Modifizierer. Diese Methode ist Teil der Schnittstelle Member. Þ Class getReturnType()
18
Gibt ein Class-Objekt zurück, das den Ergebnistyp beschreibt. Þ Class[] getParameterTypes()
Liefert ein Array von Class-Objekten, die die Typen der Parameter beschreiben. Die Reihenfolge entspricht der deklarierten Parameterliste. Das Array hat die Länge null, wenn die Methode keine Parameter erwartet. Þ Class[] getExceptionTypes()
Liefert ein Array von Class-Objekten, die mögliche Exceptions beschreiben. Das Array hat die Länge null, wenn die Methode keine solchen Exceptions mittels throws deklariert. Das Feld spiegelt nur die throws-Klausel wider. Sie kann prinzipiell auch zu viele Exceptions enthalten, bei einer Methode foo() throws RuntimeException, NullPointerException etwa genau die beiden Ausnahmen. Þ String toString()
Liefert eine String-Repräsentation der Methode, ähnlich dem Methodenkopf in einer Deklaration.
1249
18
Reflection und Annotationen
18.3.3
Properties einer Bean erfragen
Eine Bean besitzt Properties (Eigenschaften), die in Java (bisher) durch Setter und Getter ausgedrückt werden, also Methoden, die einer festen Namenskonvention folgen. Gibt es Interesse an den Properties, lässt sich natürlich getMethods() auf dem Class-Objekt aufrufen und nach den Methoden filtern, die der Namenskonvention entsprechen. Die Java-Bibliothek bietet aber im Paket java.beans eine einfachere Lösung für Beans: einen PropertyDescriptor.
Beispiel Gib alle Properties von Color aus (es gibt nur lesbare): Listing 18.9: com/tutego/insel/meta/PropertyDescriptors.java, main() BeanInfo beanInfo = Introspector.getBeanInfo( Color.class ); for ( PropertyDescriptor pd : beanInfo.getPropertyDescriptors() ) System.out.println( pd.getDisplayName() + " : " + pd.getPropertyType().getName() );
Die Ausgabe: RGB : int alpha : int blue : int class : java.lang.Class colorSpace : java.awt.color.ColorSpace green : int red : int transparency : int
Interessanter sind vom PropertyDescriptor die Methoden getReadMethod() und getWriteMethod(), die beide ein Method-Objekt liefern – sofern es verfügbar ist –, um so die Methode gleich aufrufen zu können. BeanInfo liefert mit getPropertyDescriptors() zwar die Properties, kann jedoch über getMethodDescriptors() auch alle anderen Methoden liefern.
18.3.4
Konstruktoren einer Klasse
Konstruktoren und Methoden haben einige Gemeinsamkeiten, unterscheiden sich aber insofern, als Konstruktoren keinen Rückgabewert haben. Die Ähnlichkeit zeigt sich auch in der Methode getConstructors(), die ein Array von Constructor-Objekten zurückgibt. Über dieses Array lassen sich dann wieder Name, Modifizierer, Parameter und Exceptions der Konstrukto-
1250
18.3
Attribute, Methoden und Konstruktoren
ren einer Klasse erfragen. Wie wir in Abschnitt 18.4.1, »Objekte erzeugen«, sehen werden, lassen sich auch über die Methode newInstance() neue Objekte erzeugen. Wegen der weitgehenden Ähnlichkeit der Klassen Constructor und Method sind die folgenden Methoden hier nicht näher beschrieben.
Beispiel Zeige alle Konstruktoren der Color-Klasse: Listing 18.10: com/tutego/insel/meta/ShowConstructors.java, main() for ( Constructor c : java.awt.Color.class.getConstructors() ) System.out.println( c );
Die Klasse Constructor implementiert eine auskunftsfreudige toString()-Methode. Die String-Repräsentation zeigt die Signatur mit Sichtbarkeit. Nach dem Aufruf erhalten wir: public java.awt.Color(float,float,float,float) public java.awt.Color(int) public java.awt.Color(int,int,int) public java.awt.Color(int,int,int,int) public java.awt.Color(java.awt.color.ColorSpace,float[],float) public java.awt.Color(int,boolean) public java.awt.Color(float,float,float)
final class java.lang.Class
18
implements Serializable, GenericDeclaration, Type, AnnotatedElement Þ Constructor[] getConstructors()
Liefert ein Feld mit Constructor-Objekten. Þ Constructor getConstructor(Class... parameterTypes)
throws NoSuchMethodException
Liefert ein ausgewähltes Constructor-Objekt. final class java.lang.reflect.Constructor extends AccessibleObject implements GenericDeclaration, Member Þ Class getDeclaringClass()
Eine ziemlich langweilige Methode, da Konstruktoren nicht vererbt werden. Sie gibt immer nur jene Klasse aus, von der das Class-Objekt kommt. Das ist ein wichtiger Unterschied zwischen Methoden und Konstruktoren, der bei dieser Methode deutlich auffällt.
1251
18
Reflection und Annotationen
Þ Class[] getExceptionTypes() Þ int getModifiers() Þ String getName() Þ Class[] getParameterTypes()
Abbildung 18.3: UML-Diagramm mit den Unterklassen von Member
1252
18.4
18.3.5
Objekte erzeugen und manipulieren
Annotationen
Annotationen erfragen Methoden der Schnittstelle AnnotatedElement, die unter anderem Class, Constructor, Field, Method und Package implementieren. Ein Blick in AnnotatedElement verrät, wie an die Annotationen heranzukommen ist: interface java.lang.reflect.AnnotatedElement Þ Annotation[] getAnnotations()
Liefert alle mit diesem Element assoziierten Annotationen. Þ Annotation[] getDeclaredAnnotations()
Liefert alle an diesem Element deklarierten Annotationen. Vererbte Annotationen werden ignoriert. Þ boolean isAnnotationPresent(Class clazz, Collection list ) { Field[] fields = clazz.getDeclaredFields(); AccessibleObject.setAccessible( fields, true ); for ( Field f : fields ) { try { list.add( f.getName() + "=" + f.get( o ) ); } catch ( IllegalAccessException e ) { e.printStackTrace(); } }
1258
18.4
Objekte erzeugen und manipulieren
if ( clazz.getSuperclass().getSuperclass() != null ) toString( o, clazz.getSuperclass(), list ); } }
Die private Methode toString(Object, Class, ArrayList) dient eigentlich nur dem rekursiven Aufruf durch die Oberklassen. Falls es eine Oberklasse gibt, also clazz.getSuperclass().getSuperclass() ein Objekt liefert, müssen wir für die Oberklasse ebenfalls die Attribute ablaufen. Das machen wir rekursiv. Testen wir anschließend ToStringHelper in einer Klasse ToStringHelperDemo, die von Ober abgeleitet ist. Damit bekommen wir zwei Attribute in der Oberklasse. Eines davon ist interessant (die Variable i), denn die Unterklasse überdeckt sie. Dennoch findet toString() beide Belegungen. Wäre das nicht erwünscht, müssten wir einfach die Liste durchschauen und suchen, ob schon ein Attribut mit dem gleichen Namen vorhanden ist. Da der Algorithmus rekursiv erst die Unterklasse und dann die Oberklasse(n) durchsucht, bekommen wir auch die Attribute in dem sichtbaren Bereich, wie sie auch der Benutzer sieht: Listing 18.14: com/tutego/insel/meta/ToStringHelperDemo.java package com.tutego.insel.meta; class Ober { int i = 123;
18
/* private */double d = 3.1415; } public class ToStringHelperDemo extends Ober { String hello = "world"; int
i
= 42;
public static void main( String[] args ) { ToStringHelperDemo t = new ToStringHelperDemo(); System.out.println( ToStringHelper.toString( t ) ); // ToStringHelperTest[hello=world, i=42, i=123, d=3.1415] } }
1259
18
Reflection und Annotationen
18.4.4 Variablen setzen Bei Debuggern oder grafischen Editoren ist es nur eine Seite der Medaille, die Werte von Variablen anzuzeigen. Hinzu kommt noch das Setzen der Werte von Variablen. Dies ist aber genauso einfach wie das Abfragen. Anstelle der getXXX()-Methoden kommen nun verschiedene setXXX()-Methoden zum Einsatz. So trägt setBoolean() einen Wahrheitswert oder setDouble() eine Fließkommazahl in eine Variable ein. Eine allgemeine set()-Methode dient Objektreferenzen wie im Fall von get(). Die Methode set() nimmt ebenso Wrapper-Objekte für Variablen von primitiven Datentypen. Die folgenden set()-Methoden setzen daher alle »ihren« Datentyp. Wir müssen aber dafür sorgen, dass die Variable existiert und wir Zugriff darauf haben. In allen Fällen muss auf IllegalArgumentException und IllegalAccessException geachtet werden. Das folgende Programm erzeugt klassisch ein Point-Objekt mit dem Konstruktor, der x und y setzt. Anschließend verändert die eigene Methode modify() ein gewünschtes Attribut: Listing 18.15: com/tutego/insel/meta/SetFieldElements.java package com.tutego.insel.meta; import java.lang.reflect.*; import java.awt.*; class SetFieldElements { public static void main( String[] args ) { Point p = new Point( 11, 22 ); System.out.println( p ); modify( p, "x", 1111 );
// java.awt.Point[x=11,y=22]
modify( p, "y", 2222 );
// java.awt.Point[x=1111,y=2222]
System.out.println( p ); modify( p, "z", 0 );
// java.lang.NoSuchFieldException: z
} static void modify( Object o, String name, Integer param ) {
1260
18.4
Objekte erzeugen und manipulieren
try { Field field = o.getClass().getField( name ); field.set( o, param ); } catch ( NoSuchFieldException e ) { e.printStackTrace(); } catch ( IllegalAccessException e ) { e.printStackTrace(); } } }
Die Veränderung der Variablen erfolgt mit der set()-Methode. Da wir primitive Datentypen übergeben, wickeln wir sie für die modify()-Methode in ein Integer-Objekt ein. Das IntegerObjekt haben wir nicht explizit programmiert, denn es wird über Boxing vom Compiler selbst zur Verfügung gestellt. Für bekannte Typen könnten wir neben der allgemeinen Methode set() auch etwa setInt() verwenden. final class java.lang.reflect.Field extends AccessibleObject implements Member
18
Þ void set(Object obj, Object value)
Setzt das Attribut des Objekts obj, das dieses Field-Objekt repräsentiert, auf den neuen Wert value. Þ void setBoolean(Object obj, boolean z) Þ void setByte(Object obj, byte b) Þ void setChar(Object obj, char c) Þ void setDouble(Object obj, double d) Þ void setFloat(Object obj, float f) Þ void setInt(Object obj, int i) Þ void setLong(Object obj, long l) Þ void setShort(Object obj, short s)
Belegt das Feld eines Objekts obj mit einem primitiven Element.
1261
18
Reflection und Annotationen
18.4.5
Bean-Zustände kopieren *
In mehrschichtigen Anwendungen gibt es oft das Muster, dass eine JavaBean etwa über eine objekt-relationale Mapping-Technologie automatisch aus einer Datenbankzeile aufgebaut wird und dann intern in der Geschäftsschicht verwendet wird. Soll nun diese Information über das Netzwerk an einen anderen Rechner verteilt werden, ist es nicht immer angebracht, diese JavaBean etwa direkt über Serialisierung zu versenden. Stattdessen kann ein TransferObjekt aufgebaut werden, eine spezielle JavaBean zum Beispiel, sodass der Empfänger keine Abhängigkeit zu der Bean in der internen Geschäftsschicht hat. Nun werden sich aber diese Geschäftsschicht-Bean und die Transfer-Bean sehr ähnlich sein, und viele Entwickler scheuen die Mühe, lästigen Kopiercode zu erstellen. Doch manuelle Arbeit ist nicht nötig, und eine Lösung für das Kopierproblem ist über Refection schnell geschrieben. Über die BeanInfo kommen wir an den PropertyDescriptor (siehe dazu Abschnitt 18.3.3, »Properties einer Bean erfragen«), und dann liefern getReadMethod() und getWriteMethod() die Setter/Getter. Bei einer eigenen Kopiermethode wie copyProperties(Object source, Object target) müssen wir bei der Quell-Bean jede Property auslesen und entsprechend bei der Ziel-Bean nach der Property suchen und den Setter aufrufen. Wenn das Ganze ohne Typkonvertierungen programmiert werden soll, sind es nur wenige Zeilen Programmcode. Kommen einfache Konvertierungen dazu, etwa wenn einmal ein Wrapper als Property-Typ genutzt wird und einmal der primitive Datentyp, ist es etwas mehr. Der Aufwand mit einer eigenen Implementierung ist allerdings nicht nötig, denn zwei populäre Implementierungen können helfen: Þ Apache Commons BeanUtils (http://commons.apache.org/beanutils/):
Die Klasse org.apache.commons.beanutils.BeanUtils bietet praktische statische Methoden wie copyProperty(Object bean, String name, Object value), copyProperties(Object dest, Object orig), Object cloneBean(Object bean) oder populate(Object bean, Map properties). Þ Dozer (http://dozer.sourceforge.net/): Dozer bringt ausgefeilte Mapping-Möglichkeiten
mit, die weit über BeansUtils hinausgehen. Das geht so weit, dass es ein Eclipse-Plugin zur Konfiguration der Abbildungen gibt.
18.4.6 Private Attribute ändern Wenn es der Sicherheitsmanager zulässt, kann ein Programm auch private- oder protectedAttribute ändern und Methoden/Konstruktoren eingeschränkter Sichtbarkeit aufrufen. Die Schlüsselfigur in diesem Spiel ist die Oberklasse java.lang.reflect.AccessibleObject, die den Klassen Constructor, Field und Method die Methode setAccessible(boolean) vererbt. Ist das Argument true und lässt der Sicherheitsmanager die Operation zu, lässt sich auf jedes Element (also Konstruktor, Attribut oder Methode) zugreifen:
1262
18.4
Objekte erzeugen und manipulieren
Listing 18.16: com/tutego/insel/meta/ReadPrivate.java package com.tutego.insel.meta; public class ReadPrivate { @SuppressWarnings( "all" ) private String privateKey = "Schnuppelhase"; public static void main( String[] args ) throws Exception { ReadPrivate key = new ReadPrivate(); Class c = key.getClass(); java.lang.reflect.Field field = c.getDeclaredField( "privateKey" ); field.setAccessible( true ); System.out.println( field.get(key) ); // Schnuppelhase field.set( key, "Schnuckibutzihasidrachelchen"); System.out.println( field.get(key) ); // Schnuckibutzihasidrachelchen } }
Warnung Mit dieser Technik lässt sich viel Unsinn anrichten. Es gibt Dinge, die in der Laufzeitumgebung einfach fest sein müssen. Dazu zählen einmal angelegte Strings oder Wrapper-Objekte. Strings sind immutable, weil sie intern in einem privaten char-Feld gehalten werden und es keine Modifikationsmöglichkeiten gibt. Auch Wrapper-Objekte sind, wenn sie einmal mit einem Konstruktor angelegt wurden, nicht über öffentliche Methoden veränderbar. Sie anschließend per Reflection zu modifzieren bringt große Unordnung, insbesondere bei den gecachten Integer/Long-Wrapper-Objekten, die die statischen valueOf()-Methoden liefern.
18.4.7
Methoden aufrufen
Nach dem Abfragen und Setzen von Variablenwerten und Konstruktor-Aufrufen zum Erzeugen eines Objekts ist das Aufrufen von Methoden per Reflection der letzte Schritt. Wenn zur Compilezeit der Name der Methode nicht feststeht, lässt sich zur Laufzeit dennoch eine im Programm deklarierte Methode aufrufen, wenn ihr Name als Zeichenkette vorliegt.
1263
18
18
Reflection und Annotationen
Zunächst gehen wir wieder von einem Class-Objekt aus, das die Klasse des Objekts beschreibt, für das eine Objektmethode aufgerufen werden soll. Anschließend wird ein Method-Objekt als Beschreibung der gewünschten Methode benötigt; wir bekommen dies mit der Methode getMethod() aus dem Class-Exemplar. getMethod() verlangt zwei Argumente: einen String mit dem Namen der Methode und ein Array von Class-Objekten. Jedes Element dieses Arrays entspricht einem Parametertyp aus der Signatur der Methode. Damit werden überladene Methoden unterschieden. Nachdem wir das beschreibende Method-Exemplar und die Parameterwerte für den Aufruf vorbereitet haben, ruft invoke() die Zielmethode auf – im Englischen heißt dies dynamic invocation. invoke() erwartet zwei Argumente: ein Array mit Argumenten, die der aufgerufenen Methode übergeben werden, und eine Referenz auf das Objekt, auf dem die Methode aufgerufen werden soll und zur Auflösung der dynamischen Bindung dient. final class java.lang.reflect.Method extends AccessibleObject implements GenericDeclaration, Member Þ Object invoke(Object obj, Object... args)
throws IllegalAccessException, IllegalArgumentException, InvocationTargetException
Ruft eine Methode des Objekts obj mit den gegebenen Argumenten auf. Wie schon beim Konstruktor löst die Methode eine InvocationTargetException aus, wenn die aufzurufende Methode eine Exception auslöst.
Beispiel Wir erzeugen ein Point-Objekt und setzen im Konstruktor den x-Wert auf 10. Anschließend fragen wir mit der Methode getX(), die wir dynamisch aufrufen, den x-Wert wieder ab: Listing 18.17: com/tutego/insel/meta/InvokeMethod.java, main() Point p = new Point( 10, 0 ); Method method = p.getClass().getMethod( "getX" ); String returnType = method.getReturnType().getName(); Object returnValue = method.invoke( p ); System.out.printf( "(%s) %s", returnType, returnValue ); // (double) 10.0
Beispiele der Varargs sind bei getMethod() die Parametertypen und bei invoke() die Argumente für setLocation(). Da getMethod() eine beliebige Anzahl von Argumenten annehmen kann und kein Argument dazuzählt, muss die Methode nicht so parametrisiert werden: Method method = p.getClass().getMethod( "getX", (Class[]) null );
1264
18.4
Objekte erzeugen und manipulieren
Auffälliger ist die Möglichkeit der variablen Argumentanzahl bei invoke(). Da ein Getter keine Parameter besitzt, heißt es kurz method.invoke(p); statt wie vor Java 5: method.invoke( p, (Object[]) null );
Interessant sind Methoden mit Parameterliste, wie setLocation(): Point p = new Point(); Method method = p.getClass().getMethod( "setLocation", int.class, int.class ); method.invoke( p, 1, 2 ); System.out.println( p );
18.4.8 Statische Methoden aufrufen Wir wollen ein Beispiel programmieren, in dem die Klasse InvokeMain die statische main()-Methode einer anderen Klasse, HasMain, mit einem Parameter aufruft: Listing 18.18: com/tutego/insel/meta/InvokeMain.java package com.tutego.insel.meta; import java.lang.reflect.*; import java.util.Arrays; public class InvokeMain
18
{ public static void main( String[] args ) throws Exception { String[] argv = { "-option", "Parameter" }; Method method = Class.forName( "com.tutego.insel.meta.HasMain" ). getMethod( "main", argv.getClass() ); method.invoke( null, new Object[]{ argv } ); } } class HasMain { public static void main( String[] args )
1265
18
Reflection und Annotationen
{ System.out.println( "Got: " + Arrays.toString( args ) ); } }
18.4.9 Dynamische Methodenaufrufe bei festen Methoden beschleunigen * Werden über Reflection Methoden aufgerufen, deren Methodennamen erst zur Laufzeit bestimmt werden, so verlieren wir die Typsicherheit vom Compiler, und die Geschwindigkeit ist nicht optimal – auch wenn es seit Java 5 nicht mehr so schlimm ist (doch immer noch zeigt eine einfache Zeitmessung einen deutlichen Unterschied). Diese Aufrufe lassen sich prinzipbedingt auch durch einen JIT-Compiler nicht weiter beschleunigen. Wir müssen also nach einer Lösung suchen, mit der wir diese Art von Aufruf beschleunigen können. Ein möglicher Weg hierbei ist, in Kenntnis des Namens der Methode – nennen wir die Methode meth() – den Namen in einer (abstrakten) Oberklasse dem Compiler bereits bekannt zu machen. Reflection ist nur zum Laden einer Unterklasse mit gegebenem Namen nötig; die normale, dynamische Methodenbindung erledigt den Rest – ganz ohne versteckte Schnüre, doppelte Böden oder Spiegel (Reflection). Versuchen wir, den folgenden Code nach diesem Schema zu ändern: Listing 18.19: com/tutego/insel/meta/DynamReflection.java, main() Class clazz = Class.forName("com.tutego.insel.meta.DynamReflectionMethod" ); Object o = clazz.newInstance(); clazz.getMethod( "meth" ).invoke( o ); DynamReflection ist die Hauptklasse, die die Klasse DynamReflectionMethod über Class.forName()
anfordert: Listing 18.20: com/tutego/insel/meta/DynamReflectionMethod.java package com.tutego.insel.meta; public class DynamReflectionMethod { @Override public void meth() { System.out.println( "Bewusste Raucher trinken Filterkaffee" ); } }
1266
18.4
Objekte erzeugen und manipulieren
Über das Class-Objekt erzeugt newInstance() ein neues Exemplar. getMethod() sucht die Beschreibung der Methode meth() heraus, und invoke() ruft die Methode meth() auf. Hier genau entsteht ein kleiner Geschwindigkeitsverlust. Wenn es uns gelänge, um das invoke() herumzukommen, wäre das schon ein großer Fortschritt. Dies schaffen wir, indem wir eine Schnittstelle (oder Oberklasse) für DynamReflectionMethod konstruieren, die genau diese Methode vorschreibt. Die implementierende Klasse (beziehungsweise Unterklasse) wird dann eine Implementierung angeben: Listing 18.21: com/tutego/insel/meta/DynamAbstract.java package com.tutego.insel.meta; interface DynamBase { void meth(); } class DynamBaseMethod implements DynamBase { public void meth() { System.out.println( "Bewusste Raucher trinken Filterkaffee" ); } }
18
public class DynamAbstract { public static void main( String[] args ) throws Exception { Class clazz = Class.forName( "com.tutego.insel.meta.DynamBaseMethod" ); DynamBase o = (DynamBase) clazz.newInstance(); o.meth(); } } DynamBase ist eine Schnittstelle, die zur Übersetzungszeit bekannt ist. Die virtuelle Maschine
löst den Aufruf nach den üblichen Regeln der dynamischen Bindung selbst auf. Die Klasse DynamBaseMethod wird ebenfalls erst zur Laufzeit geladen. Wir verstecken hier sehr elegant den Aufwand. Wir haben die gleiche Funktionalität und Flexibilität wie im vorangegangenen Reflection-Beispiel – wenn wir die Möglichkeit, den Klassennamen durch einen String anzu-
1267
18
Reflection und Annotationen
geben, außer Acht lassen –, aber mit der höheren Geschwindigkeit eines konventionellen Methodenaufrufs ohne Reflection.
Hinweis Der Aufruf von Class.forName() liefert ein Class-Objekt, bei dem Typ nicht bekannt ist. Daher ist unsere Variable clazz mit Class deklariert. Bei newInstance() ist dann auch eine explizite Typanpassung auf den Ergebnistyp nötig, was nicht nötig wäre, wenn das Class-Objekt korrekter wäre. Um das Class-Objekt von Class.forName() zu spezialisieren, gibt es eine Methode asSubclass(). Dann lässt sich statt dem bekannten Class clazz = Class.forName( "DynamBaseMethod" ); DynamBase o = (DynamBase) clazz.newInstance();
Folgendes schreiben: Class findClass( String name ) throws ClassNotFoundException { MemJavaFileObject fileObject = classFiles.get( name ); if ( fileObject != null ) { byte[] bytes = fileObject.getClassBytes();
1305
19
Dynamische Übersetzung und Skriptsprachen
return defineClass( name, bytes, 0, bytes.length ); } return super.findClass( name ); } }
19.3
Ausführen von Skripten
Seit Java 6 bietet die Standardbibliothek über das Paket javax.script eine API, um Skriptsprachen wie JavaScript, Groovy oder Jython anzusprechen. Diese API wurde im JSR-223, »Scripting for the Java Platform«, definiert, und das Standard-JDK und JRE bringt mit Rhino (http://www.mozilla.org/rhino/ScriptingJava.html) einen Interpreter für JavaScript mit. (Bei anderen Java SE-Implementierungen muss das nicht zwingend gegeben sein.) Das in Java 6 neu ins bin-Verzeichnis aufgenommene Kommandozeilenprogramm jrunscript ermöglicht das Setzen von Variablen, das Ausführen von Skript-Code und das Auswerten von Ergebnissen. Eine Skript-Sprache kann auf den vollen Umfang der Java-API zurückgreifen, definiert aber üblicherweise auch eigene Bibliotheken.
Beispiel Führe ein simples Skript über das Kommandozeilenprogramm aus: $ jrunscript -e "print('Hallo JavaScript')"
Eine Skript-Engine führt die Skripte aus, indem sie das Parsen, Interpretieren und Verwalten der Objekte übernimmt. Rhino übernimmt JavaScript, doch die Webseite https://scripting.dev.java.net/ führt mehr als 10 weitere Skriptsprachen auf, die sich über die neue API integrieren lassen.
19.3.1
JavaScript-Programme ausführen
Bevor wir uns mit der Java-Seite beschäftigen, wollen wir ein kleines JavaScript-Programm schreiben. Es liest aus einer Variablen im Kontext, gibt etwas auf der Konsole aus und deklariert und initialisiert eine neue Variable.
1306
19.3
Ausführen von Skripten
Listing 19.12: com/tutego/insel/script/tutego.js f = new javax.swing.JFrame() f.setSize( 500, 100 ) f.defaultCloseOperation = javax.swing.JFrame.EXIT_ON_CLOSE f.title = "Hallo " + name + "." f.visible = true today = new Date() println( today ) month = today.getMonth() + 1
Damit ein Java-Programm das Skript laden und ausführen kann, sind nur zwei Klassen nötig. Der ScriptEngineManager verschafft uns Zugang zu einer gewünschten Skript-Engine. Erfragt wird eine Skript-Engine über einen Namen (wie »JavaScript«) oder über einer Dateiendung, die die Skript-Dateien üblicherweise haben (wie »js«). Listing 19.13: com/tutego/insel/script/JavaScriptDemo.java, Teil 1 package com.tutego.insel.script; import java.io.InputStreamReader; import javax.script.*; public class ScriptDemo { public static void main( String[] args ) throws ScriptException
19
{ ScriptEngine engine = new ScriptEngineManager().getEngineByName("JavaScript");
Die Methode getEngineByName() liefert ein ScriptEngine-Objekt, dessen eval()-Methoden die Interpretation starten. Listing 19.14: com/tutego/insel/script/JavaScriptDemo.java, Teil 2 engine.put( "name", "Christian Ullenboom" ); engine.eval( new InputStreamReader( ScriptDemo.class.getResourceAsStream( "tutego.js" ) ) ); System.out.println( engine.get( "month" ) ); } }
1307
19
Dynamische Übersetzung und Skriptsprachen
Ausgeführt stellt das Programm ein Swing-Fenster dar und gibt Folgendes auf der Konsole aus: Hallo Christian Ullenboom. Sun Jul 08 2007 15:25:12 GMT+0200 (CEST) 7.0
19.3.2
Groovy
Groovy (http://groovy.codehaus.org/) ist eine objektorientierte Skriptsprache, die auf einer JVM läuft und vollen Zugriff auf alle Java-Bibliotheken bietet. Die Sprache hat viele interessante Eigenschaften, die sie zu Java 2.0 machen – wenn wir die jetzige Version Java 1.7 nennen wollen. Groovy setzt auf der Standard-Java-Syntax auf und erweitert diese.1 Einige Höhepunkte: Groovy-Feature
Beispiel
Statt System.out.print()/
println 1 + 2
println() reicht ein print bzw.
print "Wow"
println, und dann muss das Argu-
ment auch nicht in runden Klammern stehen. Anweisungen müssen nicht immer
print "Wow"
mit einem Semikolon abgeschlos-
print "Wow"; print "Wow"
sen werden, sondern nur dann, wenn mehrere Anweisungen in einer Zeile stehen. Variablen müssen nicht mit einem
def age = 40
Typ deklariert werden, das gilt auch
def greet( name ) { print "Hallo " + name }
bei catch oder Methoden/Kon-
try { } catch ( e ) { }
struktoren. Zeichenketten lassen sich mit ein-
print "Ja" == 'Ja'
fachen oder doppelten Anfüh-
def sign = "-" as char
// true
rungszeichen angeben. Einzelne Zeichen (char/Character) müssen besonders aufgebaut werden. Tabelle 19.3: Eigenschaften von Groovy mit Beispiel
1
Bis auf sehr kleine Ausnahmen ist jedes Java-Programm ein Groovy-Programm.
1308
19.3
Groovy-Feature
Beispiel
Strings in doppelten Anführungs-
def one = 1
zeichen sind besondere GStrings:
print "$one plus $one macht ${1+1}"
Enthalten sie $variable bzw.
// 1 plus 1 macht 2
Ausführen von Skripten
${ausdruck}, so wird der Inhalt der
Variablen bzw. der ausgewertete Ausdruck eingesetzt. Strings können über mehrere Zei-
print """
len laufen, wenn sie in """ oder '''
Zeile 1
eingeschlossen sind – folgt ein
Zeile 2\
Backslash am Ende der Zeile, wird
Weiter mit Zeile 2
kein Zeilenumbruchzeichen einge-
"""
fügt. Alles ungleich 0 und null ist true.
if ( 1 ) print 'Zweig wird genommen'
Groovy definiert einen neuen Da-
def numbes = 0..9
tentyp für Bereiche (engl. ranges).
def number = 0... Falls jetzt ein Setup Alert kommt, kann dieser mit OK geschlossen werden. 7. Wähle aus dem Zweig Devel den Eintrag gcc-core (bzw. gcc-g++). (Den gdb können wir angeben, wenn C-Programme debuggt werden sollen.) Dann Weiter >. Die Wahl selektiert automatisch ein paar weitere abgeleitete Pakete und zeigt sie an. Dann Weiter >. Der tatsächliche Download beginnt. 8. Es lassen sich Icons setzen. Sie sind nicht nötig und können abgewählt werden. Weiter > schließt die Installation ab.
Übersetzen mit Ant Das Build-Tool Ant bringt in der Standard-Distribution keinen Task mit, der einen C-Compiler anstößt. Nichtsdestotrotz lassen sich mit externe Programme aufrufen. Somit sieht das ganze Build-Skript folgendermaßen aus: Listing 21.6: build.xml
1344
21.4
Nativ die Stringlänge ermitteln
Hinweis Die dynamische Bibliothek muss unter Windows die Endung .dll und unter Unix-Systemen die Endung .so haben. In der Unix-Welt beginnen die dynamischen Bibliotheken mit dem Präfix lib, sodass sich daraus für eine Datei die Namensgebung libName.so ergibt. Wer den -Task nicht verwenden mag, der kann auch die externen CC-Tasks unter http://ant-contrib.sourceforge.net/ nutzen.
21
21.4
Nativ die Stringlänge ermitteln
Wir haben unsere Funktion noch nicht zu Ende geführt. Es fehlt die Berechnung der Zeichenkettenlänge, für die wir den String zuerst von der Unicode-Implementierung in ein C-Zeichenfeld überführen müssen. Dazu dient eine JNI-Funktion GetStringUTFChars(), die wir über die Umgebung env nutzen können. const char* str = (*env)->GetStringUTFChars( env, s, NULL );
1345
21
Java Native Interface (JNI)
1
Hinweis Die Schreibweisen unterscheiden sich im Fall von C oder C++. Während es bei C const char* str = (*env)->GetStringUTFChars( env, s, NULL );
heißt, schreiben wir bei C++: const char* str = env->GetStringUTFChars( s, NULL );
In der objektorientierten C++-Variante ist env als Argument nicht mehr nötig. Wir bleiben bei unseren Buchbeispielen in der prozeduralen C-Welt und übergeben daher allen JNI-Funktionen das JNIEnv.1 Die Zeichenkettenlänge liefert die C-Funktion strlen(), die im Header string.h definiert ist: Listing 21.7: strlen.c #include #include "strlen.h" #include #include JNIEXPORT jint JNICALL Java_com_tutego_jni_StrLen_strlen( JNIEnv *env, jclass clazz, jstring s ) { if ( s == NULL ) { jclass exc = (*env)->FindClass( env, "java/lang/NullPointerException" ); if ( exc != NULL ) (*env)->ThrowNew( env, exc, "(in C code)" ); return –1; } const char* str = (*env)->GetStringUTFChars( env, s, NULL ); if ( str == NULL )
1
Siehe dazu unter http://java.sun.com/javase/6/docs/technotes/guides/jni/spec/design.html den Punkt »Native Method Arguments«.
1346
21.5
Erweiterte JNI-Eigenschaften
return –1; int len = strlen( str ); (*env)->ReleaseStringUTFChars( env, s, str ); return (jint) len; }
Mit JNI lassen sich auf der C-Seite Java-Objekte erzeugen und zerstören, genauso wie sich JavaMethoden aufrufen und Werte austauschen lassen. Wir nutzen das, um ein Ausnahme-Objekt zu erzeugen, wenn es keine Referenz auf ein String-Objekt gibt.
21.5
Erweiterte JNI-Eigenschaften
Im letzten Beispiel haben wir auf der Java-Seite wenig unternommen beziehungsweise lediglich eine C-Funktion aufgerufen und ein Ergebnis zurückgegeben. Nun wollen wir Objekteigenschaften auslesen, Methoden aufrufen und Objekte erzeugen. JNI bietet noch mehr als nur die Übergabe von primitiven Datentypen und Strings.
21.5.1
Klassendefinitionen
JNI repräsentiert ein Java-Objekt durch jobject. Um auf Attribute eines Java-Objekts zuzugreifen, müssen wir zunächst die Klassendefinition erfragen. Wir kennen das bereits aus Kapitel 18, »Reflection und Annotationen«:
21 Class clazz = o.getClass();
Ähnlich funktioniert das in JNI. Dort benutzen wir die JNI-Funktion GetObjectClass(): jclass jclass;
// Zuweisung mit Initialisierung in klassischem C nicht möglich
jclass = (*env)->GetObjectClass( env, obj ); obj repräsentiert das Objekt, für das wir die Klassendefinition besorgen.
Und wie auch Reflection nicht nur mit getClass() das Class-Objekt liefert, sondern auch eine Suche nach dem Klassenamen mit Class.forName() bietet, so ermöglicht JNI Ähnliches mit FindClass(). jclass = (*env)->FindClass( env, "Klassenname" );
1347
21
Java Native Interface (JNI)
Beispiel Ein Exemplar der Klasse C wird einer nativen Funktion übergeben. Die Deklaration der nativen Methode in Java ist folgende: native void foo( C c );
Die Übersetzung liefert uns in etwa: JNIEXPORT jobject JNICALL foo( JNIEnv *env, jobject in_c )
Es holt GetObjectClass() die Klassendefinition, die anschließend in jclass steht: jclass jclass = (*env)->GetObjectClass( env, in_c );
21.5.2
Zugriff auf Attribute
Um unter Reflection auf die Attribute zuzugreifen, muss das Class-Objekt ein Field-Objekt akquirieren: Field field = clazz.getField( Feldname );
Ähnlich funktioniert auch dieses wieder in JNI. Mit der JNI-Funktion GetFieldID() erhalten wir einen Zeiger auf den Speicherplatz eines Felds.
Beispiel Jetzt müssen wir nur über unsere Klasse C weitere Aussagen machen. Geben wir Folgendes vor: class C { int i; }
Um die Attribut-ID zu erlangen, schreiben wir: jfieldID jfid; jfid = (*env)->GetFieldID( env, jclass, "i", "I");
Den zweiten Parameter entlarven wir als Zeiger auf die Klassendefinition. Das dritte Argument kennzeichnet den Namen der Variablen (i in der Klasse C), und das letzte Argument bestimmt den Typ der Variablen. Das große I kennzeichnet einen Integer, und die anderen Typen haben wir schon einmal beleuchtet. Zur Wiederholung:
1348
21.5
Signatur
Typ
Z
boolean
B
Byte
C
Char
S
Short
I
Int
J
Long
F
Float
D
Double
V
Void
LvollQualifizierterName;
Objekttyp
[Typ
Feld mit Typ
Erweiterte JNI-Eigenschaften
Tabelle 21.1: Kodierung von Typen
Der letzte Schritt ist das Auslesen beziehungsweise Setzen der Werte. Wiederum soll uns Reflection eine Orientierung geben: Class clazz = o.getClass(); Field field = clazz.getField( Feldname ); field.setAttribute( o, new Integer(9) );
Beispiel Die JNI-Funktion GetIntField() liest das Attribut des Objekts aus: jfieldID jfid;
21
jclass jclass; jint val; jclass = (*env)->GetObjectClass( env, in_c ); jfid
= (*env)->GetFieldID( env, jclass, "i", "I");
val
= (*env)->GetIntField( env, in_c, jfid );
Für die unterschiedlichen Typen stehen ebenfalls ganz unterschiedliche GetXXXField()-Funktionen zur Verfügung. Die Tabelle fasst sie zusammen:
1349
21
Java Native Interface (JNI)
GetField
Nativer Typ
Java-Typ
GetObjectField()
jobject
Object
GetBooleanField()
jboolean
boolean
GetByteField()
Jbyte
byte
GetCharField()
Jchar
char
GetShortField()
Jshort
short
GetIntField()
Jint
int
GetLongField()
Jlong
long
GetFloatField()
Jfloat
float
GetDoubleField()
jdouble
double
Tabelle 21.2: Zugriff auf Attribute von Java-Objekten
Die entsprechenden SetXXXField()-Funktionen lassen sich leicht ableiten. Die letzte Frage ist die nach den Datentypen. Die anschließende Tabelle zeigt, welcher Java-Typ welchem nativen Typ zugeordnet ist und wie die Wertebereiche sind: Java-Typ
Nativer Typ
Beschreibung
boolean
jboolean
8 Bit ohne Vorzeichen
byte
jbyte
8 Bit mit Vorzeichen
char
jchar
16 Bit ohne Vorzeichen
short
jshort
16 Bit mit Vorzeichen
int
iint
32 Bit mit Vorzeichen
long
jlong
64 Bit mit Vorzeichen
float
jfloat
32 Bit
double
jdouble
64 Bit
void
void
Tabelle 21.3: Mapping zwischen Javas primitiven Datentypen (sowie void) und C
21.5.3
Methoden aufrufen
So wie bei Attributzugriffen eine jfieldID nötig ist, so bedarf es bei Methodenaufrufen einer jmethodID. Diese liefert die Methode GetMethodID() für Objektfunktionen und GetStaticMethodID() für statische Funktionen. Anzugeben bei der ID-Suche ist der Name der Funktion und als String kodiert der Rückgabetyp und die Parametertypen. Ist das Ergebnis des Methodenaufrufs 0, so gibt es die Methode nicht.
1350
21.5
Erweiterte JNI-Eigenschaften
id = (*env) -> GetMethodID( env, cls, "getAbsolutePath", "()Ljava/lang/String;" ); if ( id == 0 ) { /* Fehlerbehandlung */ }
Hinweis Für die nicht so intuitive String-Signatur der Methode bietet sich das Dienstprogramm javap mit dem Schalter -s an. $ javap -s java.io.File
Der relevante Ausschnitt in unserem Fall lautet: public class java.io.File extends java.lang.Object implements java.io.Serializable,java.lang.Comparable{ public java.lang.String getAbsolutePath(); Signature: ()Ljava/lang/String; }
Die Funktionen CallObjectMethod() bzw. CallStaticMethod() rufen mit der jmethodID die JavaFunktion auf. Sie sind für alle Funktionen gedacht, die ein Objekt (also auch Felder) zum Ergebnis haben. id = (*env) -> GetMethodID( env, cls, "getAbsolutePath", "()Ljava/lang/String;" ); obj = (*env) -> CallObjectMethod( env, file, id );
Ist das Ergebnis ein primitiver Typ, steht der Typ der Rückgabe im Funktionsnamen – der Bauplan für die Namen ist CallTypMethod() bzw. CallStaticTypMethod(), also etwa CallBooleanMethod(). Im Fall keiner Rückgabe steht für den Typ einfach Void, wie CallStaticVoidMethod(). In unserem Beispiel mit getAbsolutePath() vom File-Ojekt hat die Methode keinen Parameter. Die C-Methoden CallMethod() bzw. CallStaticMethod() sind so definiert, dass sie Argumente per Varargs annehmen: CallMethod( JNIEnv *env, jclass clazz, jmethodID methodID, ... ); CallStaticMethod( JNIEnv *env, jclass clazz, jmethodID methodID, ... );
Neben den mit ... definierten Varargs gibt es zwei weitere Varianten für alle Funktionen, die auf "A" beziehungsweise auf "V" enden. Þ CallStaticMethodA(JNIEnv *env, jclass clazz, jmethodID methodID, jvalue *args); Þ CallMethodA(JNIEnv *env, jclass clazz, jmethodID methodID, jvalue *args); Þ CallStaticMethodV(JNIEnv *env, jclass clazz, jmethodID methodID, va_list args); Þ CallObjectMethodV(JNIEnv *env, jclass clazz, jmethodID methodID, va_list args);
1351
21
21
Java Native Interface (JNI)
Die Funktionen mit der Endung "A" nehmen die Argumente für die Java-Funktion über einen Verweis auf ein jvalue-Feld an, und die Methode mit der Endung "V" nimmt die Argumente in einer Struktur vom Typ va_list an.
21.5.4
Threads und Synchronisation
Die Struktur JNIEnv bietet zur Synchronisation die zwei Funktionen, um das Betreten und Verlassen eines synchronisierten Blocks nachzubilden. Þ jint MonitorEnter(JNIEnv *env, jobject obj); Þ jint MonitorExit(JNIEnv *env, jobject obj);
Das zweite Argument ist genau das Lock-Objekt, an dem synchronisiert wird. Während in purem Java die Laufzeitumgebung bei einer Exception den Lock wieder freigibt, müssten wir das in C selbst überwachen.
21.6
Einfache Anbindung von existierenden Bibliotheken
Die Arbeit mit JNI ist nicht besonders komfortabel, sodass im Laufe der Zeit einige Vereinfachungen entstanden sind. Auf der einen Seite stehen Quellcodegeneratoren, auf der anderen Seite sehr dynamische Lösungen.
21.6.1
Generieren von JNI-Wrappern aus C++-Klassen und C-Headern
cxxwrap (http://cxxwrap.sourceforge.net/) liest Header-Dateien von C++ ein und generiert automatisch für die Klassen Stellvertreter auf der Java-Seite sowie Delegates in JNI, die auf die tatsächliche Implementierung weiterleiten. Aus den Beschreibungen der Header-Dateien nimmt cxxwrap nicht nur die Klassen mit Methoden, sondern auch die Konstanten. Auch versucht cxxwrap, so gut wie möglich die Parametertypen zu übersetzen, etwa char unsigned char in byte, und Pointer auf primitive Zellen in Arrays umzusetzen. Die Konstruktoren, Destruktoren und Methoden werden von der Java-Seite auf die C++-Seite weitergeleitet. Das Projekt wurde schon lange nicht mehr gepflegt, aber da sich die JNI-API auch nicht groß verändert hat, kann cxxwarp ein erster Start sein. Eine aktuellere Alternative ist gluegen (https:// gluegen.dev.java.net/). gluegen wird verwendet, um die Open GL-Schnittstellen nach Java zu bringen. Dazu liest es die C-Header-Dateien und macht so die Methoden für Java-Programme zugänglich.
1352
21.7
Invocation-API
Ein weiterer Generator ist SWIG (Simplified Wrapper and Interface Generator) unter http:// www.swig.org/. Mit einer zu schreibenden Interface-Datei generiert SWIG den JNI-Code für den Zugriff auf existierende C(++)-Programme. Das Projekt ist sehr aktiv.
21.6.2
COM-Schnittstellen anzapfen
Sind die nativen Methoden über COM zugänglich, ermöglichen die Bibliotheken Jawin (http:// jawinproject.sourceforge.net/) und com4j (https://com4j.dev.java.net/) mit einer kleinen nativen Bibliothek einfachen Zugriff auf diese Ressourcen; besonders praktisch ist das für MS Office, da es sich so praktisch fernsteuern lässt. com4j ist besonders nützlich, denn ein Generator erzeugt Java-Wrapper, sodass typsicheres Arbeiten möglich ist. Damit Programme mit com4j übersetzt und zum Laufen gebracht werden können, muss sich com4j.jar im Klassenpfad befinden und com4j.dll im Suchpfad für externe native Bibliotheken stehen. Ein Beispiel für Word liegt der Distribution bei. Jawin wurde schon länger nicht mehr aktualisiert, tut jedoch seine Dienste. com4j ist aktueller, aber auch seit drei Jahren ohne Update.
21.7
Invocation-API
Bisher haben wir JNI nur als Einbahnstraße gesehen (nicht im negativen Sinne). Doch anstatt nur aus Java heraus ein C(++)-Programm anzubinden, bietet JNI auch den anderen Weg: Ein C(++)-Programm kann die gesamte JVM einbetten. Das ist über die Invocation API möglich. Im Prinzip recht Folgendes aus: #include int main()
21
{ JavaVM *jvm; JNIEnv *env; JavaVMInitArgs jvmargs; jint r; jvmargs.nOptions = 0; jvmargs.version = JNI_VERSION_1_7; r = JNI_CreateJavaVM( &jvm, (void**)&env, &jvmargs ); if ( r < 0 )
1353
21
Java Native Interface (JNI)
return –1; // Ab hier ist über env alles möglich wie vorher (*jvm)->DestroyJavaVM( jvm ); }
Wer das Programm übersetzt, der sollte daran denken, die dynamische Bibliothek jvm.dll im Suchpfad zu haben; die Datei befindet sich im Java-Verzeichnis unter jre7\bin\client.
21.8
Zum Weiterlesen
Die Java Native Interface Specification unter http://download.oracle.com/javase/7/docs/technotes/guides/jni/spec/jniTOC.html ist eine der wichtigsten Quellen für diejenigen, mit intensiver mit JNI arbeiten wollen. Im Tutorial-Stil sind http://java.sun.com/developer/onlineTraining/Programming/JDCBook/jniref.html und http://java.sun.com/docs/books/tutorialNB/ download/tut-native1dot1.zip gute Lernquellen. Eine JNI-FAQ bietet die Webseite von JGuru: http://tutego.de/go/jnifaq und http://mindprod.com/jgloss/jni.html. Eine Bibliothek zum Ansprechen von dynamischen Bibliotheken ist JNA (Java Native Access) unter https:// jna.dev.java.net/. Mit JNI kommen Entwickler hier gar nicht in Kontakt. Mehr Informationen zur Invocation API gibt http://download.oracle.com/javase/7/docs/technotes/guides/jni/spec/ invocation.html.
1354
Kapitel 22 Sicherheitskonzepte »Vorsicht ist die Einstellung, die das Leben sicherer macht, aber selten glücklich.« – Samuel Johnson (1709–1784)
22.1
Zentrale Elemente der Java-Sicherheit
Damit Java-Programme sicher arbeiten, greift eine Reihe von Elementen ineinander. Einige Dinge gibt schon die Sprache selbst vor (wie fehlende Pointerarithmetik, Sichtbarkeitsbereiche, Überwachung der Feldgrenzen), und andere ergeben sich durch die Laufzeitumgebung selbst. Zunächst ist da der Bytecode Verifier, der grob sicherstellt, dass der Java-Bytecode korrekt geformt ist. Zu den Prüfungen zählen zum Beispiel, dass Bytecode nicht in der Mitte enden darf, dass der Index auf Variablen korrekt ist und dass Sprünge nicht außerhalb des Programmcodes erfolgen. Der Klassenlader ist die nächste Einheit, und sein Einfluss auf die Sicherheit ist nicht offensichtlich. Er stellt jedoch sicher, dass sich Klassen in Paketen nicht überschreiben können und dass ein selbst geschriebenes java.lang.Object nicht plötzlich das Original überdeckt; beide befinden sich in unterschiedlichen Runtime Packages. Durch eine Hierarchie der Klassenlader kommt eine Anforderung an die Klasse java.lang.Object auch zuerst an den obersten Vater-Klassenlader, den Bootstrap Class Loader. Sind die Klassen geladen, überwacht zur Laufzeit der Sicherheitsmanager gültige Aufrufe; er sitzt immer zwischen unserer Java-Applikation und dem Betriebssystem. Der Sicherheitsmanager existiert seit Java 1.0, gibt aber die Arbeit seit Java 1.2 an eine verallgemeinerte Einheit, den Access Controller, weiter. Er nutzt Tricks wie Stack-Überprüfung, um herauszufinden, ob Aufrufer einer Methode schon gewisse Rechte erworben haben, um die Operation ausführen zu können. Der Access Controller stellt sicher, dass Programmcode nur dann ausgeführt werden kann, wenn die passenden Rechte vorhanden sind.
22.1.1
Security-API der Java SE
Die Gesamtheit aller Bibliotheken, die sich in Java um die Sicherheit kümmern, wird SecurityAPI genannt. Sie gesteht aus unterschiedlichen Teilen:
1355
22
22
Sicherheitskonzepte
Þ Verschlüsselung und Nachrichten-Authentifizierung. Seit Java 1.1 gibt es die Java-Crypto-
graphy-API. Die Java Cryptography Architecture (JCA) beschreibt, wie diese API benutzt werden kann. Ihr ist das Paket java.security gewidmet. In Java 1.4 ist dann die Java Cryptography Extension (JCE) hinzugekommen, die vorher nur als optionales Paket seit 1.2 erhältlich war. Sie erweitert die Möglichkeiten der JCA. Die Klassen und Schnittstellen sind an dem Paket javax.crypto zu erkennen. Þ Authentifizierung und Zugriffskontrolle. Die Java Authentication and Authorization Ser-
vice (JAAS) ist eine API mit Benutzerauthentifizierung etwa über ein Kerberos-System. Þ Public-Key-Infrastruktur. Sie dient zum Verwalten von Schlüsseln in Keystores und zum
Prüfen von digitalen X.509-Zertifikaten.
22.1.2
Cryptographic Service Providers
Die Security-API ist so entworfen worden, dass über sogenannte Cryptographic Service Provider Implementierungen ausgewechselt werden können. Die Security-API von Java ist völlig unabhängig von der Implementierung der kryptografischen Algorithmen und bietet zunächst Schnittstellen an. Die konkreten Algorithmen wie RSA oder DES realisieren Provider – Oracle ist einer von ihnen und bringt einen Standard-Provider für grundlegende Operationen mit.
Beispiel Welche Provider Java 7 bietet, zeigt folgender Zweiteiler: for ( Provider p : Security.getProviders() ) System.out.println( p + ": " + p.getInfo() );
Das Ergebnis sind zehn Einträge: SUN version 1.7: SUN (DSA key/parameter generation; DSA signing; SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS keystore; PKIX CertPathValidator; PKIX CertPathBuilder; LDAP, Collection CertStores, JavaPolicy Policy; JavaLoginConfig Configuration) SunRsaSign version 1.7: Sun RSA signature provider SunEC version 1.7: Sun Elliptic Curve provider (EC, ECDSA, ECDH) SunJSSE version 1.7: Sun JSSE provider(PKCS12, SunX509 key/trust factories, SSLv3, TLSv1) SunJCE version 1.7: SunJCE Provider (implements RSA, DES, Triple DES, AES, Blowfish, ARCFOUR, RC2, PBE, Diffie-Hellman, HMAC)
1356
22.2
Der Sandkasten (Sandbox)
Beispiel (Forts.) SunJGSS version 1.7: Sun (Kerberos v5, SPNEGO) SunSASL version 1.7: Sun SASL provider(implements client mechanisms for: DIGEST-MD5, GSSAPI, EXTERNAL, PLAIN, CRAM-MD5, NTLM; server mechanisms for: DIGEST-MD5, GSSAPI, CRAM-MD5, NTLM) XMLDSig version 1.0: XMLDSig (DOM XMLSignatureFactory; DOM KeyInfoFactory) SunPCSC version 1.7: Sun PC/SC provider SunMSCAPI version 1.7: Sun's Microsoft Crypto API provider
Jeder Provider implementiert einen oder mehrere Algorithmen. Neue Provider lassen sich jederzeit einbringen, insbesondere dann, wenn uns die Amerikaner nicht erlauben, eine starke Verschlüsselung zu verwenden. Eine genauere Übersicht liefert http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136007.html und http://download.oracle.com/javase/7/ docs/technotes/guides/security/crypto/CryptoSpec.html.
22.2 Der Sandkasten (Sandbox) Seit den ersten Java-Versionen gibt es das Prinzip der Sandbox, wonach Applikationen nur ganz bestimmte Rechte haben und sich nicht mehr ergaunern können. Das gilt insbesondere für Applets im Browser. Sie dürfen nicht das Gleiche tun wie Applikationen: auf Festplatten zugreifen, die Zwischenablage auslesen und vieles mehr. Die Sandbox besteht aus zwei Teilen, die sehr wichtig für die Java-Sicherheit sind: dem Klassenlader (Klasse ClassLoader) und dem Sicherheitsmanager (SecurityManager). Der Klassenlader lädt die .class-Dateien und erzeugt (unter anderem) die dazugehörigen Class-Exemplare. Wir wollen uns in diesem Kapitel intensiver mit dem zweiten Teil, dem Sicherheitsmanager, auseinandersetzen.
1357
22
22
Sicherheitskonzepte
Normale Applikationen benutzen den Standardklassenlader und verwenden keinen Sicherheitsmanager. Applets aus dem Internet fordern besondere Sicherheit, sodass Browser einen besonderen Klassenlader und Sicherheitsmanager nutzen. Der Security-Manager für Applets erlaubt zum Beispiel kein Ausführen von externen Programmen, da auf diese Weise die Festplatte formatiert werden könnte. Auch darf ein Applet keine Klassen von einem fremden Server laden; zulässig ist nur der Server, von dem das Applet selbst geladen wurde. Diese Vorgabe stellt der Klassenlader sicher.
22.3 Sicherheitsmanager (Security Manager) Über Applets wissen wir bereits, dass sie auf einige Ressourcen des Rechners nicht zugreifen dürfen. Zwischen dem Aufrufer einer Bibliotheksmethode und dem Betriebssystem sitzt eine Einheit, die unsere Aktionen genau kontrolliert. Dieses Zwischensystem ist der Sicherheitsmanager. Standardmäßig startet die Laufzeitumgebung für Applikationen ohne Sicherheitsmanager, für Applets gibt es jedoch spezielle Sicherheitsmanager. Jeder Sicherheitsmanager ist eine Unterklasse von SecurityManager. Den aktuellen Sicherheitsmanager liefert die statische Methode System.getSecurityManager(). Führen wir folgende Zeile in einer Applikation aus, so sehen wir, dass anfänglich kein Sicherheitsmanager gesetzt ist, da die Ausgabe null ist. public class ApplicationSecManager { static public void main( String[] args ) { System.out.println( System.getSecurityManager() ); } }
Im Gegensatz dazu sind wir bei Applets mit einem etwas anderen Bild konfrontiert. Das folgende Programm liefert eine Ausgabe wie sun.applet.AppletSecurity@123456 auf dem Bildschirm. Die Zahl ist der Hashcode des Objekts: public class Applet1 extends java.applet.Applet { public void paint( java.awt.Graphics g ) { g.drawString( System.getSecurityManager().toString(), 10, 10 ); } }
1358
22.3
Sicherheitsmanager (Security Manager)
22
Abbildung 22.1: UML-Diagramm für Security-Manager
22.3.1
Der Sicherheitsmanager bei Applets
Die beiden Beispiele machen deutlich, dass dem Applet ein Security-Manager zugewiesen ist und den Applikationen kein Sicherheitsmanager etwas verbietet. Doch was ist einem Applet eigentlich verboten?
1359
22
Sicherheitskonzepte
Þ Applets dürfen nicht auf lokale Dateien des Client-Rechners zugreifen, sie etwa erzeugen,
lesen, modifizieren oder löschen. Sonst könnten sie wichtige Systemdateien an ihren Heimatserver übermitteln, und das stellt ein ernsthaftes Risiko dar. Þ Applets können außerdem keine Netzwerkverbindungen zu anderen Computern als dem
Heimatserver aufnehmen; dies gilt für alle Verbindungen, die mit den Netzwerk-Klassen URL, Socket und DatagramSocket möglich sind – was oft einen Einschnitt darstellt, weil etwa ein Börsenticker-Applet Kursdaten von einem anderen Server holen möchte. Das Internet als verteiltes System sollte auch vollständig genutzt werden können. Da Applets nicht in der Lage sind, Verbindungen zu Fremdrechnern aufzubauen, können sie natürlich auch nicht als Server fungieren. Þ Weiterhin kann ein Applet keine Programme ausführen, die auf dem lokalen Rechner lie-
gen. Applets dürfen auch keine anderen Programme starten und keine nativen Bibliotheken laden. (Für normale System-DLLs bringt das ohnehin nichts, da sie nicht über die benötigte Namenskonvention verfügen.) Þ Threads sind ein etwas anderes Problem. Da alle Applets gemeinsam in einer JVM laufen,
muss gewährleistet sein, dass sich nur die Threads eines Applets (also die Threads in der Thread-Gruppe des Applets) beeinflussen dürfen. In der Vergangenheit traten mehrfach Sicherheitsprobleme auf, bei denen sich Threads verschiedener Applets in die Quere kamen. Auch darf kein Applet die gemeinsam genutzte virtuelle Maschine beenden. Þ Applets dürfen keinen eigenen Sicherheitsmanager installieren. Könnte ein Applet das tun,
ließen sich leicht die für Applets geltenden Beschränkungen aushebeln. Der Java-fähige Webbrowser erzeugt für uns ein spezielles ClassLoader-Objekt, das abgesichert arbeitet. Þ Die Java-Umgebung setzt automatisch einige Properties, damit unser Programm etwas
über seine Umgebung erfahren kann. Diese Variablen lassen sich über System.getProperty(String) auslesen. Applets dürfen nur manche Variablen lesen. Sie haben keinen Zu-
griff auf Informationen über das Java-Home-Directory, den Java-Klassenpfad, den User-Namen, das Home-Verzeichnis und das Arbeitsverzeichnis des Anwenders. Die anderen Daten in den Variablen sind frei. Dazu gehören etwa: java.version, java.vendor, java.vendor.url, java.class.version, os.name, os.arch, os.version, file.separator, path.separator, line.separator. Obwohl diese Daten natürlich für statistische Zwecke missbraucht werden können, sind sie doch für ein Applet unter Umständen lebensnotwendig: So kann es etwa einfach an der Versionsnummer ablesen, ob eine bestimmte Klasse mit Methoden bestimmter Versionen implementiert ist oder nicht (andernfalls muss die Implementierung dies über eine Exception testen).
1360
22.3
Sicherheitsmanager (Security Manager)
22.3.2 Sicherheitsmanager aktivieren Nehmen wir ein Programm SecTest an, das den aktuellen Sicherheitsmanager anzeigt und dann die Länge einer Datei ausgibt. Listing 22.1: com/tutego/security/SecTest.java package com.tutego.security; import java.io.File; public class SecTest { public static void main( String[] args ) { System.err.println( System.getSecurityManager() ); System.err.println( new File( "c:/address.txt" ).length() ); } }
Die Schalter -Djava.security.debug und -Djava.security.manager Wenn wir das Programm starten, läuft es durch und gibt die Länge der Datei aus. Mit dem Schalter -Djava.security.debug=all können Sicherheitsprüfungen geloggt werden, und wir bekommen Ausgaben wie diese: $ java -Djava.security.debug=all com.tutego.security.SecTest scl:
getPermissions ProtectionDomain (file:/S:/25_Sicherheitskonzepte/
)
22
sun.misc.Launcher$AppClassLoader@11b86e7
java.security.Permissions@1a46e30 ( (java.io.FilePermission \S:\25_Sicherheitskonzepte\- read) (java.lang.RuntimePermission exitVM) ) scl: null 42924
1361
22
Sicherheitskonzepte
Geben wir beim Start den Schalter -Djava.security.manager an, so meldet die Laufzeitumgebung einen Standard-Sicherheitsmanager an. Ein println(System.getSecurityManager()) liefert dann eine Ausgabe wie »java.lang.SecurityManager@26b249«. (Auch mit -Djava.security. manager=MeineSecManagerKlasse lässt sich arbeiten.) Soll eine potenziell kritische Operation wie das Erfragen der Dateilänge ausgeführt werden, steigt die Laufzeitumgebung mit einer Exception aus, weil der Sicherheitsmanager das standardmäßig nicht zulässt: $ java -Djava.security.manager com.tutego.security.SecTest java.lang.SecurityManager@26b249 Exception in thread "main" java.security.AccessControlException: access denied ( java.io.FilePermission c:\address.txt read) at java.security.AccessControlContext.checkPermission(AccessControlContext .java:270) at java.security.AccessController.checkPermission(AccessController.java:401) at java.lang.SecurityManager.checkPermission(SecurityManager.java:542) at java.lang.SecurityManager.checkRead(SecurityManager.java:887) at java.io.File.length(File.java:790) at SecTest.main(SecTest.java:9) Wie nutzen die Java-Bibliotheken den Sicherheitsmanager?
Ein Sicherheitsmanager hat die Kontrolle über alle problematischen (also potenziell gefährlichen) Methoden in der Java-Bibliothek. Alle Methoden, die irgendetwas mit Sicherheit zu schaffen haben, fragen vorher den Sicherheitsmanager, ob sie überhaupt zu der kritischen Aktion berechtigt sind. Sehen wir uns dazu die Methode list() aus der Klasse java.io.File an: public String[] list() { SecurityManager security = System.getSecurityManager(); if ( security != null ) security.checkRead( path ); return fs.list( this ); }
Wir erkennen, dass die Methode zunächst den Sicherheitsmanager konsultiert und dann erst die wahre Aktion ausführt. Betrachten wir das Beispiel, so ist dies typisch für alle anderen Methoden aus der File-Klasse und macht deutlich, dass es keine Möglichkeit gibt, um diesen Sicherheitsmanager herumzukommen; es sei denn, die Methode list() vom internen FileSystem-Objekt ließe sich direkt aufrufen – was aber nicht möglich ist, weil fs fest als privates
1362
22.3
Sicherheitsmanager (Security Manager)
statisches Attribut in der Klasse File verankert ist. Sogar Unterklassen können fs also weder sehen noch nutzen. So wie die File-Klasse mit dem SecurityManager arbeitet, rufen auch andere Klassen Prüfmethoden auf, um zu entscheiden, ob der Zugriff auf eine Ressource erlaubt ist. Verweigert der Sicherheitsmanager eine Operation, löst er eine SecurityException aus. Der Sicherheitsmanager kann zum Beispiel folgende Klassen beschränken: Þ Toolkit: Können wir mit getSystemEventQueue() die Systemschlange für Ereignisse abfragen? Þ Window: Erzeugt in einem Applet zusätzlich die Einblendung »Warning: Applet Window«. Þ FileInputStream: Dürfen wir ein solches Objekt überhaupt erzeugen? Þ Class: Dürfen wir auf Elemente der Klasse zugreifen? Þ ClassLoader: Können wir einen neuen Klassenlader definieren? Þ Runtime: Können wir mit exit() aussteigen oder externe Programme ausführen?
22.3.3
Rechte durch Policy-Dateien vergeben
Zwar könnte ein Programm einen eigenen Sicherheitsmanager vom Typ SecurityManager installieren, doch das ist in Java in der Regel nicht nötig. Es gibt bessere Möglichkeiten, Sicherheitseinstellungen vorzunehmen. Um einem Programm die passenden Rechte zu geben – und damit in unserem Fall Zugriff auf die Dateilänge zu bekommen –, werden die zugesicherten Rechte in einer Policy-Datei gesammelt. Bekommt die Laufzeitumgebung beim Start einen Verweis auf die Policy-Datei, wird der Security-Manager auf die vergebenen Berechtigungen Rücksicht nehmen. Bei der Vergabe von Rechten können zusätzlich angegeben werden: Þ Codebase: Vergibt Rechte für Klassen, die von einem bestimmten Ort kommen. Þ Signierung: Es wird nur das Recht eingeräumt, wenn Programmcode signiert ist. Þ Principal: Gewährt bestimmte Rechte für authentifizierte Benutzer.
22 Policy-Dateien mit grant-Anweisungen Die Policy-Dateien bestehen aus einer Reihe von grant-Anweisungen. Sehen wir uns die Datei myPol.policy an, die für alle Dateien eine Leseberechtigung vergibt: Listing 22.2: myPol.policy grant { permission java.io.FilePermission
"", "read";
};
1363
22
Sicherheitskonzepte
java.security.manager Nun muss diese Berechtigungsdatei mit dem Sicherheitsmanager verbunden werden. Das geschieht am komfortabelsten von der Kommandozeile aus: $ java -Djava.security.manager -Djava.security.policy=myPol.policy com.tutego.security.SecTest java.lang.SecurityManager@26b249 28
Wir sehen, dass das Programm nun durchläuft und die Dateilänge ausgibt. Der Schalter -Djava.security.policy gibt einen Pfad auf die Berechtigungsdatei an. Die Datei muss im Pfad gefunden oder absolut adressiert werden.
Standard-Policy-Dateien Neben diesen benutzerdefinierten Rechteregeln gibt es vom System vergebene PolicyDateien. Sie werden von Java standardmäßig in der Datei java.policy im Unterverzeichnis lib/security (etwa C:\Program Files\Java\jre7\lib\security, aber auch C:\Program Files\Java\ jdk1.7.0\jre\lib\security) der Java-Installation gespeichert. Diese Rechtedatei definiert damit die »Standardberechtigungen«. Listing 22.3: C:\Program Files\Java\jre7\lib\security\java.policy, Ausschnitt // Standard extensions get all permissions by default grant codeBase "file:${{java.ext.dirs}}/*" { permission java.security.AllPermission; };
Alle Bibliotheken, die in das ext-Verzeichnis gelegt werden, bekommen alle Rechte. Das liegt an den Systemrechten. Das zeigt auch die Verwendung einer Code-Base: Sie spezifiziert den genauen Pfad, in dem die Rechte gelten. Also werden nur für das lib/ext-Verzeichnis alle Rechte vergeben, aber nicht für alle anderen. (Das ext-Verzeichnis ist nicht direkt angegeben, sondern über eine Variable. In älteren Java-Versionen wurde es als "file:${java.home}/lib/ ext/*" geschrieben.) Eigene, systemunabhängige Rechtedateien können wir unter dem Namen java.policy im Benutzerverzeichnis ablegen. Auch diese Dateien kann der Systemverwalter anpassen. Zunächst werden die Standardsicherheitsdateien genutzt und die Benutzerdateien »nachgeladen«. Eine weitere Datei java.security im Verzeichnis security der JRE und des JDK beschreibt, welche Rechtedateien genutzt werden. Genau dort befinden sich die beiden Dateien.
1364
22.3
Sicherheitsmanager (Security Manager)
Listing 22.4: C:\Program Files\Java\jre7\lib\security\java.security, Ausschnitt # The default is to have a single system-wide policy file, # and a policy file in the user’s home directory. policy.url.1=file:${java.home}/lib/security/java.policy policy.url.2=file:${user.home}/.java.policy
Die Datei ist ebenso wichtig, wenn neue Provider, also Implementierungen der KryptografieAPI, angemeldet werden. Da Rechte nur vergeben, aber bisher nicht genommen werden können, besteht das Sicherheitsproblem darin, dass eine eigene Policy-Datei alle Rechte vergibt, wogegen die Systemdatei Einschränkungen vorsieht. In diesem Fall kann der Programmverwalter auch dem Benutzer das Recht nehmen, eigene Rechtedateien anlegen zu können. Dazu editiert er die Datei java.security. Der Eintrag allowSystemProperty muss false sein. Standardmäßig ist er true, wie der Ausschnitt zeigt: Listing 22.5: C:\Program Files\Java\jre7\lib\security\java.security, Ausschnitt # whether or not we allow an extra policy to be passed on the command line # with -Djava.security.policy=somefile. Comment out this line to disable # this feature. policy.allowSystemProperty=true
22.3.4 Erstellen von Rechtedateien mit dem grafischen Policy-Tool Das grafische Dienstprogramm policytool gibt uns die Möglichkeit, Applikationen und signierten Applets spezielle Rechte einzuräumen oder zu verweigern. Das Policy-Tool nimmt uns die Arbeit ab, die Rechtedateien von Hand zu editieren. Nach dem Aufruf des Programms policytool öffnet sich ein Fenster, das uns einige Menüpunkte bereitstellt, über die wir bestehende Rechtedateien editieren oder auch neue anlegen können.
Abbildung 22.2: Das grafische Policy-Tool
1365
22
22
Sicherheitskonzepte
Neue Einträge für die Zugeständnisse der Laufzeitumgebung an das Programm werden über das Menü Add Policy Entry vorgenommen. Über das Dialogfenster können wir anschließend eine Reihe von erlaubten Eigenschaften sowie Permissions auswählen. Die folgende Tabelle zeigt einige Permissions und ihre Bedeutungen: Permission
Bedeutung
AllPermission
Die Anwendung oder das Applet darf alles.
FilePermission
Zugriff auf Dateien und Verzeichnisse
NetPermission
Zugriff auf Netzwerkressourcen
PropertyPermission
Zugriff auf Systemeigenschaften
ReflectPermission
Zugriff über Reflection auf andere Objekte erlauben
RuntimePermission
Einschränkungen von Laufzeitsystemen wie Klassenlader
SecurityPermission
Einstellen eines allgemeinen Sicherheitskonzepts, etwa für den Zugriff auf Policies
SerializablePermission
Beschränkung der Serialisierung
SocketPermission
Spezielle Einschränkungen an einer Socket-Verbindung
Tabelle 22.1: Auswahl einiger Permissions
22.3.5
Kritik an den Policies
Die Policies sind eine nette Sache, um für eine Applikation die Rechte einzuschränken oder zu vergeben, doch sie sind nicht unproblematisch.
Format der Policy-Dateien Policy-Dateien sind standardmäßig Textdateien auf der Clientseite des Anwenders. Ein Anwender kann diese Textdateien ohne große Probleme ändern und mehr Rechte zugestehen. Die Rechtedateien sind durch keine Prüfsumme gesichert, um Änderungen gegebenenfalls zu erkennen. Zum anderen ist das Textformat nicht mehr so »modern«, und XML-basierte Textformate lösen proprietäre Dateiformate immer mehr ab. Da sich das Sicherheitssystem von Java jedoch beliebig erweitern lässt, lassen sich die Standardtextformate durch ein neues System ersetzen, das etwa XML-Dateien liest und eine (mit einer digitalen Signatur gesicherte) Prüfsumme speichert, die nicht mehr so leicht veränderbar ist.
1366
22.3
Sicherheitsmanager (Security Manager)
Kein Refresh Wurden Policy-Dateien einmal vom System eingelesen, können sie zwar nachträglich verändert werden, doch das Java-System erkennt diese Änderung nicht. Als Konsequenz muss die Applikation neu gestartet werden. Das ist für Benutzerapplikationen kein großes Dilemma, doch für serverseitige Applikationen ein großes Problem. Es ist unmöglich, für eine kleine Änderung an den Policy-Dateien etwa den EJB-Server herunterzufahren und wieder neu zu starten. Angenommen, das System ist ein Five-Nine-System, weist also eine Verfügbarkeit von 99,999 % auf, so würde dies eine erlaubte Ausfallzeit von etwa fünf Minuten ausmachen – was bei laufender Änderung der Policies kaum zu erreichen ist.
Keine Rollen bei der Rechtevergabe Der Zweck des Policy-Verfahrens besteht darin, einem Programm Rechte zuzuordnen. Die Rechte können weiterhin für Programme vergeben werden, die von einem bestimmten Ort kommen (CodeSource) und von einem bestimmten Anwender signiert sind (SignedBy). Was wäre, wenn wir einem bestimmten Benutzer Rechte zuordnen wollten? Das ist nicht so einfach möglich. Jeder Benutzer müsste dann das Jar-Archiv signieren, und der Policy-Datei wäre zu entnehmen, was jedem Benutzer zustünde. Doch das taugt nichts! Käme ein Benutzer hinzu, müsste das Archiv neu signiert werden – bei 10.000 Benutzern ein undenkbares Unterfangen. Des Weiteren könnte der Benutzer selbst seine Rechte erweitern, was nicht sinnvoll wäre. Wir brauchen also nicht nur ein Verfahren, das nach den Quellen, sondern auch nach Rollen unterscheidet. Dieses Verfahren heißt rollenbasierte Rechtevergabe. Jedem Benutzer ist eine Rolle zugeordnet, und anhand dieser Rolle werden ihm Rechte zugewiesen. Das Betriebssystem Windows nutzt zum Beispiel diesen Typ der Rechtevergabe.
JAAS (Java Authentication and Authorization Service) Für ein rollenbasiertes Sicherheitssystem gibt es JAAS (Java Authentication and Authorization Service). Es ist Bestandteil seit Java 1.4. Die beiden Hauptteile sind: Þ Authentifikation/Authentifizierung. Gibt die Identität einer Person oder eines Programms
gegenüber einem Kommunikationspartner an. Þ Autorisierung. Sicherstellen der Rechte, sodass ein Benutzer Aktionen durchführen kann
beziehungsweise ihm Aktionen verwehrt bleiben. Das JAAS ist damit eine Java-Version eines Pluggable Authentication Module (PAM). Wichtig in diesem Zusammenhang sind Login-Module. Sie erlauben die Anmeldung an eine Instanz, sodass sich der Benutzer authentifizieren kann. Dies kann ein komplexes System wie
1367
22
22
Sicherheitskonzepte
Kerberos sein, aber auch eine Smart-Card oder ein biometrisches System. Einige Login-Module liefert das JDK mit jeder Laufzeitumgebung mit aus. Hat sich der Benutzer (das Subject) mit dem Login-Modul authentifiziert, verbindet JAAS ihn mit authentifizierten Benutzerkennungen, die Principal heißen. Bei den Policy-Dateien haben wir nun gesehen, wie die Rechte auch für eine Codebase, einen Signierer und auch einen Principal vergeben werden können. Der Sicherheitsmanager ermöglicht also einem Programmstück nur dann die Ausführung, wenn ein Benutzer angemeldet ist und die nötigen Rechte hat. Der Programmcode muss also keine Implementierung mit Fallunterscheidungen für diverse Rollen aufweisen, sondern kann einfach in der Policy-Datei mit einem Principal assoziiert werden.
22.4 Signierung Wir wollen uns in diesem Kapitel mit einigen Werkzeugen beschäftigen, die zur Signierung von Java-Archiven vom JDK angeboten werden. Zum Signieren von Applikationen sowie von Applets und zur Vergabe der Zugriffsrechte und -beschränkungen stellt Oracle die Dienstprogramme keytool, jarsigner und policytool bereit.
22.4.1
Warum signieren?
Die Sandbox einer Java VM ist sinnvoll, damit Amok laufende Applikationen keine ernsthaften Schäden anrichten können. Es gibt aber genauso gut Szenarien, in denen es nützlich ist, Applets mehr Freiräume einzuräumen. Gründe können sein: Eingebundene native Bibliotheken sollen eine Authentifizierung über das Ohrläppchen eines Anwenders vornehmen oder auf die Festplatten zum Caching zurückgreifen können.
22.4.2 Digitale Ausweise und die Zertifizierungsstelle Wenn nun das Java-Programm diesen Zugriff eigentlich nicht machen darf, aber möchte, was ist die Lösung? Die Antwort ist, Programme mit einem Autor zu verbinden und die Programme dann auszuführen, wenn wir dem Autor vertrauen. Zentral bei diesem Spiel ist die sichere Identifizierung des Autors. Das übernimmt eine Zertifizierungsstelle (Certificate Authority, CA), die digitale Signaturen ausstellt, um eine Person oder Organisation zu identifizieren. Ein Programmstück wird dann mit einer Signatur verbunden, sodass immer der Autor bekannt ist, wenn kritische Programmstellen Unheil anrichten und ich dem Autor so richtig meine Meinung sagen möchte.
1368
22.4
Signierung
Die Zertifizierungsstelle ist ein kleiner Schwachpunkt in diesem Szenario, denn erst einmal hindert uns keiner daran, selbst die Zertifizierungsstelle zu spielen und das Zertifikat auf Mickey Mouse auszustellen – das machen wir auch gleich. Dem Anwender obliegt die Verantwortung, nur Zertifikate von wirklich autorisierten Stellen anzunehmen. Die Bundesnetzagentur akkreditiert Zertifizierungsstellen. Hier gibt es einige bekannte CAs wie VeriSign, CAcert oder Thawte, weitere sind unter http://www.pki-page.org/ vermerkt. Das Zertifikat selbst verbindet die Person mit einem kryptografischen Schlüssel und weiteren Informationen wie Seriennummer, Aussteller und Lebensdauer. Dem Schlüssel kommt die größte Bedeutung zu, denn damit wird das Java-Archiv signiert. Der wichtigste Standard für Zertifikate ist der ITU-T-Standard X.509. Die Zertifikate sind in ASN.1 (Abstract Syntax Notation One) kodiert.
22.4.3 Mit keytool Schlüssel erzeugen Das Programm keytool erzeugt öffentliche und private Schlüssel und legt sie in einer passwortgeschützten und verschlüsselten Datei ab. Die Datei hat standardmäßig den Namen .keystore und befindet sich im Benutzerverzeichnis des Anwenders. Mit dem Programm keytool lassen sich neben der Schlüsselgenerierung auch Zertifikate importieren, Zertifikatsanforderungen ausstellen und Schlüssel als vertrauenswürdig festlegen. Möchten wir einen Schlüssel erstellen, rufen wir das Programm keytool mit der Option -genkey auf. Daneben gibt die Option -alias einen Namen für den Schlüsselinhaber an. Nehmen wir an, dass das JDK-Programm keytool (zum Beispiel im Verzeichnis C:\Program Files\Java \jdk1.7.0\bin) im Suchpfad eingebunden ist. $ keytool -genkey -alias CUllenboom
Anschließend fragt keytool nach dem Passwort des Schlüsselspeichers und erfragt weitere Angaben zum Inhaber. Mit diesen Informationen erzeugt das Programm ein Schlüsselpaar mit einem selbstzertifizierenden Zertifikat. Bei diesem speziellen Zertifikat sind Aussteller und Inhaber identisch. Option
Bedeutung
-genkey
Erzeugung eines Schlüsselpaars
-import
Importieren eines Zertifikats
-selfcert
Erstellung eines selbstinitiierten Zertifikats
-certreq
Export einer Zertifikatsanforderung; sie kann als Datei an eine CA geschickt werden.
Tabelle 22.2: Optionen von »keytool«
1369
22
22
Sicherheitskonzepte
Option
Bedeutung
-export
Export eines Zertifikats. Dieses kann dann von einem anderen Benutzer importiert und als vertrauenswürdig deklariert werden.
-list
Listet alle Zertifikate und Schlüssel auf.
-delete
Entfernt ein Schlüsselpaar.
-help
Zeigt eine kurze Hilfe an.
Tabelle 22.2: Optionen von »keytool« (Forts.)
Die Angabe der Optionen ist immer dann sinnvoll, wenn die Standardeinstellungen unpassend sind. Über die Optionen lassen sich die Algorithmen zur Verschlüsselung und Schlüsselgenerierung ebenso angeben wie eine Pfadangabe des Schlüsselspeichers oder die Gültigkeitsdauer.
22.4.4 Signieren mit jarsigner Das Dienstprogramm jarsigner signiert und verifiziert Jar-Archive. Dazu erstellt jarsigner zunächst einen Hashcode des Archivs und verschlüsselt ihn anschließend mit dem privaten Schlüssel des Nutzers. Das Zertifikat und der öffentliche Schlüssel werden dem Archiv beigelegt.
Beispiel Signiere das Archiv archiv.jar mit dem Schlüsselspeicher (Keystore) von CUllenboom. $ jarsigner archiv.jar CUllenboom
Die Anwendung mit jarsigner fügt dem Archiv zwei weitere Dateien hinzu: eine SignaturDatei mit der Endung .sf und eine Signaturblock-Datei mit der Endung .dsa. Die SignaturDatei enthält eine Liste aller Dateien im Archiv und speichert zudem den Hash-Wert zu einer mit aufgeführten Hash-Funktion. Diese Signatur-Datei wird dann mit dem privaten Schlüssel des Signierers signiert und zusammen mit dem verschlüsselten Zertifikat des Signierers in der Signaturblock-Datei gespeichert.
Beispiel Wir möchten wissen, ob ein Archiv verifiziert ist: $ jarsigner -verify archiv.jar
1370
22.5
22.5
Digitale Unterschriften *
Digitale Unterschriften *
Ein Message-Digest, kurz MD, definiert ein Verfahren zur Erzeugung digitaler Unterschriften für Dokumente. Der berechnende Algorithmus ist eine Einwegfunktion und liefert aus einer Botschaft beliebiger Länge einen »Fingerabdruck« in Form einer Zahl. Die Fingerabdrücke dienen dazu, veränderte Botschaften zu bemerken. Hängen wir einer Rechnung etwa eine 0 an, soll dies nicht unbemerkt bleiben. Wir haben ähnliche Funktionen schon beim Hash-Verfahren kennengelernt. Die meisten Klassen überschreiben die Methode hashCode() der Oberklasse Object, um einen int (also 32 Bit) als Identifizierer zu liefern. Für die Begriffe Message-Digest und Fingerabdruck gibt es weitere Synonyme: Kompressionsfunktion, Kontraktionsfunktion, kryptografische Prüfsumme (falls die Unterschrift zusätzlich verschlüsselt ist), Integritätsprüfung von Nachrichten (Message Integrity Check, MIC) oder Erkennung von Manipulationen (Manipulation Detection Code, MDC). Ist dem Fingerabdruck ein Schlüssel beigefügt, fällt auch der Begriff Message Authentication Code (MAC).
22.5.1
Die MDx-Reihe
Die Firma RSA1 Data Security entwickelte mit der Reihe MD2, MD4 und MD5 drei Verfahren zur Berechnung kryptografischer Prüfsummen. MD5 produziert 128-Bit-Hash-Werte; das ist eine 32-stellige Hexadezimalzahl. Während bei MD2 (1989) und MD4 (1990) sich relativ schnell Schwächen zeigten, dauerte es beim MD5-Verfahren (1991) mehr als 10 Jahre, bis im August 2004 von der Arbeitsgruppe um Xiaoyun Wang Methoden zur Kollision und von Patrick Stach2 ein Kollisionsgenerator entwickelt wurden. Wir haben uns schon beim Hashing in Kapitel 3 mit Kollisionen beschäftigt. Da ein MD5-Hash-Wert 128 Bit lang ist, kann er 2^128 verschiedene Ausgabewerte annehmen. Zwangsläufig sind unter 2^128 + 1 verschiedenen Nachrichten mindestens zwei Texte mit gleichem Hash-Wert. Die Wahrscheinlichkeit, dass eine beliebige Nachricht den gleichen Hash-Wert wie eine vorgegebene Nachricht hat, liegt bei 0,000 000 000 000 000 000 000 000 000 000 000 000 029 % (1/2^128). (Die Wahrscheinlichkeit, dass zwei beliebig gewählte unterschiedliche Nachrichten den gleichen HashWert haben, ist jedoch deutlich höher. Dieses Phänomen heißt Geburtstagsparadoxon.) Die chinesische Arbeitsgruppe führte einen erfolgreichen Kollisionsangriff vor und generierte zwei Dokumente mit dem gleichen MD5-Hash. Am 1. März 2005 konnten zwei X.509Zertifikate erstellt werden, die den gleichen MD5-Hash besaßen, aber unterschiedliche öffentliche Schlüssel. Dabei hat die Forschergruppe lediglich Kommentarfelder mit unterschiedli-
1
Programmiert wurde es von Ron Rivest, einem der Mitentwickler des RSA-Public-Key-Verfahrens. Daher auch das »R«. Die Kollegen waren Adi Shamir und Leonard Adleman.
2
http://www.stachliu.com/collisions.html
1371
22
22
Sicherheitskonzepte
chen Werten belegt. Dabei ist ein Kollisionsangriff der einfachere Fall, denn hier müssen lediglich zwei verschiedene Nachrichten mit gleichem MD5-Hash gefunden werden. Spannender ist ein Preimage-Angriff, bei dem zu einem gegebenen Hash-Wert (etwa von einem X.509-Zertifikat) ein neues Dokument (also wieder ein X.509-Zertifikat) mit gleichem MD5-Hash-Wert erzeugt wird. Doch ein Preimage-Angriff ist für X.509-Zertifikate bisher nicht bekannt, und daher geht von MD5 im Moment auch keine echte Gefahr für digitale Signaturen aus.
22.5.2
Secure Hash Algorithm (SHA)
Das National Institute of Standards and Technology (http://www.nist.gov) entwickelte im Secure Hash Standard (SHS) den Secure Hash Algorithm (SHA)3 mit einem Hash-Wert von 160 Bit. Der Secure-Hash-Standard ist Teil des Digital-Signature-Standards (DSS), und dieser wiederum ist Teil des Capstone-Projekts. Dieses Projekt definiert Standards für öffentlich verfügbare Kryptografie. Es besteht aus vier Hauptkomponenten. Dazu gehören ein symmetrischer Verschlüsselungsalgorithmus (Skipjack, auch Clipper genannt), ein Schlüsselaustauschprotokoll (bisher nicht öffentlich, ein Diffie-Hellman-Verfahren), ein Hash-Algorithmus (SHA) und ein Algorithmus für die digitale Unterschrift (DSA, die SHA benutzt). Die Auswahl der Algorithmen treffen das NIST und die NSA. Die erste Version von SHA hatte eine undokumentierte Schwachstelle, die in einer neuen Implementierung, SHA-1, nicht mehr vorhanden ist. Wir nennen SHA-1 im Folgenden einfach SHA und beziehen uns damit auf die neueste Version. Im Vergleich zu MD5 generiert SHA einen Hash-Wert von 160 Bit, was Brute-Force-Angriffe erschwert. Die Analysen von Xiaoyun Wang, Yiqun Lisa Yin und Hongbo Yu zeigten jedoch auch Schwächen von SHA-1 auf. Das Team konnte die Anzahl der Kollisionsberechnungen von Brute-Force-Angriffen von 2^80 auf 2^69 und später auf 2^63 senken – Security-Guru Bruce Schneier vermeldet auf seiner Webseite4, dass SHA-1 damit mehr oder weniger geknackt sei.
22.5.3
Mit der Security-API einen Fingerabdruck berechnen
Der Einstiegspunkt für Fingerabdrücke ist eine statische Methode, MessageDigest.getInstance(), die ein Exemplar eines konkreten kryptografischen Algorithmus liefert. Das Argu-
ment ist ein Name für den Algorithmus, etwa MD5 oder SHA. Das JDK implementiert den 3
Eine Beschreibung des Algorithmus ist unter http://www.itl.nist.gov/fipspubs/fip180-1.htm abgelegt. FIPS ist die Abkürzung für Federal Information Processing Standards Publication – ich glaube nicht, dass es eine Verwandtschaft mit Heinz Erhardts Fips gibt.
4
http://www.schneier.com/blog/archives/2005/08/new_cryptanalyt.html und http://www.schneier.com/blog/ archives/2005/02/sha1_broken.html
1372
22.5
Digitale Unterschriften *
DSA-Algorithmus NIST Digital Signature Algorithm und für digitale Signaturen SHA-1 und MD5. Da wir uns etwas näher mit Signaturen beschäftigt haben, wollen wir zunächst die Klasse MessageDigest für digitale Fingerabdrücke untersuchen.
22.5.4 Die Klasse MessageDigest Mit der statischen Methode getInstance() bekommen wir einen Algorithmus, der eine bestimmte Berechnungsfunktion implementiert. getInstance() gibt es in zwei Varianten. Beiden gemeinsam ist der Name des Algorithmus im übergebenen Argument. Die folgende Anweisung erzeugt ein MessageDigest-Objekt für SHA: MessageDigest digest = MessageDigest.getInstance( "SHA" );
Eine zweite Variante spezifiziert den Hersteller näher: MessageDigest digest = MessageDigest.getInstance( "SHA", "SUN" );
Ist der Algorithmus nicht bekannt, bekommen wir eine NoSuchAlgorithmException. Ein unbekannter Hersteller führt zu einer NoSuchProviderException.
22
Abbildung 22.3: UML-Diagramm der Klasse MessageDigest
Den Fingerabdruck berechnen Nun können wir eine Nachricht kodieren. Dafür gibt es zwei Möglichkeiten: Die Nachricht wird als Ganzes übergeben, oder sie wird Schritt für Schritt kodiert. Die Funktionsweise erinnert sehr an die Schnittstelle java.util.zip.Checksum.
1373
22
Sicherheitskonzepte
Beispiel Die folgenden Zeilen berechnen den Hash-Wert für eine Zeichenkette: MessageDigest md = MessageDigest.getInstance( "SHA" ); md.update( "Hello".getBytes() );
Die update()-Methode ist auch für ein einzelnes Byte deklariert. Für große Dateien ist es besser, immer wieder update() auf größeren Blöcken aufzurufen, anstatt die ganze Datei auf einmal zu übergeben, da dafür die Datei vollständig im Speicher stehen müsste. Schritt für Schritt nehmen wir mit update() immer mehr von der Nachricht hinzu. Ein Beispiel: Berechne den Hash-Wert für alle Daten eines Eingabestroms: Listing 22.6: com/tutego/security/digest/MessageDigestDemo.java, messageDigest() static byte[] messageDigest( InputStream in, String algo ) throws Exception { MessageDigest messageDigest = MessageDigest.getInstance( algo ); byte[] md = new byte[ 8192 ]; for ( int n = 0; (n = in.read( md )) > –1; ) messageDigest.update( md, 0, n ); return messageDigest.digest(); }
Den Fingerabdruck auslesen Nach dem Sammeln berechnet die Methode digest() die Signatur. Sie hat eine bestimmte Länge in Byte, die wir mit getDigestLength() erfragen können. Da digest() ein Byte-Array zurückliefert, ist der Wert von getDigestLength() mit der Länge des Arrays identisch. digest() lässt sich auch mit einem Byte-Feld aufrufen. Ein einfaches SHA-Programm für den String sieht daher so aus: Listing 22.7: com/tutego/security/digest/SHATest.java, Ausschnitt MessageDigest md = MessageDigest.getInstance( "SHA" ); byte[] digest = md.digest( "abd".getBytes() ); for ( byte b : digest ) System.out.printf( "%02x", b );
Das Programm erzeugt die Ausgabe:
1374
22.6
Verschlüsseln von Daten(-strömen) *
a9 99 3e 36 47 6 81 6a ba 3e 25 71 78 50 c2 6c 9c d0 d8 9d
Schon eine einfache Veränderung wirkt sich global aus. Statt »abc« kodieren wir jetzt »Abc« und »abd«. Einmal ändert sich der Kleinbuchstabe in einen Großbuchstaben, und im anderen Fall nehmen wir einfach das nachfolgende Zeichen im Alphabet. Kein Byte bleibt gleich: 91 58 58 af a2 27 8f 25 52 7f 19 20 38 10 83 46 16 4b 47 f2
// Abc
cb 4c c2 8d f0 fd be 0e cf 9d 96 62 e2 94 b1 18 9e 2a 57 35
// abd
22.6 Verschlüsseln von Daten(-strömen) * Kryptografie unterscheidet zwischen asymmetrischer und symmetrischer Verschlüsselung. Ist die Kommunikation asymmetrisch, sind zwei Schlüssel nötig: ein öffentlicher und ein privater. Bei der symmetrischen Verschlüsselung ist nur ein Schlüssel erforderlich, der bei der Ver- und Entschlüsselung gleich ist. Bekanntester Vertreter der symmetrischen Verschlüsselung ist DES (Data Encryption Standard), der allerdings wegen seiner geringen Schlüssellänge nicht mehr aktuell ist. DES wurde 1981 in den USA als ANSI-Standard normiert. Bei den asymmetrischen Verfahren ist die RSA-Verschlüsselung die bekannteste. Ihre Sicherheit basiert auf dem mathematischen Problem, für eine große Ganzzahl eine Primfaktorzerlegung zu finden. Asymmetrische Verschlüsselung ist im Vergleich zu symmetrischen Verschlüsselungen langsam.
22.6.1
Den Schlüssel, bitte
Jeder Schlüssel, sei er privat oder öffentlich, implementiert die Basisschnittstelle java.security.Key. Von dieser Schnittstelle gibt es Unterschnittstellen, etwa PublicKey, PrivateKey für die asymmetrischen Schlüssel oder SecretKey für den symmetrischen Schlüssel. Von diesen Schnittstellen existieren weitere Unterschnittstellen.
Abbildung 22.4: UML-Diagramm der Klasse Key
1375
22
22
Sicherheitskonzepte
Schlüssel aus der Fabrik Um Schlüssel zu erzeugen, gibt es zwei Fabriken: KeyGenerator erzeugt symmetrische Schlüssel und KeyPairGenerator asymmetrische. Der Fabrikmethode getInstance() ist dabei eine Kennung zu übergeben, die für den Algorithmus steht. Listing 22.8: com/tutego/security/crypto/KeyGeneratorDemo.java, main() KeyGenerator kg = KeyGenerator.getInstance( "DES" ); KeyPairGenerator kpg = KeyPairGenerator.getInstance( "RSA" );
Der nächste Schritt sieht eine Initialisierung des Schlüssels mit zufälligen Werten vor. Ohne Initialisierung kann jeder Provider unterschiedlich verfahren. kg.init( 56 );
// nicht größer als 56!
kpg.initialize( 1024 );
Nicht besonders schlau ist, dass einmal die Methode init() heißt und dann einmal initialize(). Beiden Methoden lässt sich noch ein Zufallszahlengenerator mitgeben, doch intern ist das SecureRandom schon sehr gut. Kryptografische Angaben kann ein Objekt vom Typ AlgorithmParameterSpec einführen. Der letzte Schritt besteht im Erfragen der Schlüssel: SecretKey secKey = kg.generateKey(); KeyPair
keyPair = kpg.genKeyPair();
Bei einer Ausgabe des symmetrischen Schlüssels über System.out.println() kommt nicht viel Sinnvolles heraus, doch bei den privaten und öffentlichen Schlüsseln, die keyPair mit getPublic() und getPrivate() offenlegt, implementieren PublicKey und PrivateKey eine ansehnliche toString()-Methode. System.out.println( keyPair.getPublic() );
Liefert: SunJSSE RSA public key: public exponent: 010001 modulus: a8186ac3 03b9417e c0247c70 d225ae75 04d2fa3b 9b21e009 ca32a1f3 3cc7404f aeb6df52 0aa4d9ab ae35a5d5 d7b30f38 ce670895 3234fab2 c67f1211 b9dab8d2 edda3a7b 710fbf86 0274a2a6 842c4d73 76fc2166 80ef1e82 36a949f9 8180c5c7 004cffdd c103b42b 9abf216d 5f797440 20b8ec52 afe44407 a871e1f7 0e27fec9
1376
22.6
Verschlüsseln von Daten(-strömen) *
System.out.println(keyPair.getPrivate()) liefert eine noch längere Ausgabe mit Exponent,
Modulo usw.
SecretKeySpec Schlüssel für die symmetrische Verschlüsselung sind nichts anderes als Binärfelder. Die Klasse javax.crypto.spec.SecretKeySpec dient zum Erzeugen eines symmetrischen Schlüssels und erwartet im Konstruktor das Byte-Feld und den Algorithmus. Key k = new SecretKeySpec( "01234567".getBytes(), "DES" );
Für andere Typen existieren wiederum andere Klassen. Zum Beispiel erzeugt DSAPrivateKeySpec einen privaten Schlüssel aus einem anderen Schlüssel, zwei Primzahlen und einer Basis,
die als BigInteger-Objekte angegeben sind.
22.6.2 Verschlüsseln mit Cipher Die Klasse javax.crypto.Cipher bildet das Zentrum der JCE. Nachdem init() das Objekt mit einem Modus und Schlüssel initialisiert hat, lassen sich mit update(byte[]) Daten durchschleusen. doFinal() rundet das Ganze dann ab. Die Rückgabe ist immer ein verschlüsselter Block von byte. Cipher cipher = Cipher.getInstance( "DES" ); cipher.init( Cipher.ENCRYPT_MODE, key ); byte[] verschlüsselt = cipher.doFinal( unverschlüsselt );
Beim Entschlüsseln wird der Cipher einfach in den Modus Cipher.DECRYPT_MODE gesetzt.
22.6.3 Verschlüsseln von Datenströmen
22
Zum Verschlüsseln von Datenströmen bietet die Java-Bibliothek die praktischen Klassen javax.crypto.CipherInputStream und CipherOutputStream an. Sie erwarten ein Cipher-Objekt, das eine DES-Verschlüsselung durchführt. Listing 22.9: com/tutego/security/crypto/ReadWriteDES.java package com.tutego.security.crypto; import java.io.*; import java.security.Key; import javax.crypto.*;
1377
22
Sicherheitskonzepte
import javax.crypto.spec.SecretKeySpec; import sun.misc.*; public class ReadWriteDES { static void encode( byte[] bytes, OutputStream out, String pass ) throws Exception { Cipher c = Cipher.getInstance( "DES" ); Key k = new SecretKeySpec( pass.getBytes(), "DES" ); c.init( Cipher.ENCRYPT_MODE, k ); OutputStream cos = new CipherOutputStream( out, c ); cos.write( bytes ); cos.close(); } static byte[] decode( InputStream is, String pass ) throws Exception { Cipher c = Cipher.getInstance( "DES" ); Key k = new SecretKeySpec( pass.getBytes(), "DES" ); c.init( Cipher.DECRYPT_MODE, k ); ByteArrayOutputStream bos = new ByteArrayOutputStream(); CipherInputStream cis = new CipherInputStream( is, c ); for ( int b; (b = cis.read()) != –1; ) bos.write( b ); cis.close(); return bos.toByteArray(); } public static void main( String[] args ) throws Exception { ByteArrayOutputStream out = new ByteArrayOutputStream(); encode( "Das wird anders werden".getBytes(), out, "01234567" );
1378
22.7
Zum Weiterlesen
String s = new BASE64Encoder().encode( out.toByteArray() ); System.out.println( s ); // qJYN+8Hd5dXsgMl1akQnw4iCbRN3EUbK byte[] decode = new BASE64Decoder().decodeBuffer( s ); InputStream is = new ByteArrayInputStream( decode ); System.out.println( new String( decode( is, "01234567" ) ) ); } }
22.7
Zum Weiterlesen
Da jeder etwas anderes unter Sicherheit versteht, sind auch die Möglichkeiten zum Weiterlesen nahezu unbeschränkt. Die Verifizierung ist sehr trickreich, und insbesondere ein finallyBlock verlangt einiges an Aufmerksamkeit. Der Abschnitt 4.9 der »Java Language Specification« beschreibt die Validierung genauer. Auf die Probleme geht der Artikel »The Problem of Bytecode Verification in Current Implementations of the JVM« (http://citeseer.ist.psu.edu/ 484520.html) etwas genauer ein. Das Zusammengreifen der einzelnen Elemente wie Klassenlader, Verifier, Sicherheitsmanager ist gut im Online-Kapitel von »Inside the Java Virtual Machine« (http://www.artima.com/insidejvm/ed2/security.html) nachzulesen.
22
1379
Kapitel 23 Dienstprogramme für die Java-Umgebung »Die glücklichen Sklaven sind die erbittertsten Feinde der Freiheit.« – Marie von Ebner-Eschenbach (1830–1916)
23.1
Programme des JDK
Während das JRE nur eine Laufzeitumgebung enthält, besteht eine JDK-Installation aus dem JRE plus einer größeren Zahl Tools im bin-Ordner. Während beim JDK 1.0 im Wesentlichen nur der Compiler und die Laufzeitumgebung Teil des Pakets waren, erhöhte sich die Anzahl der Werkzeuge auf etwa 50. Mit den Werkzeugen lassen sich zum Beispiel die gestarteten Java-Programme auflisten oder lässt sich ein kleiner CORBA-Namensdienst-Server starten. Wie andere Dienstprogramme auch, dokumentiert Oracle die Programme unter http://tutego.de/go/jdktools.
23.2 Monitoringprogramme vom JDK Java ist eine beliebte Technologie auf der Serverseite, und da ist das Überwachen einer JVM sehr wichtig.
23.2.1
23
jps
Das Programm jps ist das Java Virtual Machine Process Status Tool und liefert alle laufenden Java-Programme mit einem lokalen VM-Identifizierer. c:\Program Files\Java\jdk1.7.0\bin>jps -mlvV 11372 -Xms40m -Xmx384m -XX:MaxPermSize=256m 12876 sun.tools.jps.Jps -mlvV -Dapplication.home=c:\Program Files\Java\jdk1.7.0 -Xms8m
1381
23
Dienstprogramme für die Java-Umgebung
Die Optionen sind: Þ
-l listet den Paketnamen der Klasse mit dem main() auf.
Þ -m zeigt die an die main()-Methode übergebenen Argumente an. Þ –v und –V zeigen die an die JVM übergebenen Parameter an.
Mehr Details gibt es unter http://download.oracle.com/javase/7/docs/technotes/tools/share/ jps.html. Unter Java 6 zeigt jps bei Eclipse noch »org.eclipse.equinox.launcher_....jar« an, bei Java 7 ist die Ausgabe leider leer. jps selbst ist auch in der Liste. In dieser Sitzung ist die ID von Eclipse 11372. Die folgenden Beispiele nutzen die Eclipse-ID für zusätzliche Anfragen.
23.2.2 jstat Mit jstat, dem Java Virtual Machine Statistics Monitoring Tool, ist es möglich, PerformanceStatistiken zu erfragen: c:\Program Files\Java\jdk1.7.0\bin>jstat -gcutil 11372 S0
S1
E
0,00
0,00
0,41
O
P
46,19
YGC
99,43
42
YGCT 0,575
FGC 278
FGCT
GCT
56,867
57,442
Die Ausgaben zeigen zum Beispiel mit FGC die Anzahl der GC-Ereignisse an. Die ID 11372 erfahren wir vom Tool jps. Die Seite http://download.oracle.com/javase/7/docs/technotes/tools/ share/jstat.html schlüsselt die Abkürzungen auf.
23.2.3
jmap
Das Memory-Map-Tool namens jmap zeigt eine Liste mit der Anzahl der Exemplare von JavaObjekten und zeigt auch, wie viel Hauptspeicher sie verbrauchen. Für Eclipse ist die Anzahl der Objekte sehr groß, sodass die Ausgabe hier gekürzt ist: c:\Program Files\Java\jdk1.7.0\bin>jmap -histo 11372 num
#instances
#bytes
class name
---------------------------------------------1:
103936
16083192
2:
98630
9517600
[C
3:
103936
8327696
1382
23.2
4:
10042
6929984
5:
10042
4533928
6:
8560
4067552
7:
85434
3901168
[B
8:
76434
1834416
java.lang.String
Monitoringprogramme vom JDK
9:
64731
1553544
java.util.HashMap$Entry
10:
32035
1416784
[I
11:
10953
1292104
java.lang.Class
4409:
1
8
org.eclipse.jdt.internal.debug.ui....
4410:
1
8
org.eclipse.jdt.ui.actions.Organize... org.eclipse.jdt.internal.corext.refactoring....
...
4411:
1
8
Total
818672
68628952
Ein paar Details mehr sind unter http://download.oracle.com/javase/7/docs/technotes/tools/ share/jmap.html zu finden.
23.2.4 jstack Das Stack-Trace-Programm jstack zeigt laufende Threads an, zusammen mit Informationen über den durch Monitore erzwungenen Wartezustand. Ein Ausschnitt für die Eclipse-Threads: c:\Program Files\Java\jdk1.7.0\bin>jstack
11372
2011-08-12 15:51:37 Full thread dump Java HotSpot(TM) Client VM (21.0-b17 mixed mode, sharing): "org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=2 tid=0x06214000 nid=0x30c4 in Object.wait() [0x069df000] java.lang.Thread.State: TIMED_WAITING (on object monitor)
23 at java.lang.Object.wait(Native Method) – waiting on (a org.eclipse.jface.text.reconciler.DirtyRegionQueue) at ... "Worker-28" prio=6 tid=0x06211400 nid=0xad0 in Object.wait() [0x0711f000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) – waiting on (a org.eclipse.core.internal.jobs.WorkerPool) ...
1383
23
Dienstprogramme für die Java-Umgebung
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:50) ... "[ThreadPool Manager] – Idle Thread" daemon prio=6 tid=0x06211c00 nid=0x295c in
ð
Object.wait() [0x08d7f000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) ... ... "Service Thread" daemon prio=6 tid=0x01f52000 nid=0x2d78 runnable [0x00000000] java.lang.Thread.State: RUNNABLE "C1 CompilerThread0" daemon prio=10 tid=0x01f36c00 nid=0x2b38 waiting on condition
ð
[0x00000000] java.lang.Thread.State: RUNNABLE "Attach Listener" daemon prio=10 tid=0x01f35800 nid=0x1788 waiting on condition
ð
[0x00000000] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" daemon prio=10 tid=0x01f32400 nid=0x2ef8 runnable [0x00000000] java.lang.Thread.State: RUNNABLE "Finalizer" daemon prio=8 tid=0x01f2a400 nid=0x2004 in Object.wait() [0x044df000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) – waiting on (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(Unknown Source) – locked (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(Unknown Source) at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source) "Reference Handler" daemon prio=10 tid=0x01f25000 nid=0x2ca8 in Object.wait() [0x043df000] java.lang.Thread.State: WAITING (on object monitor)
1384
23.2
Monitoringprogramme vom JDK
at java.lang.Object.wait(Native Method) – waiting on (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:503) at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source) – locked (a java.lang.ref.Reference$Lock) "main" prio=6 tid=0x01e19c00 nid=0x2b34 runnable [0x0012f000] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.win32.OS.WaitMessage(Native Method) at org.eclipse.swt.widgets.Display.sleep(Display.java:4652) ... at org.eclipse.equinox.launcher.Main.run(Main.java:1410) "VM Thread" prio=10 tid=0x01f23c00 nid=0x28ec runnable "VM Periodic Task Thread" prio=10 tid=0x01f5c000 nid=0x2898 waiting on condition JNI global references: 373
Zum Stack-Strace der Threads gibt es weitere Informationen unter http://download.oracle.com/javase/7/docs/technotes/tools/share/jstack.html.
23.2.5
VisualVM
VisualVM ist eine grafische Oberfläche mit einfachen Profiling-Möglichkeiten und bettet Kommandozeilenwerkzeuge wie jstack ein. VisualVM ist Teil von Java ab dem JDK 6, aber eine aktuelle Version findet sich immer unter https://visualvm.dev.java.net/. Im JDK befindet es sich wie die anderen Tools im bin-Verzeichnis und hört auf den Namen jvisualvm. Wir wollen die mitgelieferte Version nutzen. Beim ersten Mal müssen wir eine Kalibrierung starten, doch dann öffnet sich schon die grafische Oberfläche. Wählen wir links im Baum Local 폷 VisualVM aus, so schauen wir uns die Zustände, etwa den Speicherbedarf und die Thread-Auslastung des Programms VisualVM selbst an (siehe Abbildung 23.1).
Durch den Speicher wühlen: Heap-Dump Visual VM bietet die großartige Möglichkeit, sich während der Laufzeit zu einem Programm zu verbinden und über die Objektverweise zu navigieren. Unser Beispiel soll ein kleines Programm HeapUser sein, von dem wir später die vier Objektvariablen untersuchen wollen:
1385
23
23
Dienstprogramme für die Java-Umgebung
Abbildung 23.1: Screenshot der VisualVM Listing 23.1: HeapUser.java import java.util.*; public class HeapUser { String string = "Hallo Welt"; Date
date
= new Date();
ArrayList list = new ArrayList( Arrays.asList( string, date.toString() ) ); HeapUser heapUser; public static void main( String[] args ) { HeapUser h = new HeapUser(); h.heapUser = h; new Scanner( System.in ).next(); System.out.println( h.string ); } }
1386
23.2
Monitoringprogramme vom JDK
Starten wir das Programm und VisualVM läuft noch im Hintergrund, so erkennt VisualVM automatisch das gestartete Program und aktualisiert die Baumansicht unter local. Im Kontextmenü lässt sich über HeapUser der Heap-Dump erfragen.
Abbildung 23.2: Heap-Dump anzeigen
Nach dem Aktivieren des Schalters Classes sind alle geladenen Klassen aufgeführt und es ist zu sehen, wie viele Exemplare es von den Klassen gibt.
23
Abbildung 23.3: Anzeige der geladenen Klassen mit Statistik
1387
23
Dienstprogramme für die Java-Umgebung
Unten gibt es ein Suchfeld, in dem wir »HeapUser« eintragen. Es bleibt eine Klasse in der Liste.
Abbildung 23.4: Suchen nach »HeapUser«
Im Kontextmenü lässt sich nun Show in Instances View aufrufen.
Abbildung 23.5: Exemplare vom Typ »HeapUser« anfordern
Die folgende Ansicht bildet den Ausgangspunkt für exploratives Arbeiten.
1388
23.2
Monitoringprogramme vom JDK
Abbildung 23.6: Attribute und Belegungen einsehen
Links ist die Instanz abgebildet, die wir untersuchen. Das ist HeapUser, von dem es genau ein Exemplar gibt (#1). Rechts gibt es zwei Einteilungen. In der oberen Einteilung können wir die Objekteigenschaften vom links ausgewählten Objekt sehen und durch die Baumansicht tiefer reinzoomen. So enthält this, also das ausgewählte Objekt, die Variablen heapUser, list, date und string. An den auf sich selbst verweisenden Pfeilen an heapUser lässt sich – die Symbole werden in einer Art Statusleiste kurz erklärt – erkennen, dass die Variable heapUser das eigene Objekt referenziert. Falten wir list auf, so sehen wir die Objektvariablen der ArrayList-Instanz im Baum, und unter anderem lässt sich die size ablesen, also die Anzahl der Elemente in der Liste. elementData wiederum ist ein Knoten, der sich auffalten lässt, er repräsentiert das interne Feld – die eckigen Klammern deuten den Typ »Feld« an – der ArrayList. Wird er ausgefaltet, gelangen wir zu den beiden Strings. Im unteren Bereich der Einteilung, bei References, ist abzulesen, wer das selektierte Objekt referenziert. Es gibt zwei Stellen, an denen das untersuchte Objekt HeapUser referenziert wird: Einmal über die lokale Variable in der main-Methode, und einmal über die Objektvariable.
1389
23
23
Dienstprogramme für die Java-Umgebung
Profiling von Java-Applikationen Ein Profiler zeigt an, an welchen Stellen ein Programm Prozessorzeit verbraucht. Auf der Webseite https://visualvm.dev.java.net/profiler.html stellt Oracle eine Dokumentation bereit, wie VisualVM als Profiler genutzt wird.
23.3
Programmieren mit der Tools-API
Tools wie der Java-Compiler javac, aber auch jarsigner, javadoc, apt, xjc, javap und andere Kommandozeilenwerkzeuge, sind rein in Java geschrieben. Einige Tools bieten Entwicklern eine API, sodass sie erweitert und von Programmen angesprochen werden können. Das ist interessant für Tool-Anbieter, die zum Beispiel den Compiler erweitern oder die Ausgabe vom JavaDoc-Tool anpassen möchten. Alle in Java geschriebenen Programme befinden sich in einem Extra-Java-Archiv mit dem Namens tools.jar, das sich im lib-Verzeichnis des JDK befindet. Die normalen ausführbaren Programme wie javadoc oder javah haben (unter Windows) alle die gleiche Größe um 15 KiB, da sie nichts anderes machen, als die Java-Laufzeitumgebung mit tools.jar im Klassenpfad aufzurufen und dann an die entsprechende main()-Methode des Programms weiterzuleiten. Statt javadoc aufzurufen, kommt com.sun.tools.javadoc.Main.main() zum gleichen Ziel. Oracle definiert nicht für jedes Tool eine API. So ist es zum Beispiel nicht vorgesehen, in den Erzeugungsprozess von javah einzugreifen. Wohl ist es aber möglich, eigene Doclets zu schreiben – Doclets sind kleine Programme, die aus der Java-API-Dokumentation zum Beispiel verlinkte HTML-Dokumente aufbauen.
23.3.1
Eigene Doclets
Standardmäßig sind die Programme – und die API der Programme – nicht im Klassenpfad eingebunden. Um eigene Doclets zu schreiben, muss zunächst tools.jar in den Klassenpfad aufgenommen werden. Das macht neue Pakete wie com.sun.javadoc (Metadateien) und com.sun.tools.javadoc (Doclet-Tool selbst) verfügbar. Im folgenden Beispiel wollen wir ein kleines Doclet schreiben, das Klassen, Methoden und Konstruktoren ausgibt, die das Tag @since 1.7 tragen. So lässt sich leicht ermitteln, was in der Version Java 7 alles hinzugekommen ist. Doclets werden normalerweise von der Kommandozeile aufgerufen und dem javadoc-Tool übergeben. Unser Programm vereinfacht das, indem es direkt das Tool über Java mit dem passenden Parameter aufruft.
1390
23.3
Programmieren mit der Tools-API
Listing 23.2: com/tutego/tools/javadoc/SinceJava7FinderDoclet.java package com.tutego.tools.javadoc; import java.io.*; import java.util.Formatter; import com.sun.javadoc.*; import com.sun.tools.javadoc.Main; public class SinceJava7FinderDoclet { private final static Formatter formatter = new Formatter(); public static boolean start( RootDoc root ) { for ( ClassDoc clazz : root.classes() ) processClass( clazz ); return true; } private static void processClass( ClassDoc clazz ) { for ( Tag tag : clazz.tags( "since" ) ) if ( "1.7".equals( tag.text() ) ) formatter.format( "Neuer Typ %s%n", clazz ); for ( MethodDoc method : clazz.methods() ) for ( Tag tag : method.tags( "since" ) ) if ( "1.7".equals( tag.text() ) )
23
formatter.format( "Neue Methode %s%n", method ); for ( ConstructorDoc constructor : clazz.constructors() ) for ( Tag tag : constructor.tags( "since" ) ) if ( "1.7".equals( tag.text() ) ) formatter.format( "Neuer Konstruktor %s%n", constructor ); for ( FieldDoc field : clazz.fields() ) for ( Tag tag : field.tags( "since" ) )
1391
23
Dienstprogramme für die Java-Umgebung
if ( "1.7".equals( tag.text() ) ) formatter.format( "Neues Attribut %s%n", field ); } public static void main( String[] args ) { PrintStream err = System.err, out = System.out; System.setErr( new PrintStream( new OutputStream() { @Override public void write( int b ) { } } ) ); System.setOut( System.err ); String[] params = { "-quiet", // ignored!? "-doclet", SinceJava7FinderDoclet.class.getName(), "-sourcepath", "C:/Program Files/Java/jdk1.7.0/src/", //
"java.lang" "-subpackages", "java:javax" }; Main.execute( params ); System.setErr( err ); System.setOut( out ); System.out.println( formatter ); }
}
Unsere main()-Methode ruft das JDK-Doclet-Programm über Main.execute() auf und übergibt die eigene Doclet-Klasse per Parameter – die Argumente von execute() erinnern an die Kommandozeilenparameter. Das Doclet-Hauptprogramm wiederum ruft unsere start(RootDoc root)-Methode auf – das Gleiche würde auch passieren, wenn das Doclet von außen über javadoc aufgerufen würde. start() läuft über alle ermittelten Typen und übergibt zum Abarbeiten der Innereien die Verantwortung an processClass(). Die Metadaten kommen dabei über diverse XXXDoc-Typen.
1392
23.4
Ant
23.4 Ant Die Arbeit eines Softwareentwicklers ist nicht immer so spannend, wie es einem die Fantasie vorgaukelt. Der Alltag besteht aus Compilieren, dem Erstellen von Dokumentationen, dem Aktualisieren von Webseiten, dem Ausliefern von Archiven und Ähnlichem. Der schlaue Zeitgenosse schreibt sich für diese Aufgaben Skripte. Unter Unix wurde für die Sammlung dieser Skripte ein sogenanntes make-Tool benutzt. Eine besondere Aufgabe von make war es, Zusammenhänge zwischen verschiedenen Quellcodedateien zu erkennen und dann die benötigten neu zu übersetzen. Wenn sich zum Beispiel eine Header-Datei ändert, muss auch die C-Datei, die diese Header-Datei einbindet, neu übersetzt werden. Unter Java können wir mit diesem make-Tool nicht so viel anfangen, doch Aufgaben wie das Erstellen von Archiven, die Neuübersetzung aller Quellen und das Erzeugen von Dokumentationen bleiben. Für diese Aufgaben wurde von der Apache-Gruppe ein Tool mit dem Namen Ant (http://ant.apache.org/) entwickelt. Der Name selbst ist ein Akronym aus Another Neat Tool. Ein weiteres populäres Produkt der Apache Software Foundation ist Maven (http:// maven.apache.org/). Es geht einen Schritt weiter und bietet standardisiertes Erstellen von Anwendungen zusammen mit der jeweiligen Dokumentation und Tests für den gesamten Build-Prozess.
23.4.1
Bezug und Installation von Ant
Wir erhalten ein Archiv von Ant auf den Seiten der Indianer-Gruppe, genauer gesagt unter http://ant.apache.org/bindownload.cgi. Nach dem Entpacken sollten wir unsere Umgebungsvariable (PATH) so erweitern, dass sie auf das bin/-Verzeichnis von Ant zeigt. Wenn wir jetzt ant auf der Kommandozeile aufrufen, sollte folgende Ausgabe zu sehen sein: $ ant Buildfile: build.xml does not exist! Build failed
23 Die Installation liefert alle benötigten Bibliotheken gleich mit.
Beispielklasse, die Ant übersetzen soll Wir begnügen uns am Anfang mit einer einfachen Java-Klasse, die Ant verwalten soll: Listing 23.3: ant/AntDemo.java package ant; public class AntDemo
1393
23
Dienstprogramme für die Java-Umgebung
{ public static void main( String[] args ) { System.out.println( "Ant is beautiful." ); } }
Dieses Mal soll die Quellcodedatei nicht von Hand übersetzt werden, sondern ein Ant-Skript soll dies erledigen.
23.4.2 Das Build-Skript build.xml Eine XML-Datei beschreibt, welche Schritte Ant auszuführen hat. Ant nennt die Dateien BuildFiles, und eine solche Datei heißt oft build.xml. Wir wollen sie in das gleiche Verzeichnis stellen, in dem auch unsere Java-Quellcodedatei steht: Listing 23.4: build.xml
Eine DTD-Referenzierung ist für die XML-Datei nicht zwingend nötig, da der Parser die Datei nicht validierend abarbeitet. Der Eintrag definiert das Projekt unter dem Namen Insel. Das Attribut default definiert weiterhin, dass der einfache Aufruf von Ant automatisch das Ziel build aufrufen soll.
23.4.3 Build den Build Im Inneren des Eintrags folgen -Einträge. Wir definieren das Ziel build, das den Compiler starten soll. Das übernimmt der Task , der alle Dateien compiliert, die sich im aktuellen Verzeichnis befinden. Neben stellt Ant eine große Zahl zusätzlicher Tasks bereit. Wechseln wir auf der Kommandozeile in das Verzeichnis mit den Dateien, dann reicht es, Ant aufzurufen, und der Konstruktionsprozess beginnt. Ant sucht selbstständig nach der Datei build.xml. Folgendes erscheint:
1394
23.4
Ant
$ ant Buildfile: build.xml build: [javac] Compiling 1 source file BUILD SUCCESSFUL
Die Option -verbose gibt zusätzliche Informationen über den Entstehungsprozess aus. Die Datei build.xml lässt sich vielfältig anpassen. Nehmen wir uns den Eintrag noch einmal vor, und erweitern wir ihn zu:
Das weist Ant an, während der Übersetzung zu optimieren und Debug-Informationen mit aufzunehmen. Das Attribut includes befiehlt, nicht nur Quellcodedateien des aktuellen Verzeichnisses zu übersetzen, sondern auch alle Dateien aller Unterverzeichnisse. Die Notation **/ ist eine Vereinfachung, die für alle Unterverzeichnisse steht. An ihrer Stelle ist auch eine Aufzählung der Verzeichnisse zulässig.
23.4.4 Properties Eine gute Idee ist es, sich von den konkreten Pfaden im -Element zu lösen, denn Ant erlaubt es, Eigenschaften zu definieren, die Platzhaltern oder Makros ähneln. Um Programme aus einem Verzeichnis (nennen wir es src) in ein Zielverzeichnis (nennen wir es build) zu übersetzen, schreiben wir:
Bisher haben wir uns mit der Übersetzung beschäftigt. Dennoch wissen wir, dass wir auch noch andere target-Elemente verwenden können. Und obwohl die Benennung dieser Targets prinzipiell willkürlich ist, gibt es eine vorgeschlagene Namenskonvention. Eintrag
Bedeutung
init
Erstellt Verzeichnisse und Initialisierungsdateien.
build
Inkrementeller Aufbau
test
Ablaufen der Tests mit JUnit
Tabelle 23.1: Namenskonvention für Targets
1395
23
23
Dienstprogramme für die Java-Umgebung
Eintrag
Bedeutung
clean
Ausgabeverzeichnisse löschen
deploy
*.jar, *.war und sonstige Archive erstellen
publish
Veröffentlichen der Ergebnisse
fetch
Bezieht Quellcodedateien aus der Versionsverwaltung.
docs, javadocs
Erstellt die Dokumentation.
all
Abfolge von clean, fetch, build, test, docs, deploy
main
Erstellt das Projekt, in der Regel build oder build, test.
Tabelle 23.1: Namenskonvention für Targets (Forts.)
Der Eintrag init soll eine initiale Verzeichnisstruktur aufbauen. Nehmen wir an, der Compiler soll in unser oben genanntes Verzeichnis build übersetzen. Dann muss dieses Verzeichnis natürlich existieren. Das Anlegen des Verzeichnisses kann in init geschehen:
Um die erstellten Verzeichnisse in einem Target clean zu löschen, wollen wir eine Property dist für das Distributionsverzeichnis hinzunehmen:
23.4.5 Externe und vordefinierte Properties Falls sich das Versionsrad eine Nummer weiter dreht, ist es ungünstig, wenn Änderungen an der XML-Datei vorzunehmen sind. Eine gute Lösung für das Problem besteht darin, eine externe Datei anzugeben, die die Version definiert. Das kann so aussehen: Listing 23.5: version.properties version=0.7
Jetzt fehlt nur noch der Bezug zu dieser Eigenschaften-Datei in der XML-Datei. Bisher kennen wir zwar einen Eintrag property name und value, aber eine zweite Variante mit dem Attribut file bindet eine Datei ein, die Schlüssel-Werte-Paare wie bei unserer version.properties beschreibt.
1396
23.4
Ant
Jetzt lässt sich auf die Variable version ganz normal zugreifen, um zum Beispiel eine zweite Eigenschaft einzuführen:
version ist unsere Variable, und ${version} setzt den Inhalt der Variablen ein. Daneben gibt es
aber noch einige Standard-Properties: Property
Bedeutung
Basedir
absoluter Pfad zum Basisverzeichnis des Projekts; in basedir gesetzt
ant.file
absoluter Pfad der Build-Datei
ant.version
Version von Ant
ant.project.name
Name des Projekts, wie in gesetzt
ant.java.version
JVM-Version, wie von Ant entdeckt, etwa »1.6«
Tabelle 23.2: Standard-Properties
23.4.6 Weitere Ant-Tasks Ant kann Programme mit automatischen Tests mit JUnit überprüfen, Klassendateien zu einem Archiv zusammenbinden oder E-Mails verschicken. Die Archive lassen sich automatisch auf einen FTP-Server übertragen. Für Ant gibt es viele Tasks; http://ant.apache.org/ manual/tasksoverview.html gibt einen Überblick. Die wichtigsten Tasks sind: Ant-Task
Aufgabe
javac
Übersetzt mit Java-Compiler.
jar
Bündelt Dokumente in ein Java-Archiv.
manifest
Erzeugt eine Manifest-Datei.
signjar
Signiert ein Java-Archiv.
unjar
Packt Java-Archive aus.
javadoc
Erzeugt die Java-Dokumentation.
exec
Startet ein externes Programm.
copy
Kopiert Dateien.
mkdir
Legt ein Verzeichnis an.
move
Verschiebt Dateien.
23
Tabelle 23.3: Ausgewählte Ant-Tasks
1397
23
Dienstprogramme für die Java-Umgebung
Ant-Task
Aufgabe
echo
Schreibt Ausgaben auf die Konsole.
sql
Sendet SQL-Anweisungen zur Datenbank.
javah
Erzeugt C-Header Dateien für JNI.
junit
Arbeitet JUnit-Tests ab.
Tabelle 23.3: Ausgewählte Ant-Tasks (Forts.)
Neben Tasks spielen FileSets eine wichtige Rolle. Sie bilden Gruppen von Dateien. Die Gruppen werden nach bestimmen Kriterien gebildet, etwa nach der Dateiendung. Folgendes FileSet umfasst alle Java-Quellcodedateien, schließt aber alle Test-Dateien aus, die sich in Unterverzeichnissen ausgehend von der Angabe des Wurzelpfads über die Property src befinden:
Beispiel Das ClassFileSet (http://ant.apache.org/manual/OptionalTypes/classfileset.html) ist ein besonderes FileSet, das nicht einfach alle Dateien von Verzeichnissen auswählt, sondern durch Bytecode-Analyse herausfindet, welche Abhängigkeiten es wirklich gibt. So gelangen nur die Klassendateien in die Gruppe, die vom angegebenen Wurzelelement referenziert werden.
23.5
Disassembler, Decompiler und Obfuscator
Ein Disassembler ist ein Werkzeug, das den Bytecode und die Struktur einer Java-Klassendatei anzeigt. Ein Decompiler geht einen Schritt weiter und versucht aus Klassendateien wieder Quellcodedateien zu gewinnen, die, wenn sie später compiliert werden, wieder den gleichen Bytecode ergeben würden. Genau diese »leichte« Lesbarkeit von Bytecode oder eine Decompliation möchte ein anderes Werkzeug, der Obfuscator, erschweren. Das Ziel von Obfuscation ist das möglichst effektive Verschleiern aller Bytecodeinformationen, sodass Menschen den Spaß am Bytecode verlieren und Decompiler bei ihrer Rücktransformation sogar aus dem Tritt kommen. Das Eclipse-Plugin ByteCodeDeluxe unter http://www.idedeluxe.com/bytecode/ visualisiert die Struktur einer Bytecode-Datei.
1398
23.5
23.5.1
Disassembler, Decompiler und Obfuscator
Der Diassembler javap
Das JDK liefert im bin-Verzeichnis der Installation mit javap ein Werkzeug aus, das zwar nicht die Implementierung von Methoden hervorzaubert, aber immerhin die statische Struktur einer Klasse mit den Vererbungsbeziehungen, Variablen, Methoden, Parametern anzeigt. In der einfachsten Variante wird javap mit dem Klassennamen aufgerufen. Wir nehmen im Folgenden an, dass javap im Suchpfad steht und wir uns auf der Kommandozeile direkt im bin-Verzeichnis vom JDK befinden. Wir setzen zuerst den Klassenpfad und geben anschließend als Kommandozeilenargument für javap die Klasse Quadrat aus dem ersten Kapitel an, die disassembliert werden soll. $ javap -classpath Z:\Documents\Insel\programme\1_01_Intro Quadrat Compiled from "Quadrat.java" public class Quadrat extends java.lang.Object{ public Quadrat(); static int quadrat(int); static void ausgabe(int); public static void main(java.lang.String[]); }
Abzulesen sind auch Dinge, die der Compiler automatisch generiert und die im Bytecode stehen, die wir aber im Allgemeinen nicht schreiben würden, etwa der voll qualifizierte Klassenname java.lang.Object oder java.lang.String, die Vererbungsbeziehung zu Object oder der automatisch angelegte Standardkonstruktor. Das Tool javap erlaubt noch mehr Parameter, die die Option -help anzeigt. $ javap -help Usage: javap ... where options include:
23
-c
Disassemble the code
-classpath
Specify where to find user class files
-extdirs
Override location of installed extensions
-help
Print this usage message
-J
Pass directly to the runtime system
-l
Print line number and local variable tables
-public
Show only public classes and members
-protected
Show protected/public classes and members
-package
Show package/protected/public classes
1399
23
Dienstprogramme für die Java-Umgebung
and members (default) -private
Show all classes and members
-s
Print internal type signatures
-bootclasspath Override location of class files loaded by the bootstrap class loader -verbose
Print stack size, number of locals and args for methods If verifying, print reasons for failure
Hinweis Auch der Java-Compiler kann seit Java 7 mit dem neuen Schalter –Xprint ähnliche Informationen ausgeben: $ javac.exe -Xprint Quadrat.java public class Quadrat { public Quadrat(); static int quadrat(int n); static void ausgabe(int n); public static void main(java.lang.String[] args); }
Java-Bytecode am Beispiel Interessanter ist der Schalter -c, der den Bytecode der Methoden/Konstruktoren/Initialisierer anzeigt. Am Beispiel: $ javap -c -classpath Z:\Documents\Insel\programme\1_01_Intro Quadrat Compiled from "Quadrat.java" public class Quadrat extends java.lang.Object{
Steigen wir nicht chronologisch ein, sondern bei der statischen Methode quadrat(). Sie bekommt als Argument ein int und liefert es multipliziert mit sich selbst zurück: static int quadrat(int); Code: 0:
iload_0
1:
iload_0
2:
imul
3:
ireturn
1400
23.5
Disassembler, Decompiler und Obfuscator
Die Ausgabe macht die Stack-Natur des JVM sichtbar. Der Übergabeparameter n von quadrat(int n) steht auf Position 0 im Stack. Um das Quadrat zu bilden, wird der aktuelle Parameter zweimal mit iload_0 auf den Stapel gelegt und dann mit imul multipliziert. imul löscht die beiden Werte vom Stapel und ersetzt sie durch das Ergebnis der Multiplikation. ireturn liefert den obersten Stackwert als int zurück. Das Präfix »i« bei imul und ireturn zeigt, dass die Operationen auf Ganzzahlen durchgeführt werden. Andere Präfixe sind »b« für byte, »c« für char, »d« für double oder »a« für Objektreferenzen. Kommen wir zur statischen main-Methode: public static void main(java.lang.String[]); Code: 0:
iconst_4
1:
invokestatic
4:
return
#59; //Method ausgabe:(I)V
}
Im Rumpf der main()-Methode steht der Aufruf ausgabe(4), was im Bytecode dazu führt, dass mit iconst_4 der Wert 4 auf den Stack gelegt wird und dann invokestatic die Methode ausgabe() aufruft. Der Standardkonstruktor von Quadrat ruft lediglich den Standardkonstruktor der Oberklasse Object auf. public Quadrat(); Code: 0:
aload_0
1:
invokespecial
4:
return
#8; //Method java/lang/Object."":()V
Bei Konstruktoren und Objektmethoden ist automatisch an Position 0 im Stack die this-Referenz gesetzt, da die Aufrufer automatisch an Position 0 diese Referenz übergeben. (Bei statischen Methoden ist das nicht so.) Bei unserem Konstruktor Quadrat() setzt also aload_0 diese this-Referenz auf den Stack, damit der Konstruktor der Oberklasse, also Object aufgerufen werden kann. Konstrukturaufrufe werden im Bytecode mit invokespecial durchgeführt. Im Kern ist ein Konstruktor eine Methode mit dem speziellen Namen und der Rückgabe void. Die Angabe #8 ist ein Verweis auf eine interne Tabelle, doch der Java-Kommentar macht den Eintrag für uns lesbar. Am komplexesten ist die statische Methode ausgabe(). Im Original sieht sie so aus:
1401
23
23
Dienstprogramme für die Java-Umgebung
String s; int
i;
for ( i = 1; i