Rheinwerk Computing < openbook >


 
Inhaltsverzeichnis
Materialien zum Buch
Vorwort
1 Java ist auch eine Sprache
2 Imperative Sprachkonzepte
3 Klassen und Objekte
4 Arrays und ihre Anwendungen
5 Der Umgang mit Zeichen und Zeichenketten
6 Eigene Klassen schreiben
7 Objektorientierte Beziehungsfragen
8 Schnittstellen, Aufzählungen, versiegelte Klassen, Records
9 Ausnahmen müssen sein
10 Geschachtelte Typen
11 Besondere Typen der Java SE
12 Generics<T>
13 Lambda-Ausdrücke und funktionale Programmierung
14 Architektur, Design und angewandte Objektorientierung
15 Java Platform Module System
16 Die Klassenbibliothek
17 Einführung in die nebenläufige Programmierung
18 Einführung in Datenstrukturen und Algorithmen
19 Einführung in grafische Oberflächen
20 Einführung in Dateien und Datenströme
21 Einführung ins Datenbankmanagement mit JDBC
22 Bits und Bytes, Mathematisches und Geld
23 Testen mit JUnit
24 Die Werkzeuge des JDK
A Java SE-Module und Paketübersicht
Stichwortverzeichnis


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 24 Die Werkzeuge des JDK
Pfeil 24.1 Übersicht
Pfeil 24.1.1 Aufbau und gemeinsame Schalter
Pfeil 24.2 Java-Quellen übersetzen
Pfeil 24.2.1 Der Java-Compiler des JDK
Pfeil 24.2.2 Alternative Compiler
Pfeil 24.2.3 Native Compiler
Pfeil 24.3 Die Java-Laufzeitumgebung
Pfeil 24.3.1 Schalter der JVM
Pfeil 24.3.2 Der Unterschied zwischen java.exe und javaw.exe
Pfeil 24.4 Dokumentationskommentare mit Javadoc
Pfeil 24.4.1 Einen Dokumentationskommentar setzen
Pfeil 24.4.2 Mit dem Werkzeug javadoc eine Dokumentation erstellen
Pfeil 24.4.3 HTML-Tags in Dokumentationskommentaren *
Pfeil 24.4.4 Generierte Dateien
Pfeil 24.4.5 Dokumentationskommentare im Überblick *
Pfeil 24.4.6 Javadoc und Doclets *
Pfeil 24.4.7 Veraltete (deprecated) Typen und Eigenschaften
Pfeil 24.4.8 Javadoc-Überprüfung mit DocLint
Pfeil 24.5 Das Archivformat JAR
Pfeil 24.5.1 Das Dienstprogramm jar benutzen
Pfeil 24.5.2 Das Manifest
Pfeil 24.5.3 Applikationen in JAR-Archiven starten
Pfeil 24.6 jlink: der Java Linker
Pfeil 24.7 Zum Weiterlesen
 

Zum Seitenanfang

24.4    Dokumentationskommentare mit Javadoc Zur vorigen ÜberschriftZur nächsten Überschrift

Die Dokumentation von Softwaresystemen ist ein wichtiger, aber oft vernachlässigter Teil der Softwareentwicklung. Leider, denn Software wird im Allgemeinen öfter gelesen als geschrieben. Während des Entwicklungsprozesses müssen die Entwickler Zeit in Beschreibungen der einzelnen Komponenten investieren, besonders dann, wenn weitere Entwickler diese Komponenten in einer öffentlichen Bibliothek anderen Entwicklern zur Wiederverwendung zur Verfügung stellen. Um die Klassen, Schnittstellen, Aufzählungen und Methoden sowie Klassen-/Objektvariablen gut zu verstehen, müssen sie sorgfältig beschrieben werden. Wichtig bei der Beschreibung sind der Typname, der Methodenname, die Art und die Anzahl der Parameter, die Wirkung der Methoden und das Laufzeitverhalten. Da das Erstellen einer externen Dokumentation (also einer Beschreibung außerhalb der Quellcodedatei) fehlerträchtig und deshalb nicht gerade motivierend für die Beschreibung ist, werden spezielle Dokumentationskommentare in den Java-Quelltext eingeführt. Ein spezielles Programm generiert aus den Kommentaren Beschreibungsdateien (im Allgemeinen HTML) mit den gewünschten Informationen.[ 287 ](Die Idee ist nicht neu. In den 1980er-Jahren verwendete Donald E. Knuth das WEB-System zur Dokumentation von TeX. Das Programm wurde mit den Hilfsprogrammen weave und tangle in ein Pascal-Programm und eine TeX-Datei umgewandelt. )

 

