Java SE 8 Standard-Bibliothek  
Professionelle Bücher. Auch für Einsteiger.
 
Inhaltsverzeichnis


Vorwort
1 Neues in Java 8 und Java 7
2 Fortgeschrittene String-Verarbeitung
3 Threads und nebenläufige Programmierung
4 Datenstrukturen und Algorithmen
5 Raum und Zeit
6 Dateien, Verzeichnisse und Dateizugriffe
7 Datenströme
8 Die eXtensible Markup Language (XML)
9 Dateiformate
10 Grafische Oberflächen mit Swing
11 Grafikprogrammierung
12 JavaFX
13 Netzwerkprogrammierung
14 Verteilte Programmierung mit RMI
15 RESTful und SOAP-Web-Services
16 Technologien für die Infrastruktur
17 Typen, Reflection und Annotationen
18 Dynamische Übersetzung und Skriptsprachen
19 Logging und Monitoring
20 Sicherheitskonzepte
21 Datenbankmanagement mit JDBC
22 Java Native Interface (JNI)
23 Dienstprogramme für die Java-Umgebung
Stichwortverzeichnis

Jetzt Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Java SE 8 Standard-Bibliothek von Christian Ullenboom
Das Handbuch für Java-Entwickler
Buch: Java SE 8 Standard-Bibliothek

