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 Komponenten, JavaBeans und Module
14 Die Klassenbibliothek
15 Einführung in die nebenläufige Programmierung
16 Einführung in Datenstrukturen und Algorithmen
17 Einführung in grafische Oberflächen
18 Einführung in Dateien und Datenströme
19 Einführung ins Datenbankmanagement mit JDBC
20 Einführung in <XML>
21 Testen mit JUnit
22 Bits und Bytes und Mathematisches
23 Die Werkzeuge des JDK
A Java SE-Paketübersicht
Stichwortverzeichnis


Download:

- Beispielprogramme, ca. 35,4 MB


Buch bestellen
Ihre Meinung?



Spacer
<< zurück
Java ist auch eine Insel von Christian Ullenboom

Einführung, Ausbildung, Praxis
Buch: Java ist auch eine Insel


Java ist auch eine Insel

Pfeil 3 Klassen und Objekte
Pfeil 3.1 Objektorientierte Programmierung (OOP)
Pfeil 3.1.1 Warum überhaupt OOP?
Pfeil 3.1.2 Denk ich an Java, denk ich an Wiederverwendbarkeit
Pfeil 3.2 Eigenschaften einer Klasse
Pfeil 3.2.1 Klassenarbeit mit Point
Pfeil 3.3 Natürlich modellieren mit der UML (Unified Modeling Language) *
Pfeil 3.3.1 Hintergrund und Geschichte der UML
Pfeil 3.3.2 Wichtige Diagrammtypen der UML
Pfeil 3.3.3 UML-Werkzeuge
Pfeil 3.4 Neue Objekte erzeugen
Pfeil 3.4.1 Ein Exemplar einer Klasse mit dem Schlüsselwort new anlegen
Pfeil 3.4.2 Der Zusammenhang von new, Heap und Garbage-Collector
Pfeil 3.4.3 Deklarieren von Referenzvariablen
Pfeil 3.4.4 Jetzt mach mal ’nen Punkt: Zugriff auf Objektattribute und -methoden
Pfeil 3.4.5 Überblick über Point-Methoden
Pfeil 3.4.6 Konstruktoren nutzen
Pfeil 3.5 ZZZZZnake
Pfeil 3.6 Pakete schnüren, Imports und Kompilationseinheiten
Pfeil 3.6.1 Java-Pakete
Pfeil 3.6.2 Pakete der Standardbibliothek
Pfeil 3.6.3 Volle Qualifizierung und import-Deklaration
Pfeil 3.6.4 Mit import p1.p2.* alle Typen eines Pakets erreichen
Pfeil 3.6.5 Hierarchische Strukturen über Pakete
Pfeil 3.6.6 Die package-Deklaration
Pfeil 3.6.7 Unbenanntes Paket (default package)
Pfeil 3.6.8 Klassen mit gleichen Namen in unterschiedlichen Paketen *
Pfeil 3.6.9 Kompilationseinheit (Compilation Unit)
Pfeil 3.6.10 Statischer Import *
Pfeil 3.7 Mit Referenzen arbeiten, Identität und Gleichheit (Gleichwertigkeit)
Pfeil 3.7.1 null-Referenz und die Frage der Philosophie
Pfeil 3.7.2 Alles auf null? Referenzen testen
Pfeil 3.7.3 Zuweisungen bei Referenzen
Pfeil 3.7.4 Methoden mit Referenztypen als Parametern
Pfeil 3.7.5 Identität von Objekten
Pfeil 3.7.6 Gleichheit (Gleichwertigkeit) und die Methode equals(…)
Pfeil 3.8 Arrays
Pfeil 3.8.1 Grundbestandteile
Pfeil 3.8.2 Deklaration von Arrays
Pfeil 3.8.3 Arrays mit Inhalt
Pfeil 3.8.4 Die Länge eines Arrays über das Attribut length auslesen
Pfeil 3.8.5 Zugriff auf die Elemente über den Index
Pfeil 3.8.6 Array-Objekte mit new erzeugen
Pfeil 3.8.7 Typische Array-Fehler
Pfeil 3.8.8 Arrays als Methodenparameter
Pfeil 3.8.9 Vorinitialisierte Arrays
Pfeil 3.8.10 Die erweiterte for-Schleife
Pfeil 3.8.11 Arrays mit nichtprimitiven Elementen
Pfeil 3.8.12 Methode mit variabler Argumentanzahl (Vararg)
Pfeil 3.8.13 Mehrdimensionale Arrays *
Pfeil 3.8.14 Nichtrechteckige Arrays *
Pfeil 3.8.15 Die Wahrheit über die Array-Initialisierung *
Pfeil 3.8.16 Mehrere Rückgabewerte *
Pfeil 3.8.17 Klonen kann sich lohnen – Arrays vermehren *
Pfeil 3.8.18 Array-Inhalte kopieren *
Pfeil 3.8.19 Die Klasse Arrays zum Vergleichen, Füllen, Suchen, Sortieren nutzen
Pfeil 3.8.20 Eine lange Schlange
Pfeil 3.9 Der Einstiegspunkt für das Laufzeitsystem: main(…)
Pfeil 3.9.1 Korrekte Deklaration der Startmethode
Pfeil 3.9.2 Kommandozeilenargumente verarbeiten
Pfeil 3.9.3 Der Rückgabetyp von main(…) und System.exit(int) *
Pfeil 3.10 Grundlagen von Annotationen und Generics
Pfeil 3.10.1 Generics
Pfeil 3.10.2 Annotationen
Pfeil 3.10.3 Annotationstypen aus java.lang
Pfeil 3.10.4 @Deprecated
Pfeil 3.10.5 @SuppressWarnings
Pfeil 3.11 Zum Weiterlesen
 