Zum Seitenanfang

24.4.1    Einen Dokumentationskommentar setzen Zur vorigen ÜberschriftZur nächsten Überschrift

In einer besonders ausgezeichneten Kommentarumgebung werden die Dokumentationskommentare (Doc Comments) eingesetzt. Die Kommentarumgebung erweitert einen Blockkommentar und ist vor allen Typen (Klassen, Schnittstellen, Aufzählungen) sowie Methoden und Variablen üblich. Im folgenden Beispiel gibt Javadoc Kommentare für die Klasse, für Klassen-/Objektvariablen und Methoden an:

Listing 24.1     com/tutego/insel/javadoc/Room.java

package com.tutego.insel.javadoc;



/**

* This class models a room with a given number of players.

*/

public class Room {



/** Number of players in a room. */

private int numberOfPersons;



/**

* A person enters the room.

* Increments the number of persons.

*/

public void enterPerson() {

numberOfPersons++;

}



/**

* A person leaves the room.

* Decrements the number of persons.

*/

public void leavePerson() {

if ( numberOfPersons > 0 )

numberOfPersons--;

}



/**

* Gets the number of persons in this room.

* This is always greater than or equal to 0.

*

* @return Number of persons.

*/

public int getNumberOfPersons() {

return numberOfPersons;

}

}

Kommentar

Beschreibung

Beispiel

@param

Beschreibung der Parameter

@param x coordinate.

@see

Verweis auf ein anderes Paket, einen anderen Typ, eine andere Methode oder Eigenschaft

@see java.util.Date

@see java.lang.String#length()

@version

Version

@version 1.12

@author

Schöpfer

@author Christian Ullenboom

@return

Rückgabewert einer Methode

@return Number of elements

@exception/@throws

Ausnahmen, die ausgelöst werden können

@exception NumberFormatException

{@link Verweis}

eingebauter Verweis im Text im Code-Font; Parameter wie bei @see

{@link java.lang.Thread}

{@linkplain Verweis}

wie {@link}, nur im normalen Font

{@linkplain java.lang.Thread}

{@code Code}

Quellcode im Code-Schriftsatz – auch mit HTML-Sonderzeichen

{@code 1 ist < 2}

{@literal Literale}

Maskiert HTML-Sonderzeichen. Kein Code-Schriftsatz

{@literal 1 < 2 && 2 > 1}

Tabelle 24.4     Die wichtigsten Dokumentationskommentare im Überblick

[»]  Hinweis

Die Dokumentationskommentare sind so aufgebaut, dass der erste Satz in der Auflistung der Methoden und Zustandsvariablen erscheint und der Rest in der Detailansicht:

/**

* Ein kurzer Satz, der im Abschnitt "Method Summary" stehen wird
.

* Es folgt die ausführliche Beschreibung, die später im

* Abschnitt "Method Detail" erscheint, aber nicht in der Übersicht.

*/


public void foo() { }