Java SE 8 Standard-Bibliothek
Pfeil 4 Datenstrukturen und Algorithmen
Pfeil 4.1 Datenstrukturen und die Collection-API
Pfeil 4.1.1 Designprinzip mit Schnittstellen, abstrakten und konkreten Klassen
Pfeil 4.1.2 Die Basisschnittstellen Collection und Map
Pfeil 4.1.3 Die Utility-Klassen Collections und Arrays
Pfeil 4.1.4 Das erste Programm mit Container-Klassen
Pfeil 4.1.5 Die Schnittstelle Collection und Kernkonzepte
Pfeil 4.1.6 Schnittstellen, die Collection erweitern, und Map
Pfeil 4.1.7 Konkrete Container-Klassen
Pfeil 4.1.8 Generische Datentypen in der Collection-API
Pfeil 4.1.9 Die Schnittstelle Iterable und das erweiterte for
Pfeil 4.2 Listen
Pfeil 4.2.1 Erstes Listen-Beispiel
Pfeil 4.2.2 Auswahlkriterium ArrayList oder LinkedList
Pfeil 4.2.3 Die Schnittstelle List
Pfeil 4.2.4 ArrayList
Pfeil 4.2.5 LinkedList
Pfeil 4.2.6 Der Feld-Adapter Arrays.asList(…)
Pfeil 4.2.7 ListIterator *
Pfeil 4.2.8 toArray(…) von Collection verstehen – die Gefahr einer Falle erkennen
Pfeil 4.2.9 Primitive Elemente in Datenstrukturen verwalten
Pfeil 4.3 Mengen (Sets)
Pfeil 4.3.1 Ein erstes Mengen-Beispiel
Pfeil 4.3.2 Methoden der Schnittstelle Set
Pfeil 4.3.3 HashSet
Pfeil 4.3.4 TreeSet – die sortierte Menge
Pfeil 4.3.5 Die Schnittstellen NavigableSet und SortedSet
Pfeil 4.3.6 LinkedHashSet
Pfeil 4.4 Queues (Schlangen) und Deques
Pfeil 4.4.1 Queue-Klassen
Pfeil 4.4.2 Deque-Klassen
Pfeil 4.4.3 Blockierende Queues und Prioritätswarteschlangen
Pfeil 4.4.4 PriorityQueue
Pfeil 4.5 Stack (Kellerspeicher, Stapel)
Pfeil 4.5.1 Die Methoden von java.util.Stack
Pfeil 4.6 Assoziative Speicher
Pfeil 4.6.1 Die Klassen HashMap und TreeMap
Pfeil 4.6.2 Einfügen und Abfragen des Assoziativspeichers
Pfeil 4.6.3 Über die Bedeutung von equals(…) und hashCode() bei Elementen
Pfeil 4.6.4 Eigene Objekte hashen
Pfeil 4.6.5 LinkedHashMap und LRU-Implementierungen
Pfeil 4.6.6 IdentityHashMap
Pfeil 4.6.7 Das Problem veränderter Elemente
Pfeil 4.6.8 Aufzählungen und Ansichten des Assoziativspeichers
Pfeil 4.6.9 Die Arbeitsweise einer Hash-Tabelle *
Pfeil 4.6.10 Die Properties-Klasse
Pfeil 4.7 Mit einem Iterator durch die Daten wandern
Pfeil 4.8 Iterator-Schnittstelle
Pfeil 4.8.1 Der Iterator kann (eventuell auch) löschen
Pfeil 4.8.2 Operationen auf allen Elementen durchführen
Pfeil 4.8.3 Einen Zufallszahlen-Iterator schreiben
Pfeil 4.8.4 Iteratoren von Sammlungen, das erweiterte for und Iterable
Pfeil 4.8.5 Fail-Fast-Iterator und die ConcurrentModificationException
Pfeil 4.8.6 Die Schnittstelle Enumerator *
Pfeil 4.9 Algorithmen in Collections
Pfeil 4.9.1 Die Bedeutung von Ordnung mit Comparator und Comparable
Pfeil 4.9.2 Sortieren
Pfeil 4.9.3 Den größten und kleinsten Wert einer Collection finden
Pfeil 4.9.4 Nichtänderbare Datenstrukturen, immutable oder nur lesen?
Pfeil 4.9.5 Null Object Pattern und leere Sammlungen/Iteratoren zurückgeben
Pfeil 4.9.6 Echte typsichere Container
Pfeil 4.9.7 Mit der Halbierungssuche nach Elementen fahnden
Pfeil 4.9.8 Ersetzen, Kopieren, Füllen, Umdrehen, Rotieren *
Pfeil 4.9.9 Listen durchwürfeln *
Pfeil 4.9.10 Häufigkeit eines Elements *
Pfeil 4.9.11 Singletons *
Pfeil 4.9.12 nCopies(…) *
Pfeil 4.10 Datenstrukturen mit Änderungsmeldungen
Pfeil 4.10.1 Das Paket javafx.collections
Pfeil 4.10.2 Fabrikmethoden in FXCollections
Pfeil 4.10.3 Änderungen melden über InvalidationListener
Pfeil 4.10.4 Änderungen melden über XXXChangeListener
Pfeil 4.10.5 Change-Klassen
Pfeil 4.10.6 Weitere Hilfsmethoden einer ObservableList
Pfeil 4.10.7 Melden von Änderungen an Arrays
Pfeil 4.10.8 Transformierte FXCollections
Pfeil 4.10.9 Weitere statische Methoden in FXCollections
Pfeil 4.11 Stream-API
Pfeil 4.11.1 Stream erzeugen
Pfeil 4.11.2 Terminale Operationen
Pfeil 4.11.3 Intermediäre Operationen
Pfeil 4.11.4 Streams mit primitiven Werten
Pfeil 4.11.5 Stream-Beziehungen, AutoCloseable
Pfeil 4.11.6 Stream-Builder
Pfeil 4.11.7 Spliterator
Pfeil 4.11.8 Klasse StreamSupport
Pfeil 4.12 Spezielle threadsichere Datenstrukturen
Pfeil 4.12.1 Zu Beginn nur synchronisierte Datenstrukturen in Java 1.0
Pfeil 4.12.2 Nicht synchronisierte Datenstrukturen in der Standard-Collection-API
Pfeil 4.12.3 Nebenläufiger Assoziativspeicher und die Schnittstelle ConcurrentMap
Pfeil 4.12.4 ConcurrentLinkedQueue
Pfeil 4.12.5 CopyOnWriteArrayList und CopyOnWriteArraySet
Pfeil 4.12.6 Wrapper zur Synchronisation
Pfeil 4.12.7 Blockierende Warteschlangen
Pfeil 4.12.8 ArrayBlockingQueue und LinkedBlockingQueue
Pfeil 4.12.9 PriorityBlockingQueue
Pfeil 4.12.10 Transfer-Warteschlangen – TransferQueue und LinkedTransferQueue
Pfeil 4.13 Google Guava (Google Collections Library)
Pfeil 4.13.1 Beispiel Multi-Set und Multi-Map
Pfeil 4.13.2 Datenstrukturen aus Guava
Pfeil 4.13.3 Utility-Klassen von Guava
Pfeil 4.13.4 Prädikate
Pfeil 4.13.5 Transformationen
Pfeil 4.14 Die Klasse BitSet für Bitmengen *
Pfeil 4.14.1 Ein BitSet anlegen
Pfeil 4.14.2 BitSet füllen und Zustände erfragen
Pfeil 4.14.3 Mengenorientierte Operationen
Pfeil 4.14.4 Weitere Methoden von BitSet
Pfeil 4.14.5 Primzahlen in einem BitSet verwalten
Pfeil 4.15 Zum Weiterlesen
 