Zum Seitenanfang

3.10Grundlagen von Annotationen und Generics Zur vorigen ÜberschriftZur nächsten Überschrift

Bis zu diesem Punkt haben wir uns mit den Grundlagen der Objektorientierung beschäftigt und wissen, wie Objekte aufgebaut und Eigenschaften genutzt werden. Mit zwei weiteren Eigenschaften der Programmiersprache wollen wir uns kurz beschäftigen: Annotationen und Generics. Beiden Punkten nähern wir uns aus der Nutzerperspektive und nicht aus der Sicht eines API-Designers, der neue Annotationen zur Verfügung stellen muss oder neue Methoden und Klassen deklariert und diese generisch parametrisierbar ausstatten möchte.

 

Zum Seitenanfang

3.10.1Generics Zur vorigen ÜberschriftZur nächsten Überschrift

Java ist eine typisierte Programmiersprache, was bedeutet, dass jede Variable und jeder Ausdruck einen Typ hat, den der Compiler kennt und der sich zur Laufzeit nicht ändert. Eine Zählvariable ist zum Beispiel vom Typ int, ein Abstand zwischen zwei Punkten ist vom Typ double, und ein Koordinatenpaar ist vom Typ Point. Allerdings gibt es bei der Typisierung Lücken. Nehmen wir etwa eine Liste von Punkten:

List list;

Zwar ist die Variable list nun mit List typisiert, und das ist besser als nichts, jedoch bleibt unklar, was die Liste eigentlich genau für Objekte speichert. Sind es Punkte, Einhörner oder rostige Fähren? Es wäre sinnvoll, nicht nur die Liste selbst als Typ zu haben, sondern sozusagen rekursiv in die Liste reinzugehen und genau hinzuschauen, was die Liste eigentlich referenziert. Genau das ist die Aufgabe von Generics. Die Datenstruktur wünscht sich eine Typangabe, was sie genau speichert. Dieser Typ erscheint in spitzen Klammern hinter dem eigentlichen »Haupttyp«.

List<Point> list;

Mit Generics haben API-Designer ein Werkzeug, Typen noch genauer vorzuschreiben. Die Entwickler des Typs List können so vom Nutzer fordern, den Elementtyp anzugeben. So können Entwickler dem Compiler genauer sagen, was sie für Typen verwenden, und es dem Compiler ermöglichen, genauere Tests zu machen. Es ist erlaubt und möglich, diesen »Nebentyp« nicht anzugeben, doch das führt zu einer Compilerwarnung und ist nicht empfehlenswert: Je genauer Typangaben sind, desto besser ist das für alle.

Vereinzelt kommen in den nächsten Kapiteln generische Typen vor, etwa Comparable (hilft, Objekte zu vergleichen). An dieser Stelle reicht es, zu verstehen, dass wir als Nutzer einen Typ in spitze Klammen eintragen müssen. Mit Generics selbst beschäftigen wir uns in Kapitel 10, »Generics<T>«, genauer.

 

Zum Seitenanfang

3.10.2Annotationen Zur vorigen ÜberschriftZur nächsten Überschrift