Weil ein Dokumentationskommentar /** mit /* beginnt, ist er für den Compiler ein normaler Blockkommentar. Die Javadoc-Kommentare werden oft optisch aufgewertet, indem am Anfang jeder Zeile ein Sternchen steht – dieses ignoriert Javadoc.

 

Zum Seitenanfang

24.4.2    Mit dem Werkzeug javadoc eine Dokumentation erstellen Zur vorigen ÜberschriftZur nächsten Überschrift

Aus dem mit Kommentaren versehenen Quellcode generiert ein externes Programm die Zieldokumente. Das JDK liefert das Konsolenprogramm javadoc mit aus, dem als Parameter ein Dateiname der zu kommentierenden Klasse übergeben wird. Aus compilierten Dateien können natürlich keine Beschreibungsdateien erstellt werden. Wir starten javadoc in dem Verzeichnis, in dem auch die Klassen liegen, und erhalten unsere HTML-Dokumente.

[zB]  Beispiel

Möchten wir Dokumentationen für das gesamte Verzeichnis erstellen, so geben wir alle Dateien mit der Endung .java an:

$ javadoc *.java

Javadoc geht durch den Quelltext, parst die Deklarationen und zieht die Dokumentation heraus. Daraus generiert das Tool eine Beschreibung, die in der Regel eine HTML-Seite ist.

inline image  In Eclipse lässt sich eine Dokumentation mit Javadoc sehr einfach erstellen: Im Menü FileExport ist der Eintrag Javadoc zu wählen, und nach einigen Einstellungen ist die Dokumentation generiert.

[»]  Hinweis

Die Sichtbarkeit spielt bei Javadoc eine wichtige Rolle. Standardmäßig nimmt Javadoc nur öffentliche Dinge in die Dokumentation auf.

 

Zum Seitenanfang

24.4.3    HTML-Tags in Dokumentationskommentaren * Zur vorigen ÜberschriftZur nächsten Überschrift

In den Kommentaren können HTML-Tags verwendet werden, beispielsweise <b>bold</b> und <i>italic</i>, um Textattribute zu setzen. Sie werden direkt in die Dokumentation übernommen und müssen korrekt verschachtelt sein, damit die Ausgabe nicht falsch dargestellt wird. Die Überschriften-Tags <h1>..</h1> und <h2>..</h2> sollten jedoch nicht verwendet werden. Javadoc verwendet sie zur Gliederung der Ausgabe und weist ihnen Formatvorlagen zu.

inline image  In Eclipse zeigt die Ansicht javadoc in einer Vorschau das Ergebnis des Dokumentationskommentars an.

 

Zum Seitenanfang

24.4.4    Generierte Dateien Zur vorigen ÜberschriftZur nächsten Überschrift

Für jede öffentliche Klasse erstellt Javadoc eine HTML-Datei. Sind Klassen nichtöffentlich, muss ein Schalter angegeben werden. Die HTML-Dateien werden zusätzlich mit Querverweisen zu den anderen dokumentierten Klassen versehen. Daneben erstellt Javadoc weitere Dateien:

  • index-all.html liefert eine Übersicht aller Klassen, Schnittstellen, Ausnahmen, Methoden und Felder in einem Index.

  • overview-tree.html zeigt in einer Baumstruktur die Klassen an, damit die Vererbung deutlich sichtbar ist.

  • allclasses-frame.html listet alle dokumentierten Klassen in allen Unterpaketen auf.

  • deprecated-list.html bietet eine Liste der veralteten Methoden und Klassen.

  • serialized-form.html listet alle Klassen auf, die Serializable implementieren. Jede Klassen-/Objektvariable erscheint mit einer Beschreibung in einem Absatz.

  • help-doc.html zeigt eine Kurzbeschreibung von Javadoc.

  • index.html: Javadoc erzeugt eine Ansicht mit Frames. Das ist die Hauptdatei, die die rechte und linke Seite referenziert. Die linke Seite ist die Datei allclasses-frame.html. Rechts im Frame wird bei fehlender Paketbeschreibung die erste Klasse angezeigt.

  • stylesheet.css ist eine Formatvorlage für HTML-Dateien, in der sich unter anderem Farben und Schriftarten einstellen lassen, die dann alle HTML-Dateien nutzen.

  • packages.htm ist eine veraltete Datei. Sie verweist auf die neuen Dateien.

 

Zum Seitenanfang

24.4.5    Dokumentationskommentare im Überblick * Zur vorigen ÜberschriftZur nächsten Überschrift

Einige Javadoc-Kommentare müssen isoliert hinter der Hauptbeschreibung folgen, wie @param (Beschreibung der Parameter) oder @return (Beschreibung der Rückgaben). Sie heißen Block-Tags. Andere Tags können im Text auftauchen, wie {@link} zum Setzen eines Verweises auf einen anderen Typ oder eine andere Methode. Wir nennen sie Inline-Tags. Das Javadoc-Tool erkennt unter anderem die folgenden Tags:

  • Block-Tags: @apiNote, @author, @deprecated, @exception, @implNote, @implSpec, @param, @return, @see, @serial, @serialData, @serialField, @since, @throws, @version

  • Inline-Tags: {@code}, {@docRoot}, {@inheritDoc}, {@link}, {@linkplain},

    {@literal}, {@value}

Beispiele

Eine externe Zusatzquelle geben wir wie folgt an:

@see <a href="spec.html#section">Java Spec</a>.

So verweisen wir auf eine Methode, die mit der beschriebenen Methode verwandt ist:

@see String#equals(Object) equals

Von @see gibt es mehrere Varianten:

@see #field

@see #method(Type, Type,...)

@see #method(Type argname, Type argname,...)

@see #constructor(Type, Type,...)

@see #constructor(Type argname, Type argname,...)

@see Class#field

@see Class#method(Type, Type,...)

@see Class#method(Type argname, Type argname,...)

@see Class#constructor(Type, Type,...)

@see Class#constructor(Type argname, Type argname,...)

@see Class.NestedClass

@see Class

@see package.Class#field

@see package.Class#method(Type, Type,...)

@see package.Class#method(Type argname, Type argname,...)

@see package.Class#constructor(Type, Type,...)

@see package.Class#constructor(Type argname, Type argname,...)

@see package.Class.NestedClass

@see package.Class

@see package

Dokumentiere eine Variable. Gib einen Verweis auf eine Methode an:

/**

* The X-coordinate of the component.

*

* @see #getLocation()

*/