Zum Seitenanfang

4.8Iterator-Schnittstelle Zur vorigen ÜberschriftZur nächsten Überschrift

Die Iterator-Schnittstelle ist klein und schreibt drei Methoden vor, dazu kommt in Java 8 eine Default-Methode, die wir uns später anschauen.

interface java.util.Iterator<E>
  • 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()
    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.

[zB]Beispiel

Da jede Collection eine Methode iterator() besitzt, lassen sich alle Elemente einer Sammlung wie folgt auf dem Bildschirm ausgeben:

Collection<String> set = new TreeSet<>();
Collections.addAll( set, "Horst", "Schlämmer", "Hape" , "Kerkeling" );
for ( Iterator<String> 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.

 
Zum Seitenanfang

4.8.1Der Iterator kann (eventuell auch) löschen Zur vorigen ÜberschriftZur nächsten Überschrift

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.

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.

[»]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 einer NavigableMap. Dort ist die Einfügeposition durch die Sortierung vorgegeben oder belanglos (bzw. 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.

 
Zum Seitenanfang

4.8.2Operationen auf allen Elementen durchführen Zur vorigen ÜberschriftZur nächsten Überschrift

Mit der in Java 8 neu eingeführten Default-Methode forEachRemaining(…) lässt sich Programmcode (genannt Konsument) für jedes (verbleibende) Element des Iterators aufrufen. Statt also von Hand in einer Schleife das Paar hashNext()/next() zu verwenden, läuft forEachRemaining(…) für uns den Iterator komplett ab. Verschiedene Implementierungen des Iterators können dabei frei machen, was sie wollen, etwa die Abarbeitung in einem Extra-Thread setzen.

interface java.util.Iterator<E>
  • default void forEachRemaining(Consumer<? super E> action)

 
Zum Seitenanfang

4.8.3Einen Zufallszahlen-Iterator schreiben Zur vorigen ÜberschriftZur nächsten Überschrift

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 4.24com/tutego/insel/util/RandomIterator.java

package com.tutego.insel.util;

import java.util.*;

/**
* Iterator for pseudorandom numbers.
*/
public class RandomIterator implements Iterator<Integer> {

private final Random random = new Random();
private final int bound;

/**
* Initializes this iterator with a maximum value (exclusive) for
* pseudorandom numbers.
* @param bound Maximum (exclusive) pseudorandom
*/
public RandomIterator( int bound ) {
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();
}
}

Ein Beispiel:

Listing 4.25com/tutego/insel/util/RandomIteratorDemo.java, main()

Iterator<Integer> 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).

 
Zum Seitenanfang

4.8.4Iteratoren von Sammlungen, das erweiterte for und Iterable Zur vorigen ÜberschriftZur nächsten Überschrift

Jede Collection wie ArrayList oder HashSet liefert mit iterator() einen Iterator.

interface java.util.Collection<E>
extends Iterable<E>
  • Iterator<E> iterator()
    Liefert den Iterator der Datenstruktur.

Collection erweitert eine Schnittstelle Iterable, die diese Methode auch vorschreibt. Iterable kam erst in Java 5 in die Bibliothek, und da gab es iterator() schon, sonst wäre die Methode in Collection nicht noch einmal nötig.

interface java.util.Iterable<T>
  • Iterator<T> 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<String> c = new LinkedList<>();

Ein Aufruf von c.iterator() liefert nun Iterator<String>, und beim Durchlaufen über den Iterator kann die explizite Typanpassung beim next() entfallen:

for ( Iterator<String> i = c.iterator(); i.hasNext(); ) {
String s = i.next();

}

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<String> strings ) {
int result = 0;

for ( String s : strings )
result += s.length();

return result;
}

