Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.
 
Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Imperative Sprachkonzepte
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Eigene Klassen schreiben
6 Objektorientierte Beziehungsfragen
7 Ausnahmen müssen sein
8 Äußere.innere Klassen
9 Besondere Typen der Java SE
10 Generics<T>
11 Lambda-Ausdrücke und funktionale Programmierung
12 Architektur, Design und angewandte Objektorientierung
13 Die Klassenbibliothek
14 Einführung in die nebenläufige Programmierung
15 Einführung in Datenstrukturen und Algorithmen
16 Einführung in grafische Oberflächen
17 Einführung in Dateien und Datenströme
18 Einführung ins Datenbankmanagement mit JDBC
19 Einführung in <XML>
20 Testen mit JUnit
21 Bits und Bytes und Mathematisches
22 Die Werkzeuge des JDK
A Java SE Paketübersicht
Stichwortverzeichnis

Download:
- Beispielprogramme, ca. 20,0 MB
- Übungsaufgaben, ca. 1,8 MB
- Musterlösungen, ca. 0,8 MB

Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Java ist auch eine Insel von Christian Ullenbloom
Das umfassende Handbuch
Buch: Java ist auch eine Insel

Java ist auch eine Insel
Rheinwerk Computing
1306 Seiten, gebunden, 11. Auflage
49,90 Euro, ISBN 978-3-8362-2873-2
Pfeil 13 Die Klassenbibliothek
Pfeil 13.1 Die Java-Klassenphilosophie
Pfeil 13.1.1 Übersicht über die Pakete der Standardbibliothek
Pfeil 13.1.2 Compact-Profile
Pfeil 13.2 Sprachen der Länder
Pfeil 13.2.1 Sprachen und Regionen über Locale-Objekte
Pfeil 13.3 Die Klasse Date
Pfeil 13.3.1 Objekte erzeugen und Methoden nutzen
Pfeil 13.3.2 Date-Objekte sind nicht immutable
Pfeil 13.4 Calendar und GregorianCalendar
Pfeil 13.4.1 Die abstrakte Klasse Calendar
Pfeil 13.4.2 Calendar nach Date und Millisekunden fragen
Pfeil 13.4.3 Abfragen und Setzen von Datumselementen über Feldbezeichner
Pfeil 13.4.4 Kalender-Exemplare bauen über den Calendar.Builder
Pfeil 13.4.5 Der gregorianische Kalender
Pfeil 13.4.6 Date-Time-API in Java 8
Pfeil 13.5 Klassenlader (Class Loader) und Klassenpfad
Pfeil 13.5.1 Woher die kleinen Klassen kommen
Pfeil 13.5.2 Setzen des Klassenpfades
Pfeil 13.5.3 Die wichtigsten drei Typen von Klassenladern
Pfeil 13.6 Die Utility-Klasse System und Properties
Pfeil 13.6.1 Systemeigenschaften der Java-Umgebung
Pfeil 13.6.2 line.separator
Pfeil 13.6.3 Eigene Properties von der Konsole aus setzen *
Pfeil 13.6.4 Umgebungsvariablen des Betriebssystems *
Pfeil 13.6.5 Einfache Zeitmessung und Profiling *
Pfeil 13.7 Einfache Benutzereingaben
Pfeil 13.7.1 Grafischer Eingabedialog über JOptionPane
Pfeil 13.7.2 Geschützte Passwort-Eingaben mit der Klasse Console *
Pfeil 13.8 Ausführen externer Programme *
Pfeil 13.8.1 ProcessBuilder und Prozesskontrolle mit Process
Pfeil 13.8.2 Einen Browser, E-Mail-Client oder Editor aufrufen
Pfeil 13.9 Benutzereinstellungen *
Pfeil 13.9.1 Benutzereinstellungen mit der Preferences-API
Pfeil 13.9.2 Einträge einfügen, auslesen und löschen
Pfeil 13.9.3 Auslesen der Daten und Schreiben in einem anderen Format
Pfeil 13.9.4 Auf Ereignisse horchen
Pfeil 13.9.5 Zugriff auf die gesamte Windows-Registry
Pfeil 13.10 Zum Weiterlesen
 
Zum Seitenanfang