int x = 1263732;

Eine veraltete Methode, die auf eine Alternative zeigt:

/**

* @deprecated As of JDK 1.1,

* replaced by {@link #setBounds(int,int,int,int)}

*/

Anstatt HTML-Tags wie <tt> oder <code> für den Quellcode zu nutzen, ist {@code} viel einfacher:

/**

* Compares this current object with another object.

* Uses {@code equals()} an not {@code ==}.

*/

In den letzten Java-Versionen sind neue Tags hinzugekommen:

  • eingeführt in Java 9: @index, @hidden, @provides, @uses

  • eingeführt in Java 10: @summary

 

Zum Seitenanfang

24.4.6    Javadoc und Doclets * Zur vorigen ÜberschriftZur nächsten Überschrift

Die Ausgabe von Javadoc kann den eigenen Bedürfnissen angepasst werden, indem Doclets eingesetzt werden. Ein Doclet ist ein Java-Programm, das auf der Doclet-API aufbaut und die Ausgabedatei schreibt. Das Programm liest dabei wie das bekannte Javadoc-Tool die Quelldateien ein und erzeugt daraus ein beliebiges Ausgabeformat. Dieses Format kann selbst gewählt und implementiert werden. Wer also neben dem von JavaSoft beigefügten Standard-Doclet für HTML-Dateien Framemaker-Dateien (MIF) oder RTF-Dateien erzeugen möchte, der muss ein eigenes Doclet programmieren oder kann auf Doclets unterschiedlicher Hersteller zurückgreifen. Die (schon etwas angestaubte) Website http://www.doclet.com/ listet zum Beispiel Doclets auf, die DocBook generieren oder UML-Diagramme mit aufnehmen.

Daneben dient ein Doclet aber nicht nur der Schnittstellendokumentation. Ein Doclet kann auch aufzeigen, ob es zu jeder Methode eine Dokumentation gibt oder ob jeder Parameter und jeder Rückgabewert korrekt beschrieben wurde.

 

Zum Seitenanfang

24.4.7    Veraltete (deprecated) Typen und Eigenschaften Zur vorigen ÜberschriftZur nächsten Überschrift