erzeugt der Compiler selbstständig:

static int totalStringLength( List<String> strings ) {
int result = 0;

for ( Iterator<String> 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.

Ein eigener 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 4.26com/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 4.27com/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}.
*/
public class RotatingIterator<E> implements Iterator<E>, Iterable<E> {

private final Collection<? extends E> collection;
private Iterator<? extends E> iterator;

public RotatingIterator( Collection<? extends E> collection ) {
if ( collection == null )
throw new IllegalArgumentException( "Collection darf nicht null sein" );

this.collection = collection;
iterator = collection.iterator();
}

public RotatingIterator( E... elements ) {
this( Arrays.asList( elements ) );
}

@Override
public boolean hasNext() {
return ! collection.isEmpty();
}

@Override
public E next() {
if ( ! hasNext() )
throw new NoSuchElementException( "Keine Elemente in der Collection" );

if ( ! iterator.hasNext() )
iterator = collection.iterator();

return iterator.next();
}

@Override
public void remove() {
iterator.remove();
}

@Override
public Iterator<E> iterator() {
return this;
}
}
 
Zum Seitenanfang

4.8.5Fail-Fast-Iterator und die ConcurrentModificationException Zur vorigen ÜberschriftZur nächsten Überschrift

Beackern zwei Programmstellen gleichzeitig eine Datenstruktur, so kann es zu Schwierigkeiten kommen, wenn sich die Datenstruktur strukturell verändert, also neue Elemente hinzukommen oder wegfallen. Probleme treten leicht auf, wenn ein Verweis auf die Datenstruktur im Programm an verschiedenen Stellen weitergegeben wird. Führt nun eine Stelle strukturelle Änderungen mit Methoden wie remove(…) oder add(…) durch und verändert sich damit die Größe der Liste, dann kann das zu Zugriffsfehlern führen, wenn die andere Stelle von der Änderung nichts mitbekommt.

Nehmen wir an, zwei Programmteile greifen auf eine gemeinsame Liste zurück. Ein Programmteil merkt sich eine Suchstelle und will anschließend auf das gefundene Element zurückgreifen. Zwischen diesen beiden Operationen verändert jedoch ein anderer Programmteil die Liste, und die Position des Elements verschiebt sich:

Listing 4.28com/tutego/insel/util/ConcurrentModification.java, main()

List<String> list = new ArrayList<>( Arrays.asList( "Trullo", "Zippus" ) );
int posOfZippus = list.indexOf( "Zippus" );
System.out.println( list.get( posOfZippus ) ); // Zippus
list.add( 0, "Apulien" );
System.out.println( list.get( posOfZippus ) ); // Trullo

Nach dem Einfügen von "Apulien" ist posOfZippus also veraltet. Es wäre eine Hilfe, wenn get(…) die strukturelle Veränderung bemerken würde.

Beim Erfragen über Listen-Iteratoren ist das anders. Die Entwickler der Java-Bibliothek haben einen Entwurf gewählt, bei dem konfliktträchtige Änderungen über die Listen-Iteratoren auffallen und zu einer ConcurrentModificationException führen:

Listing 4.29com/tutego/insel/util/ConcurrentModificationExceptionDemo.java, main()

List<String> list = new ArrayList<>( Arrays.asList( "Stunden", "der" ) );
Iterator<String> iterator = list.iterator(); // modCount = 0, expectedModCount = 0
list.get( 0 ); // Anfragen ändert modCount nicht
list.add( "Entspannung" ); // modCount = 1, expectedModCount = 0
iterator.next(); // modCount != expectedModCount => CME

Das funktioniert so, dass sich die Liste die Anzahl struktureller Änderungen merkt – bei der Standardimplementierung vom JDK intern in der Variablen modCount. Der Iterator registriert also die Änderungen, da sich der modCount in der Zwischenzeit durch das add(…) verändert hat. Wird der Iterator initialisiert, erfragt er den modCount der Liste und speichert den Wert in expectedModCount. Jede strukturelle Änderung in der Liste führt zum Inkrement vom modCount. Wird später eine Operation über den Iterator durchgeführt, testet er, ob der gemerkte expectedModCount mit dem aktuellen modCount übereinstimmt. In unserem Fall tut er das nicht, denn add(…) ist eine strukturelle Änderung und modCount wird 1. Beim nachfolgenden next() kommt es zu einer ConcurrentModificationException.

CurrentModificationException vermeiden

Die CurrentModificationException lässt sich in der Regel durch Umbau des Programmcodes vermeiden. Rekapitulieren wir, woher die Ausnahme eigentlich kommt: Sie kommt vom parallelen Verändern, also dem Einfügen oder Löschen der Datenstruktur, während ein Lesedurchlauf über den Iterator stattfindet. Die Lösung besteht darin, die Veränderungen über den Iterator vorzunehmen, denn dieser besitzt Einfüge-/Löschoperationen. Der Standard-Iterator bietet nur remove(), doch der ListIterator bietet auch eine set(…) bzw. add(…)-Methode.

Beispiel: Die folgenden Zeilen sollen eine Datenstruktur result ablaufen und alle Personen rausschmeißen, die verrückt sind. Lösung eins führt zur CurrentModificationException:

for ( Person p : result )
if ( p.isWired() )
result.remove( p ); // CurrentModificationException

Übertragen wir das Löschen dem Iterator, funktioniert es:

for ( Iterator<Person> iterator = result.iterator(); iterator.hasNext(); )
if ( iterator.next().isWired() )
iterator.remove();
 
Zum Seitenanfang

4.8.6Die Schnittstelle Enumerator * Zur vorigen ÜberschriftZur nächsten Überschrift

Für Iteratoren deklariert die Java-Bibliothek zwei unterschiedliche Schnittstellen. Das hat historische Gründe: Die Schnittstelle Enumeration[ 51 ](Nicht Enumerable!) gibt es seit den ersten Java-Tagen; die Schnittstelle Iterator gibt es seit Java 1.2, seit der Collection-API. Der Typ Iterator ist jedoch deutlich weiter verbreitet. Die Namen der Operationen unterscheiden sich in den Schnittstellen ein wenig und sind beim neuen Iterator kürzer.

Hast du mehr?

Gib mir das Nächste!

Iterator

hasNext()

next()

Enumeration

hasMoreElements()

nextElement()

Tabelle 4.4Methoden von Iterator und Enumeration

interface java.util.Enumeration<E>
  • boolean hasMoreElements()
    Testet, ob ein weiteres Element aufgezählt werden kann.

  • E nextElement()
    Liefert das nächste Element der Enumeration zurück. Diese Methode kann später eine NoSuchElementException (eine RuntimeException) auslösen, wenn nextElement() aufgerufen und das Ergebnis false beim Aufruf von hasMoreElements() ignoriert wird.

Wie auch Iterable erweitert Enumeration keine weitere Schnittstelle.

Konvertieren von Enumeration, Iterator, Iterable *

Es gibt keine direkte Methode, die eine Enumeration in einen Iterator oder einen Iterator in eine Enumeration konvertiert. Nur über Umwege lässt sich das erreichen. Es helfen dabei zwei Methoden in der Utility-Klasse Collections:

class java.util.Collections
  • static <T> Enumeration<T> enumeration(Collection<T> c)

  • static <T> ArrayList<T> list(Enumeration<T> e)

Die Methode enumeration() liefert zu einer Collection eine Aufzählung vom Typ Enumeration. (Für einen gewünschten Iterator ist keine Hilfsmethode nötig, da jede Collection die Methode iterator() besitzt.) Ist eine Collection gegeben, so bleibt nichts anderes übrig, als eine temporäre Datenstruktur aufzubauen, Element für Element den Iterator abzulaufen und diese Elemente in die temporäre Datenstruktur zu setzen, die dann Argument der Methode enumeration() wird.

Der zweite Fall ist einfacher. Ist eine Enumeration gegeben, liefert list() eine ArrayList – der Rückgabetyp ist wirklich sehr erstaunlich, da er ungewöhnlich konkret ist. Die ArrayList ist eine Collection und somit Iterable, kann also rechts vom Doppelpunkt beim erweiterten for stehen bzw. liefert mit iterator() einen Iterator.

Blick über den Tellerrand

Unter C++ ist die Standard Template Library (STL) eine Bibliothek, die Datenstrukturen und Algorithmen implementiert. Ein Vergleich der STL mit der Collection-API ist schwierig, obwohl beide Konzepte wie Listen, Mengen und Iteratoren besitzen. So gibt es in Java nur eine Klasse pro Datenstruktur (auch durch Generics), was die STL durch Template-Klassen (daher Template Library) realisiert, die auch primitive Werte (ohne die lästigen Java-Wrapper) speichert. Während Java über den globalen Basistyp Object jedes Objekt in jeder Datenstruktur erlaubt und sich auf die Prüfung zur Laufzeit verlässt, ist C++ da viel strenger. Die Java-Datenstrukturen referenzieren die Objekte und speichern nicht ihre Zustände an sich, wie es bei der STL üblich ist – hier steht Referenz-Semantik gegen Wert-Semantik. Fehler werden von der Collection-API über Exceptions angezeigt, während die STL kaum Ausnahmen auslöst und oft undefinierte Zustände hinterlässt; Entwickler müssen eben korrekte Anfragen stellen. STL nutzt überladene Operatoren wie == statt des Java-equals(…), < für die Ordnung in sortierten Sammlungen, [] beim Zugriff und Überschreiben und den Operator ++ für Iteratoren. Iteratoren spielen bei der STL eine sehr große Rolle – es gibt auch einen Random-Access-Iterator, der Indexierung durch [] erlaubt. Die STL-Algorithmen sind von den Datenstrukturen abgetrennt – anders als in Java – und bekommen die Elemente über Iteratoren.

 


Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück
 Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Java SE 8 Standard-Bibliothek Java SE 8 Standard-Bibliothek
Jetzt Buch bestellen

 Buchempfehlungen
Zum Rheinwerk-Shop: Java ist auch eine Insel
Java ist auch eine Insel


Zum Rheinwerk-Shop: Professionell entwickeln mit Java EE 8
Professionell entwickeln mit Java EE 8


Zum Rheinwerk-Shop: Besser coden
Besser coden


Zum Rheinwerk-Shop: Entwurfsmuster
Entwurfsmuster


Zum Rheinwerk-Shop: IT-Projektmanagement
IT-Projektmanagement


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo

 
 


Copyright © Rheinwerk Verlag GmbH 2018. Original - https://www.rheinwerk-verlag.de/openbook/
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

 

 
 


29.09.2022 - Sitemap.xml