In diesem Kapitel haben wir schon unterschiedliche Modifizierer kennengelernt. Darunter waren zum Beispiel static oder public. Das Besondere an diesen Modifizierern ist, dass sie die Programmsteuerung nicht beeinflussen, aber dennoch wichtige Zusatzinformationen darstellen, also Semantik einbringen. Diese Informationen nennen sich Metadaten. Die Modifizierer static, public sind Metadaten für den Compiler, doch mit etwas Fantasie lassen sich auch Metadaten vorstellen, die nicht vom Compiler, sondern von einer Java-Bibliothek ausgewertet werden. So wie public zum Beispiel dem Compiler sagt, dass ein Element für jeden sichtbar ist, kann auf der anderen Seite auch zum Beispiel ein besonderes Metadatum an einem Element hängen, um auszudrücken, dass es nur bestimmte Wertebereiche annehmen kann.

Java bietet eine eingebaute Fähigkeit für Metadaten: Annotationen. Die Annotationen lassen sich wie benutzerdefinierte Modifizierer erklären. Wir können zwar keine neue Sichtbarkeit erfinden, aber dennoch dem Compiler, bestimmten Werkzeugen oder der Laufzeitumgebung durch die Annotationen Zusatzinformationen geben. Dazu ein paar Beispiele für Annotationen und Anwendungsfälle:

Annotation

Erklärung

@WebService class Calculator {

@WebMethod int add( int x, int y ) ...

Definiert einen Web-Service mit einer Web-Service-Methode.

@Override public String toString() ...

Überschreibt eine Methode der Oberklasse.

@XmlRoot class Person { ...

Ermöglicht die Abbildung eines Objekts auf eine XML-Datei.

Tabelle 3.7Beispiele für Annotationen und Anwendungsfälle

Die Tabelle soll lediglich einen Überblick geben; genaue Anwendungen und Beispiele zu @Override folgen in Kapitel 6, »Objektorientierte Beziehungsfragen«.

Schreibweise für Annotationen

Annotationen werden wie zusätzliche Modifizierer gebraucht, doch unterscheiden sie sich durch ein vorangestelltes @-Zeichen (das @-Zeichen, at, ist auch eine gute Abkürzung für Annotation Type). Daher ist auch die Reihenfolge egal, sodass es zum Beispiel

  • @Override public String toString() oder