Während der Entwicklungsphase einer Software ändern sich immer wieder Methodensignaturen, oder Methoden kommen hinzu oder fallen weg. Gründe gibt es viele:

  • Methoden können nicht wirklich plattformunabhängig programmiert werden, wurden aber einmal so angeboten. Nun soll die Methode nicht mehr unterstützt werden (ein Beispiel ist die Methode stop() eines Threads).

  • Die Java-Namenskonvention soll eingeführt werden, und ältere Methodennamen sollen nicht mehr verwendet werden. Das betrifft in erster Linie spezielle set*(…)/get*()-Methoden, die ab Version 1.1 zur Verfügung standen. So finden wir beim AWT viele Beispiele dafür. Nun heißt es zum Beispiel statt size() bei einer grafischen Komponente getSize().

  • Die Programmautoren hatten sich beim Methodennamen verschrieben. So hieß es in FontMetrics vorher getMaxDecent(), und nun heißt es getMaxDescent(), und im HTMLEditorKit wird insertAtBoundry(…) zu insertAtBoundary(…).

Es ist ungünstig, die Methoden jetzt einfach zu löschen, weil es dann zu Compilerfehlern kommt. Eine Lösung wäre daher, die Methode oder den Konstruktor als deprecated zu deklarieren. @deprecated ist ein eigener Dokumentationskommentar. Sein Einsatz sieht dann etwa folgendermaßen aus (Ausschnitt aus der Klasse java.util.Date):

Listing 24.2     java.util.Date.java, Ausschnitt

/**

* Sets the day of the month of this <tt>Date</tt> object to the

* specified value. ...

*

* @param date the day of the month value between 1-31.

* @see java.util.Calendar

*
@deprecated As of JDK version 1.1,

* replaced by <code>Calendar.set(Calendar.DAY_OF_MONTH, int date)</code>. */



public void setDate(int date) {

setField(Calendar.DATE, date);

}

Die Kennung @deprecated gibt an, dass die Methode bzw. der Konstruktor nicht mehr verwendet werden soll. Ein guter Kommentar zeigt auch Alternativen auf, sofern welche vorhanden sind. Die hier genannte Alternative ist die Methode set(…) aus dem Calendar-Objekt. Da der Kommentar in die generierte API-Dokumentation übernommen wird, erkennt der Entwickler, dass eine Methode veraltet ist.

[»]  Hinweis

Wenn eine Methode als »veraltet« markiert ist, heißt das nicht zwangsläufig, dass sie in der nächsten Java-Version gelöscht wird. Es ist nur ein Hinweis darauf, dass die Methode nicht mehr verwendet werden sollte und Unterstützung nicht mehr gegeben ist.

Compilermeldungen bei veralteten Methoden

Der Compiler gibt bei veralteten Methoden eine kleine Meldung auf dem Bildschirm aus. Testen wir das an der Klasse OldSack:

Listing 24.3     src/main/java/com/tutego/insel/tools/OldSack.java

package com.tutego.insel.tool;



//@SuppressWarnings( "deprecation" )

public class OldSack {

java.util.Date d = new java.util.Date( 62, 3, 4 );

}

Jetzt rufen wir ganz normal den Compiler auf:

$ javac com/tutego/insel/tool/OldSack.java

Note: com\tutego\insel\tool\OldSack.java uses or overrides a deprecated API.

Note: Recompile with -Xlint:deprecation for details.

Der Compiler sagt uns, dass der Schalter -deprecation weitere Hinweise gibt:

$ javac -deprecation com.tutego.insel.tool.OldSack.java

com\tutego\insel\tool\OldSack.java:5: warning: [deprecation] Date(int,int,int) in Date has been deprecated

java.util.Date d = new java.util.Date( 62, 3, 4 );

^

1 warning

Die Ausgabe gibt genau die Zeile mit der veralteten Anweisung an; Alternativen nennt der Compiler nicht. Allerdings ist schon interessant, dass der Compiler in die Dokumentationskommentare schaut. Eigentlich hat er mit den auskommentierten Blöcken ja nichts zu tun und überliest jeden Kommentar. Zur Auswertung der speziellen Kommentare gibt es schließlich das Extratool javadoc, das wiederum mit dem Java-Compiler nichts zu tun hat.

[»]  Hinweis

Auch Klassen lassen sich als deprecated markieren (siehe etwa java.io.LineNumberInputStream). Dies finden wir jedoch selten in der Java-Bibliothek, und bei eigenen Typen sollte es vermieden werden.