13Die Klassenbibliothek Zur vorigen ÜberschriftZur nächsten Überschrift

»Was wir brauchen, sind ein paar verrückte Leute;
seht euch an, wohin uns die Normalen gebracht haben.«
– George Bernard Shaw (1856–1950)

 
Zum Seitenanfang

13.1Die Java-Klassenphilosophie Zur vorigen ÜberschriftZur nächsten Überschrift

Eine Programmiersprache besteht nicht nur aus einer Grammatik, sondern, wie im Fall von Java, auch aus einer Programmierbibliothek. Eine plattformunabhängige Sprache – so wie sich viele C oder C++ vorstellen – ist nicht wirklich plattformunabhängig, wenn auf jedem Rechner andere Funktionen und Programmiermodelle eingesetzt werden. Genau dies ist der Schwachpunkt von C(++). Die Algorithmen, die kaum vom Betriebssystem abhängig sind, lassen sich überall gleich anwenden, doch spätestens bei Ein-/Ausgabe oder grafischen Oberflächen ist Schluss. Die Java-Bibliothek dagegen versucht, von den plattformspezifischen Eigenschaften zu abstrahieren, und die Entwickler haben sich große Mühe gegeben, alle wichtigen Methoden in wohlgeformten objektorientierten Klassen und Paketen unterzubringen. Diese decken insbesondere die zentralen Bereiche Datenstrukturen, Ein- und Ausgabe, Grafik- und Netzwerkprogrammierung ab.

 
Zum Seitenanfang

13.1.1Übersicht über die Pakete der Standardbibliothek Zur vorigen ÜberschriftZur nächsten Überschrift

Die Java 8-Klassenbibliothek bietet genau 217 Pakete.[ 209 ] Die wichtigsten davon fasst Tabelle 13.1 zusammen:

Paket

Beschreibung

java.awt

Das Paket AWT (Abstract Windowing Toolkit) bietet Klassen zur Grafikausgabe und zur Nutzung von grafischen Bedienoberflächen.

java.awt.event

Schnittstellen für die verschiedenen Ereignisse unter grafischen Oberflächen

java.io

java.nio

Möglichkeiten zur Ein- und Ausgabe. Dateien werden als Objekte repräsentiert. Datenströme erlauben den sequenziellen Zugriff auf die Dateiinhalte.

java.lang

Ein Paket, das automatisch eingebunden ist. Enthält unverzichtbare Klassen wie String-, Thread- oder Wrapper-Klassen.

java.net

Kommunikation über Netzwerke. Bietet Klassen zum Aufbau von Client- und Serversystemen, die sich über TCP bzw. IP mit dem Internet verbinden lassen.

java.text

Unterstützung für internationalisierte Programme. Bietet Klassen zur Behandlung von Text und zur Formatierung von Datumswerten und Zahlen.

java.util

Bietet Typen für Datenstrukturen, Raum und Zeit sowie für Teile der Internationalisierung sowie für Zufallszahlen.

javax.swing

Swing-Komponenten für grafische Oberflächen. Das Paket besitzt diverse Unterpakete.

Tabelle 13.1Wichtige Pakete in der Java SE

Eine vollständige Übersicht aller Pakete gibt Anhang A, »Java SE Paketübersicht«. Als Entwickler ist es unumgänglich für die Details die Java-API-Dokumentation unter http://docs.oracle.com/javase/8/docs/api/ zu studieren.

Offizielle Schnittstelle (java- und javax-Pakete)

Das, was die Java-Dokumentation aufführt, bildet den erlaubten Zugang zum JDK. Die Typen sind für die Ewigkeit ausgelegt, sodass Entwickler darauf zählen können, auch noch in 100 Jahren ihre Java-Programme ausführen zu können. Doch wer definiert die API? Im Kern sind es vier Quellen:

  • Oracle-Entwickler setzen neue Pakete und Typen in die API.

  • Der Java Community Process (JCP) beschließt eine neue API. Dann ist es nicht nur Oracle allein, sondern eine Gruppe, die eine neue API erarbeitet und die Schnittstellen definiert.

  • Die Object Management Group (OMG) definiert eine API für CORBA.

  • Das World Wide Web Consortium (W3C) gibt eine API etwa für XML-DOM vor.