  • public @Override String toString()

lauten kann. Es ist aber üblich, die Annotationen an den Anfang zu setzen. Und wenn Annotationen an Typen gesetzt werden, bekommen sie in der Regel eine eigene Zeile.

Die Begriffe »Annotation« und »Annotationstyp«

Die Annotationstypen sind die Deklarationen, wie etwa ein Klassentyp. Werden sie an ein Element gehängt, ist es eine konkrete Annotation. Während also Override selbst der Annotationstyp ist, ist @Override vor toString() die konkrete Annotation.

Orte für Annotationen

In unserem Beispiel werden Annotationen an Typ- und Methodendeklarationen angewendet, doch die Möglichkeiten gehen weiter. Annotationen lassen sich an allen Deklarationen und bei Typnutzungen setzen:

Deklarationen von

Typnutzung

Typen: Klassen, Schnittstellen, Aufzählungen, andere Annotationstypen

new

Eigenschaften: Konstruktoren, Methoden, Attributen

Typumwandlung

implements-Klausel

throws-Klausel bei Methoden

Tabelle 3.8Wo Annotationen möglich sind

Die Annotationen bei der Typnutzung nennen sich kurz Typ-Annotationen.

Java bringt einige Annotationstypen mit, doch die werden bisher ausschließlich für Deklarationen eingesetzt, wie das bekannte @Override. Vordefinierte Typ-Annotationen sind bisher in der Java SE nicht zu finden.

 

Zum Seitenanfang

3.10.3Annotationstypen aus java.lang Zur vorigen ÜberschriftZur nächsten Überschrift

Das Paket java.lang deklariert fünf Annotationstypen, wobei uns @Override ab Kapitel 5, »Eigene Klassen schreiben«, noch häufiger über den Weg laufen wird.

Annotationstyp

Wirkung

@Override

Die annotierte Methode überschreibt eine Methode aus der Oberklasse oder implementiert eine Methode einer Schnittstelle.

@Deprecated

Das markierte Element ist veraltet und sollte nicht mehr verwendet werden.

@SuppressWarnings

Unterdrückt bestimmte Compilerwarnungen.

@SafeVarargs

besondere Markierung für Methoden mit variabler Argumentzahl und generischem Argumenttyp

@FunctionalInterface

für Schnittstellen, die nur genau eine (abstrakte) Methode besitzen

Tabelle 3.9Annotationen aus dem Paket java.lang

Die fünf Annotationen haben vom Compiler bzw. Laufzeitsystem eine besondere Semantik. Java SE deklariert in anderen Paketen (wie dem java.lang.annotation- und javax.annotation-Paket) noch weitere Annotationstypen, doch die sind an dieser Stelle nicht relevant. Dazu kommen spezielle technologiespezifische Annotationstypen wie für die XML-Objekt-Abbildung oder Web-Service-Deklarationen.

 

Zum Seitenanfang

3.10.4@Deprecated Zur vorigen ÜberschriftZur nächsten Überschrift

Die Annotation @Deprecated übernimmt die gleiche Aufgabe wie das Javadoc-Tag @deprecated: Die markierten Elemente werden als veraltet markiert und drücken damit aus, dass der Entwickler Alternativen nutzen soll.

[zB]Beispiel

Die Methode fubar()[ 125 ](Im US-Militär-Slang steht das für: »Fucked up beyond any recognition« – »vollkommen ruiniert«. ) soll als veraltet markiert werden:

@Deprecated

public void fubar() { ... }

Ruft irgendein Programmstück fubar() auf, gibt der Compiler eine einfache Meldung aus.

Die Übersetzung mit dem Schalter -Xlint:deprecation liefert die genauen Warnungen; im Moment ist das mit -deprecation gleich.

Auch über ein Javadoc-Tag kann ein Element als veraltet markiert werden. Ein Unterschied bleibt: Das Javadoc-Tag kann nur von Javadoc (oder einem anderen Doclet) ausgewertet werden, während Annotationen auch andere Tools auswerten können.

Annotationen mit zusätzlichen Informationen

Die Annotationen @Override und @Deprecated gehören zur Klasse der Marker-Annotationen, weil keine zusätzlichen Angaben nötig (und erlaubt) sind. Zusätzlich gibt es die Single-Value-Annotation, die genau eine zusätzliche Information bekommt, und eine volle Annotation mit beliebigen Schlüssel-Wert-Paaren.

Schreibweise der Annotation

Funktion

@Annotationstyp

(Marker-)Annotation

@Annotationstyp( Wert )

Annotation mit genau einem Wert

@Annotationstyp( Schlüssel1=Wert1, Schlüssel2=Wert2, ... )

Annotation mit Schlüssel-Wert-Paaren

Tabelle 3.10Annotationen mit und ohne zusätzliche Informationen

Klammern sind bei einer Marker-Annotation optional.

 

Zum Seitenanfang

3.10.5@SuppressWarnings Zur vorigen ÜberschriftZur nächsten Überschrift

Die Annotation @SuppressWarnings steuert Compilerwarnungen. Unterschiedliche Werte bestimmen genauer, welche Hinweise unterdrückt werden. Nützlich ist die Annotation bei der Umstellung von Quellcode, der vor Java 5 entwickelt wurde, denn mit Java 5 zogen Generics ein, eine Möglichkeit, dem Compiler noch mehr Informationen über Typen zu geben. Die Java-API-Designer haben daraufhin die Deklaration der Datenstrukturen überarbeitet und Generics eingeführt, was dazu führt, dass vor Java 5 entwickelter Quellcode mit einem aktuellen Java-Compiler eine Vielzahl von Warnungen ausgibt. Nehmen wir folgenden Programmcode:

ArrayList list;

list = new ArrayList();

list.add( "SuppressWarnings" );

Eclipse zeigt die Meldungen direkt an, NetBeans dagegen standardmäßig nicht.

Warnungen in Eclipse

Abbildung 3.9Warnungen in Eclipse

Der Compiler javac meldet über die Kommandozeile recht unspezifisch:

Note: ABC.java uses unchecked or unsafe operations.

Note: Recompile with -Xlint:unchecked for details.

Mit dem gesetzten Schalter -Xlint heißt es dann genauer:

warning: [rawtypes] found raw type: ArrayList

ArrayList list1;

^

missing type arguments for generic class ArrayList<E>

where E is a type-variable:

E extends Object declared in class ArrayList



warning: [rawtypes] found raw type: ArrayList

list1 = new ArrayList();

^

missing type arguments for generic class ArrayList<E>

where E is a type-variable:

E extends Object declared in class ArrayList



warning: [unchecked] unchecked call to add(E) as a member of the raw type ArrayList

list1.add("SuppressWarnings");

^

where E is a type-variable:

E extends Object declared in class ArrayList

Zwei unterschiedliche Arten von Warnungen treten auf:

  • Da die Klasse ArrayList als generischer Typ deklariert ist, melden die ersten beiden Zeilen »found raw type: ArrayList« (javac) bzw. »ArrayList is a raw type. References to generic type ArrayList<E> should be parameterized« (Eclipse).