Die Annotation @Deprecated

Annotationen sind eine Art zusätzlicher Modifizierer. Die Annotation @Deprecated (großgeschrieben) ist vorgegeben und ermöglicht es ebenfalls, Dinge als veraltet zu kennzeichnen. Dazu wird die Annotation wie ein üblicher Modifizierer etwa für Methoden vor den Rückgabetyp gestellt. Oracle hat die oben genannte Methode setDate(…) mit dieser Annotation gekennzeichnet, wie der folgende Ausschnitt zeigt:

/** ...

* @deprecated As of JDK version 1.1,

* replaced by <code>Calendar.set(Calendar.DAY_OF_MONTH, int date)</code>.

*/


@Deprecated

public void setDate(int date) { ... }

Der Vorteil der Annotation @Deprecated gegenüber dem Javadoc-Tag besteht darin, dass die Annotation auch zur Laufzeit sichtbar ist. Liegt vor einem Methodenaufruf ein @Deprecated-Tester, so kann dieser die veralteten Methoden zur Laufzeit melden. Bei dem Javadoc-Tag übersetzt der Compiler das Programm in Bytecode und gibt zur Compilezeit eine Meldung aus, im Bytecode selbst gibt es aber keinen Hinweis.

In Java 9 wurde der Annotationstyp @Deprecated um zwei Eigenschaften erweitert:

  • String since() default "": Dokumentiert die Version, seit der das Element veraltet ist.

  • boolean forRemoval() default false: Zeigt an, dass das Element in Zukunft gelöscht werden soll.

[zB]  Beispiel

Ein Beispiel aus der Thread-Klasse:

@Deprecated(since="1.2", forRemoval=true)

public final synchronized void stop(Throwable obj) {

throw new UnsupportedOperationException();

}
[»]  Veraltete Bibliotheken

Veraltetes hat sich im Laufe der Zeit genug angesammelt. Eine Übersicht liefert https://docs.oracle.com/en/java/javase/17/docs/api/deprecated-list.html.

 

Zum Seitenanfang

24.4.8    Javadoc-Überprüfung mit DocLint Zur vorigen ÜberschriftZur nächsten Überschrift

Das Javadoc-Tool kann in den Javadoc-Kommentaren Fehler aufspüren; aktiviert wird diese Prüfung mit dem Schalter Xdoclint. DocLint erkennt folgende Gruppen von Fehlern, die auch als Option angegeben werden können:

Gruppe

Beschreibung

accessibility

Prüft auf Probleme mit der Zugänglichkeit der Dokumentation, etwa dass Tabellen immer eine Zusammenfassung besitzen.

html

Erkennt HTML-Fehler, wie fehlende schließende spitze Klammern.

missing

Prüft auf fehlende Elemente, wenn zum Beispiel ein Kommentar oder @return fehlt.

reference

Prüft alle Referenzen in den Javadoc-Tags, etwa bei @see, oder auch ungültige Namen bei @param.

syntax

Prüft allgemeine Syntaxfehler wie nicht ausmaskierte HTML-Zeichen wie <, > oder & und nicht existierende Javadoc-Tags.

Tabelle 24.5     Mögliche Gruppen bei Javadoc und dem DocLint-Werkzeug

Zu weiteren Optionen der Javadoc-Erweiterung siehe https://docs.oracle.com/en/java/javase/17/docs/specs/man/javadoc.html.

 


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

Jetzt Buch bestellen


 Buchempfehlungen
Zum Rheinwerk-Shop: Captain CiaoCiao erobert Java

Captain CiaoCiao erobert Java




Zum Rheinwerk-Shop: Algorithmen in Java

Algorithmen in Java




Zum Rheinwerk-Shop: Spring Boot 3 und Spring Framework 6

Spring Boot 3 und Spring Framework 6




Zum Rheinwerk-Shop: Java SE 9 Standard-Bibliothek

Java SE 9 Standard-Bibliothek




 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und in die Schweiz

InfoInfo



 

 


Copyright © Rheinwerk Verlag GmbH 2024

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



Cookie-Einstellungen ändern