Die Merkhilfe ist, dass alles, was mit java oder javax beginnt, eine erlaubte API darstellt und alles andere zu nicht portablen Java-Programmen führen kann. Es gibt weiterhin Klassen, die unterstützt werden, aber nicht Teil der offiziellen API sind. Dazu zählen etwa diverse Swing-Klassen für das Aussehen der Oberfläche.

[+]Hinweis

Die Laufzeitumgebung von Oracle liefert noch über 3.000 Klassendateien in den Paketen sun und sunw aus. Diese internen Klassen sind nicht offiziell dokumentiert,[ 210 ] aber zum Teil sehr leistungsfähig und erlauben selbst direkten Speicherzugriff oder können Objekte ohne Standard-Konstruktor erzeugen:

Listing 13.1com/tutego/insel/sun/UnsafeInstance.java, Ausschnitt

Field field = Unsafe.class.getDeclaredField( "theUnsafe" );
field.setAccessible( true );
sun.misc.Unsafe unsafe = (sun.misc.Unsafe) field.get( null );
File f = (File) unsafe.allocateInstance( File.class );
System.out.println( f.getPath() ); // null

File hat keinen Standard-Konstruktor, nicht einmal einen privaten. Diese Art der Objekterzeugung kann bei der Deserialisierung hilfreich sein.

Standard Extension API (javax-Pakete)

Einige der Java-Pakete beginnen mit javax. Dies sind ursprünglich Erweiterungspakete (Extensions), die die Kernklassen ergänzen sollten. Im Laufe der Zeit sind jedoch viele der früher zusätzlich einzubindenden Pakete in die Standarddistribution gewandert, sodass heute ein recht großer Anteil mit javax beginnt, aber keine Erweiterungen mehr darstellt, die zusätzlich installiert werden müssen. Sun wollte damals die Pakete nicht umbenennen, um so eine Migration nicht zu erschweren. Fällt heute im Quellcode ein Paketname mit javax auf, ist es daher nicht mehr so einfach, zu entscheiden, ob eine externe Quelle mit eingebunden werden muss bzw. ab welcher Java-Version das Paket Teil der Distribution ist. Echte externe Pakete sind unter anderem:

  • Enterprise/Server API mit den Enterprise JavaBeans, Servlets und JavaServer Faces

  • Java Persistence API (JPA) zum dauerhaften Abbilden von Objekten auf (in der Regel) relationale Datenbanken

  • Java Communications API für serielle und parallele Schnittstellen

  • Java Telephony API

  • Sprachein-/-ausgabe mit der Java Speech API

  • JavaSpaces für gemeinsamen Speicher unterschiedlicher Laufzeitumgebungen

  • JXTA zum Aufbau von P2P-Netzwerken

jdk.Exported *

Im Endeffekt haben Entwickler es mit Folgendem zu tun:

  1. der offiziellen Java-API

  2. der API aus JSR-Erweiterungen, wie der Java-Enterprise-API

  3. nicht offiziellen Bibliotheken, wie quelloffenen Lösungen, etwa zum Zugriff auf PDF-Dateien oder Bankautomaten

Allerdings gibt es noch weitere Typen, die nicht im java- bzw. javax-Paket liegen, die von jeder Java SE-Implementierung unterstützt werden müssen. Dazu zählen:

  • HTTP Server API (com.sun.net.httpserver)

  • Java Debug Interface (com.sun.jdi)

  • Attach API (com.sun.tools.attach)

  • SCTP API (com.sun.nio.sctp)

  • Management Extensions (com.sun.management)

  • JConsole Plugin API (com.sun.tools.jconsole)

  • ein paar Typen aus dem Sicherheitspaket, com.sun.security.auth und com.sun.security.jgss

Um zugängliche öffentliche bzw. protected Typen und Eigenschaften zu markieren, tragen sie ab Java 8 eine spezielle Annotation @jdk.Exported – an dem Paket jdk lässt sich schon ablesen, dass die Annotation selbst schon sehr speziell ist, und auch nicht zur Standardbibliothek gehört. Alternative Java SE-Implementierungen müssen diese Typen also bereitstellen, da jedoch Oracle mit dem JDK (bzw. dem OpenJDK) so präsent ist, ist diese Markierung eher etwas für die Plattformentwickler, weniger für die normalen Entwickler.

 
Zum Seitenanfang