  • Die dritte Zeile nutzt mit add(…) eine Methode, die über Generics einen genaueren Typparameter bekommen könnte. Da wir keinen Typ angegeben haben, folgt die Warnung: »unchecked call to add(E) as a member of the raw type ArrayList« (javac) bzw. »Type safety: The method add(Object) belongs to the raw type ArrayList. References to generic type ArrayList<E> should be parameterized« (Eclipse).

Warnungen lassen sich über die Annotation @SuppressWarnings ausschalten. Als spezieller Modifizierer lässt sich die Annotation an der Variablendeklaration anbringen, an der Methodendeklaration oder an der Klassendeklaration. Die Reichweite ist aufsteigend. Wer bei altem Programmcode kurz und schmerzlos alle Warnungen abschalten möchte, der setzt ein @SuppressWarnings("all") an die Klassendeklaration.

[zB]Beispiel

Der Compiler soll keine Meldungen für die Klasse geben:

Listing 3.35SuppressAllWarnings.java

@SuppressWarnings( "all" )

public class SuppressAllWarnings {



public static void main( String[] args ) {

java.util.ArrayList list1 = new java.util.ArrayList();

list1.add( "SuppressWarnings" );



java.util.ArrayList list2 = new java.util.ArrayList();

}

}

Anstatt jede Warnung mit @SuppressWarnings("all") zu unterdrücken, ist es eine bessere Strategie, selektiv vorzugehen. Eclipse unterstützt uns mit einem Quick-Fix und schlägt für unser Beispiel Folgendes vor:

  • @SuppressWarnings("rawtypes") für ArrayList list und list = new ArrayList()

  • @SuppressWarnings("unchecked") für list.add("...")

Da zwei gleiche Modifizierer nicht erlaubt sind – und auch zweimal @SuppressWarnings nicht –, wird eine besondere Array-Schreibweise gewählt.

[zB]Beispiel

Der Compiler soll für die ungenerisch verwendete Liste und ihre Methoden keine Meldungen geben:

@SuppressWarnings( { "rawtypes", "unchecked" } )

public static void main( String[] args ) {

ArrayList list = new ArrayList();

list.add( "SuppressWarnings" );

}

Kurz kam bereits zur Sprache, dass die @SuppressWarnings-Annotation auch an der Variablendeklaration möglich ist. Für unser Beispiel hilft das allerdings wenig, wenn etwa bei der Deklaration der Liste alle Warnungen abgeschaltet werden:

@SuppressWarnings( "all" ) ArrayList list;

list = new ArrayList(); // Warnung: ArrayList is a raw type...

list.add( "SuppressWarnings" ); // Warnung: Type safety ...

Das @SuppressWarnings("all") gilt nur für die eine Deklaration ArrayList list und nicht für folgende Anweisungen, die etwas mit der list machen. Zur Verdeutlichung setzt das Beispiel die Annotation daher in die gleiche Zeile.

[»]Hinweis

Die Schreibweise @SuppressWarnings("xyz") ist nur eine Abkürzung von @SuppressWarnings({"xzy"}), und das wiederum ist nur eine Abkürzung von @SuppressWarnings(value= {"xzy"}).

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

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

@SuppressWarnings

Unterdrückt Meldungen für

deprecation

veraltete Elemente, wie new java.util.Date(2012-1970, 3, 3)

incomplete-switch

ausgelassene Aufzählungen in switch-case-Anweisungen

resource

ein nicht geschlossenes AutoCloseable, wie in new java.util. Scanner(System.in).nextLine()*

serial

eine serialisierbare Klasse, die keine Serialisierungs-ID besitzt**

unused

nicht benutzte Elemente, etwa nicht aufgerufene private Methoden

* AutoCloseable ist eine Schnittstelle, die Klassen implementieren, die über eine close()-Methode verfügen. Abschnitt 7.6.1, »try mit Ressourcen«, stellt diese Schnittstelle vor.

** Das Konzept der Serialisierung behandelt Kapitel 7 in »Java SE 8 Standard-Bibliothek«.

Tabelle 3.11Einige Werte von @SuppressWarnings

 


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 ist auch eine Insel

Java ist auch eine Insel




Zum Katalog: Java SE 9-Standard-Bibliothek

Java SE 9-Standard-Bibliothek




Zum Katalog: Professionell entwickeln mit Java EE 8

Professionell entwickeln mit Java EE 8




Zum Katalog: Entwurfsmuster

Entwurfsmuster




Zum Katalog: IT-Projektmanagement

IT-Projektmanagement




 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich

InfoInfo



 

 


Copyright © Rheinwerk Verlag GmbH 2017

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.

 

[Rheinwerk Computing]



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