13.1.2Compact-Profile Zur vorigen ÜberschriftZur nächsten Überschrift

Nicht jedes Java-Programm braucht den vollen Satz von 4.000 Typen, sondern oftmals reicht eine kleine Teilmenge. Eine Teilmenge der Java-Bibliothek wiederum ermöglicht es, kleinere Laufzeitumgebungen zu bauen, was es erlaubt, Java auch für Geräte mit weniger Ressourcen einzusetzen. Eine kleine Java-Version für Embedded-Systeme braucht kein CORBA, AWT oder JavaFX und kann so viel kleiner als das Standard-JRE sein.

In Java 8[ 211 ] wurde die Bibliothek in vier Gruppen eingeteilt, auf der einen Seite stehen drei kompakte aufsteigende Teilmengen der Standardbibliothek, genannt Compact-Profile, und auf der anderen Seite das vollständige System. Das Profil compact1 ist das kleinste, compact2 enthält compact1, compact3 enthält compact2 und das Gesamt-JRE compact3.

Welche Typen zu welchem Profil gehören, dokumentiert die Java-API auf der Startseite, und sein Profil gibt jeder Typ in der Javadoc an; die grobe Einteilung ist folgende:

Profil

Größe

Pakete

compact1

10 MiB

java.io, java.math, java.net, java.nio, java.security, java.time, java.util (inklusive Stream-API), javax.crypto, javax.script, javax.security

compact2

17 MiB

java.sql, java.rmi, javax.rmi, javax.transaction, javax.xml, org.xml, org.w3c

compact3

24 MiB

java.lang.instrument, java.lang.management, java.util.prefs, java.lang.model, javax.management, javax.naming, javax.sql.rowset, javax.tools, javax.xml.crypto, org.ieft.jgss, Kerberos, SASL

JRE/JDK

140 MiB

Alles weitere: java.beans, AWT, Swing, JavaFX, CORBA, java.awt. print, Sound, SOAP, Web-Service, …

Tabelle 13.2Inhalt der verschiedenen Profile mit Speicherbedarf[ 212 ]

Weiterhin ist die Anzahl verschiedener Provider minimiert worden, es gilt zum Beispiel nur Englisch als verpflichtende Sprache.

Werkzeug-Unterstützung für Profile

Die Werkzeuge javac, javadoc und jdeps aus dem JDK sind für die Profile aktualisiert worden, etwa dahingehend, dass sie prüfen können, ob ein Typ/eine Eigenschaft zum Profil gehört oder nicht. Der Schalter –profile gibt dabei das gewünschte Profil an.

[zB]Beispiel

Versuche die Klasse T mit der Deklaration class T extends java.awt.Point {} mit dem Profile compact3 zu übersetzen:

$ javac -profile compact3 T.java
T.java:2: error: Point is not available in profile 'compact3'
class T extends java.awt.Point { }
^
1 error

Obwohl Point eine nützliche Klasse ist und keine plattformspezifischen Eigenschaften hat, ist das gesamte Paket java.awt gesperrt und kein Teil vom Compact-Profile.

 


Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
<< zurück
 Zum Katalog
Zum Katalog: Java ist auch eine Insel Java ist auch eine Insel
Jetzt bestellen

 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Java SE 8 Standard-Bibliothek
Java SE 8 Standard-Bibliothek


Zum Katalog: Professionell entwickeln mit Java EE 7
Professionell entwickeln mit Java EE 7


Zum Katalog: Schrödinger programmiert Java
Schrödinger programmiert Java


Zum Katalog: Einführung in Java
Einführung in Java


Zum Katalog: Programmieren lernen mit Java
Programmieren lernen mit Java


Zum Katalog: Apps entwickeln für Android 5
Apps entwickeln für Android 5


Zum Katalog: Apps entwickeln mit Android Studio
Apps entwickeln mit Android Studio


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo

 
 


Copyright © Rheinwerk Verlag GmbH 2016
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.

 
Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de