Anhang A Der ASCII-Zeichensatz Der ASCII-Zeichensatz ist die US-nationale Ausprägung des ISO-7-Bit-Codes (ISO 646). Eine weitere nationale Ausprägung des ISO-7-Bit-Codes ist der nach DIN 66003 spezifizierte deutsche Zeichensatz, bei dem die Zeichen Ä, Ö, Ü, ä, Ö, Ü und ß berücksichtigt wurden. Im DIN-Zeichensatz sind gegenüber dem ASCII-Zeichensatz folgende Änderungen vorgenommen worden: [=Ä

\=Ö

]=ü

{=ä

I=ö

}=ü

-=ß

Bei manchen Rechnern wie z.B. beim IBM-PC wird aber ein erweiterter ASCIIZeichensatz eingesetzt, bei dem alle 8 Bits verwendet werden. Die ersten 128 Zeichen stimmen dabei mit dem 7-Bit ASCII-Code in Tabelle überein. Die Sonderzeichen Ä, Ö, Ü, ä, Ö, ü und ß befinden sich dabei im Bereich 128-255. Wie aus Tabelle A-1 und Tabelle A-3 ersichtlich ist, enthält der ASCII-Zeichensatz Buchstaben, Ziffern, Sonderzeichen und Steuerzeichen. Da jedem Zeichen im Rahmen des jeweiligen Codes eine 7- bzw. 8-stellige Binärzahl eindeutig zugeordnet ist und die Binärzahlen selbst eine geordnete Menge darstellen, bilden damit in jedem dieser Codes die Zeichen eine geordnete Menge. Es gibt für die Zeichen also ein vorher «) und nachher (», so dass die Zeichen dem Code entsprechend alphabetisch sortiert werden können.

830

Anhang A

Dez.

Hex.

Clrl-Ch. Char.

0

00

"@

1

01

"A

2

02

"B

3

"C

7

03 04 05 06 07

8

08

"H

9

09

10

OA

"I IIJ

(ii)

•., • •

Dez.

20

33

21 22

11

OB

"K

12

OC

"L

13

00

"M

~ I

14

OE

"N

~

15

OF

11()

16

10

"p

17

11

IIQ

18

12

"R

t

19

13

"S

!!

34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51

20

14

"T

11

21

15

"U

§

22

16

23

17

"w

24

18

25

19

26

lA

4 5 6

"0 "E

•

"F "G

• a 0

•

Hex.

Char.

40

@

Dez. 96

41

A

97

61

42

B

98

62

b

43 44 45 46 47 48 49 4A 4B 4C 40 4E 4F 50 51 52 53 54 55 56 57 58 59 5A SB SC 50 SE 5F

C

99

63

c

0

100

64

d

E F

101

65

e

102

66

f

G

103

67

9

H

104

68

h

I

105

69

i

J K

106

6A

107

6B

L

108

6C

j k I

M

109

60

m

N

110

6E

n

0 P

111 112

6F

0

70

P

Q

71

R

113 114

72

q r

S

115

73

5

T

116

74

t

U

117

75

u

Hex. Char. 60

a

V

118

76

v

W

119

w

X

120

Y

121

Z

122

[

123

\ ]

124 125 126

77 78 79 7A 7B 7C 70 7E 7F

"

127

-

x Y

z (

I )

Cl

Tabelle A-1 Der ASCII-Zeichensatz mit 128 Zeichen

In der Spalte Control-Character (Steuerzeichen), abgekürzt durch Ctrl-Ch., werden spezielle Tastenkombinationen angegeben, mit denen Steuerzeichen erzeugt werden können. Hierbei kann es je nach Betriebssystem auch geringfügige Modifikationen geben. Die ersten 32 ASCII-Zeichen stellen Steuerzeichen für die Ansteuerung von Peripheriegeräten und die Steuerung einer rechnergestützten Datenübertragung dar. Diese Zeichen tragen die Namen: Dez. Symbol Dez. Symbol Dez. Symbol Dez. Symbol Dez. Symbol Dez. Symbol 0

NUL

6

ACK

12

FF

18

OC2

24

CAN

30

RS

1

SOH

7

BEL

13

CR

19

OC3

25

EM

31

US

2

STX

8

BS

14

SO

20

OC4

26

SUB

3 4

ETX EOT ENQ

9 10 11

HAT LF.NL VT

15 16

27 28 29

ESC FS

5

17

SI

21

NAK

OLE OCl

22

SYN ETB

23

GS

Tabelle A-2 Namen der 32 Steuerzeichen des ASCII-Zeichensatzes

So ist beispielsweise FF die Abkürzung für Form Feed, d.h. Seitenvorschub, oder CR die Abkürzung für Carriage Return, dem Wagenrücklauf, der schon von der Schreibmaschine her bekannt ist.

ASCII-Zeichensatz

831

Dez Hex Char

Dez Hex Char

Dez Hex Char

Dez Hex Char

Dez Hex Char

0

00

43

2B

86

56

V

129

81

AC

JO

215

1

01

44

2C

87

57

W

130

82

e

172 173

AO

i

216

08

2

02

45

20

88

58

131

83

ä

174

AE

«

217

09

3

03

4

04

5

05

6

06

7

07

8

08

9

09

10

OA

11

OB

•'.," • • •

89

59

132

84

AF

5A

Z

133

85

a

175

90

176

BO

0

91

5B

86

ä

177

B1

92

5C

[ \

134

1

135

87

178

B2

32

2

93

50

I

C

136

88

179

B3

51

33

3

94

5E

A

137

89

52

34

4

95

5F

-

138

8A

e

53

35

5

96

60

139

8B

54

36

6

97

61

a

140

8C

'i'

55

37

7

98

62

b

141

80

I

56

38

8

99

63

c

142

8E

Jl

57

39

9

100

64

d

143

8F

58

3A

101

65

e

144

90

102

66

f

145

91

ce

188

103

67

9

146 92

~

189

46

2E

47

2F

/

48

30

49

31

50

a 0

•

• Ch ..... NICMIme ) .... _1

I~:I

..... Pm .. ~

llsst sieb der Vomame der Penoa er&-aaen

I~

'~ 'd~m ""

B 2 Java-Laufzeitumgebung Unter der Java-Laufzeitumgebung versteht man einen Java-Interpreter. Im ersten Unterkapitel wird kurz auf die Java-Properties eingegangen. In den darauf folgenden Kapiteln werden die Laufzeitumgebungen java und appletviewer beschreiben.

B 2.1 Properties In Java geschriebene Programme haben nicht die Möglichkeit, direkt auf Umgebungsvariablen des Betriebssystems zuzugreifen. So ist es beispielsweise nicht möglich, die Werte der Umgebungsvariable path oder classpath der Systemumgebung auszulesen, wie dies in C oder C++ möglich ist. In Java gibt es jedoch einen ähnlichen Mechanismus, um auf Variablen der Laufzeitumgebung zuzugreifen. Dies wird durch sogenannte Properties ermöglicht. Auf Properties kann mit der Methode getProperty () der Klasse System zugegriffen werden. Es gibt eine ganze Reihe von Properties, die in einem Java-Programm ausgelesen werden können. Beispiele hierfür sind die Properties java. version, user. name oder user. dir. Sie sind in jeder virtuellen Maschine vorhanden. Es können jedoch

Java-Tools und -Laufzeitumgebung

837

auch eigene Properties an die virtuelle Maschine übergeben werden. Dies wird näher in Kapitel B 2.2 erklärt. Im Folgenden wird ein Beispielprogramm beschrieben, das die Properties java. version und user. name ausliest und auf die Standardausgabe schreibt: public class PropertyTest {

public static void main (String[] args) {

String version = System.getProperty ("java.version"); System.out.println ("Java Version: " + version); String name = System.getProperty ("user.name"); System.out.println ("Benutzername: " + name);

[YJ I

Die Ausgabe des Programms ist: Java Version: 1.2.2 Benutzername: mueller

Manche Properties können nur von Applikationen oder Applets mit besonderen Rechten gelesen werden. Dies wird genauer in Kapitel 22 beschreiben.

B 2.2 java Die Java Virtuelle Maschine wird mit java [options] class [argument ... ]

aufgerufen. Unter options können dabei optionale Kommandozeilenschalter angegeben werden. Im Folgenden sind nur die wichtigsten beschreiben. Unter class wird die Startklasse des Java-Programms angegeben. Unter argument können ein oder mehrere durch Kommata getrennte Programmparameter übergeben werden. Diese können dann in der Methode main () aus dem Übergabeparameter String [] args ausgelesen werden. Standard-Optionen • -classpath classpath Mit dieser Option wird der CLASSPATH für die Aus-

führung eines Java-Programms gesetzt. Eine eventuell vorhandene Umgebungsvariable CLASSPATH, die bereits auf der Kommandozeile gesetzt wurde, wird hierbei überschreiben.

838

Anhang B

• -Dproperty=value

Mit dieser Option können der virtuellen Maschine benutzerdefinierte Properties mitgegeben werden. Diese können dann ebenfalls mit der Methode getproperty () der Klasse System ausgelesen werden.

• -verbose

Mit dieser Option kann die virtuelle Maschine dazu veranlasst werden, Informationen über die Ausführung auszugeben. Mögliche Einstellungen sind -verbose: class, -verbose: gc oder -verbose: jni.

• -version

Mit diesem Schalter wird die Version der Java Virtuellen Maschine auf der Standardausgabe ausgegeben.

• -help

Mit diesem Schalter werden alle Optionen als Hilfe angezeigt.

• -x

Mit diesem Schalter werden alle Nicht-Standard- Optionen auf der Standardausgabe ausgegeben.

Nicht-Standard Optionen • -Xnoclassgc

Mit dieser Option wird die Garbage Collection für Klassen ausgeschaltet.

• -Xmsn

Mit dieser Option läßt sich die Anfangsgröße des Heaps der virtuellen Maschine festlegen. Ein Beispiel hierfür ist die Angabe -XmslDm. Hiermit wird die Anfangsgröße auf 10MB festgelegt.

• -Xmxn

Mit dieser Option läßt sich die maximale Größe des Heaps der virtuellen Maschine festlegen. Ein Beispiel hierfür ist die Angabe -Xmx2 Dm. Hiermit wird die maximale Größe auf 20 MB festgelegt.

B 2.3 Appletviewer Mit dem Appletviewer lassen sich Applets samt ihrer HTML-Seite testen. Dabei wird von der HTML-Seite jedoch nur das Applet-Tag berücksichtigt, die Seite an sich wird nicht angezeigt. Der Appletviewer läßt sich mit appletviewer [options] urls starten. Als options können dabei optionale Kommandozeilenschalter angegeben werden. Als urls lassen sich eines oder mehrere HTML-Dokumente, die Applets enthalten, angeben wie in folgendem Beispiel: appletviewer Schule.html

Java-Tools und -Laufzeitumgebung

839

B 3 Jar-Dateien Bei j ar-Dateien handelt es sich um Dateien, die verschiedene Dateien in einem Archiv zusammenfassen. Ein Archiv dient zur Zusammenstellung mehrerer Dateien - in gepackter oder ungepackter Form - in einer einzigen Datei. Der Inhalt jeder .jar- Datei kann auch mit jedem gängigen zip-Tool entpackt und angesehen werden. j ar-Dateien wurden in Java aus zwei Gründen eingeführt. Bei Java-Programmen handelt es sich immer um eine mehr oder weniger lose Sammlung von . class Dateien. Die Anzahl der. class Dateien kann in größeren Projekten leicht die Zahl 1000 überschreiten. Damit bei der Auslieferung eines Programms nicht so leicht Dateien verloren gehen, wurden die jar-Dateien eingeführt. Ein weiterer wichtiger Grund ist bei der Verwendung von Applets zu finden. Bei einem Applet werden alle im Applet benötigten Klassen einzeln von einem HTTP-Server geladen. Dabei wird für das Laden jeder Datei eine neue HTTP-Verbindung aufgebaut. Wird eine einzelne komprimierte j ar-Datei geladen, so ist nur eine Verbindung nötig - die Übertragungszeit wird dadurch und durch die Komprimierung wesentlich verringert. Zusätzlich läßt sich eine jar-Datei noch signieren. Siehe hierzu Kapitel B 4. In einer jar-Datei können Klassen, Bilder und Audiodateien aufgenommen werden. Zu Erstellung einer jar-Datei wird das Tool jar mit dem JDK ausgeliefert. Seine Benutzung ist nahezu identisch mit dem tar Kommando unter UNIX: jar [options] Zieldatei Dateien Die Zieldatei ist das jar-Archiv, in dem alle unter Dateien angegebenen Dateien gespeichert werden sollen. Mit den folgenden Optionen läßt dies beeinflussen: • c •

T

• x •

f

• v • 0

• u

Erzeugt eine neues jar-Archiv Gibt den Inhalt einer j ar- Datei auf der Standard ausgabe aus. Entpackt die angegebenen oder alle Dateien, die sich in dem angegebenen j ar-Archiv befinden Mit dieser Option wird der Name der jar-Datei angegeben. Ist diese Option eingeschaltet, so wird der Fortschritt beim Packen oder Entpacken einer j ar-Datei angezeigt. Wird diese Option angegeben, so werden die Dateien unkomprimiert im j arArchiv abgelegt. Mit der Option u kann eine schon bestehende j ar-Datei aktualisiert werden.

Im Folgenden wird an einem Beispiel gezeigt, wie das Tool zu verwenden ist. Es wird dabei angenommen, dass sich die Dateien Person.class, Student.class und Schueler. class in einem Verzeichnis befinden. Mit jar cfv test. jar *. class werden alle. class Dateien, also die Dateien Person. class, Student. class und Schueler. class in die jar-Datei

840

Anhang B

test. jar gepackt. Mit der Option v wird die Fortschrittsanzeige angeschaltet. Dabei ergibt sich folgende Ausgabe:

L!J 11

added manifest adding: Person.class(in = 316) (out= 242) (deflated 23%) adding: Schue1er.class (in = 768) (out= 458) (deflated 40%) adding: Student.class(in = 713) (out= 458) (deflated 35%)

Wie aus der Ausgabe ersichtlich ist, wird außer den drei . class Dateien noch eine sogenannte Manifest-Datei in die jar-Datei aufgenommen. Sie enthält Informationen über jede Datei, die in der jar-Datei enthalten ist. Mit j ar t f tes t . j ar wird der Inhalt der j ar-Datei ausgegeben. Mit j ar xf test. jar wird die jar-Datei wieder entpackt. Um in Applets jar-Dateien verwenden zu können, wurde das Applet-Tag um den Parameter archive erweitert: Alle für in der Klasse Schule benötigten Klassen werden nun aus der Datei schule. j ar geladen.

B 4 Java Security Tools In den folgenden Unterkapiteln sollen die Tools des JDK für alle sicherheitsrelevanten Teile erklärt werden. Da eine ausführliche Beschreibung bei weitem den Rahmen dieses Buches sprengen würde, werden die wichtigsten Funktionen dieser Tools an hand eines durchgängigen Beispiels erklärt. Dabei wird zuerst die Erzeugung eines Zertifikats mit dem keytool betrachtet, danach wird mit dem Tool jarsigner die j ar-Datei eines Java-Programms signiert. Zum Schluß wird noch eine Policy Datei erzeugt, die der signierten j ar-Datei mehr Rechte einräumt.

B 4.1 Keytool Keytool wird zur Erzeugung von Schlüsseln bzw. Zertifikaten verwendet. Zusammen mit jarsigner ersetzt es das Tool javakey aus JDK 1.1.x. Keytooloperiert auf einer Datei, die. keystore genannt wird. Diese liegt defaultmäßig in dem durch java. horne angegebenen Verzeichnis und heißt . keystore. Mit der Option keystore kann auch eine andere Datei angegeben werden. Die Erzeugung eines public/private-Schlüssel-Paares erfolgt durch den Aufruf keytool -alias Schlüsselnarne -genkey. Dabei wird mit "Schlüsselname" ein Alias für den erzeugten Schlüsseleintrag angegeben, z.B. "maier".

Java-Tools und -Laufzeitumgebung

841

Im Folgenden wird ein Schlüsselpaar unter dem Alias "maier" in einer Keystore-Datei mit Namen "myKeys" im lokalen Verzeichnis erzeugt: keytool -alias maier -genkey -keystore myKeys

Das Programm keytool fragt dabei als nächstes nach einem Passwort für die Keystore-Datei: Enter keystore password:

Das Passwort muss mindestens 6 Zeichen lang sein und schützt später den Keystore vor unbefugter Benutzung. Nach der Eingabe des Passwort werden verschiedene Daten für das zu erzeugende Schlüsselpaar abgefragt. What is your first and last name? [Unknown]: Hugo Maier What is the name of your organizational unit? [Unknown]: FHTE What is the name of your organization? [Unknown]: Fachhochschule Esslingen What is the name of your City or Locality? [Unknown]: Esslingen What is the name of your State or Province? [Unknown]: Germany What is the two-letter country code for this unit? [Unknown]: DE Is correct? [no]: y

Abschließend muss noch ein Passwort für den Private Key gewählt werden. Wenn das gleiche Passwort wie für den Keystore gelten soll, so ist kein weiteres Passwort einzugeben, sondern einfach das vorhandene Passwort mit Return zu bestätigen. Enter key password for (RETURN if same as keystore password) :

Es erfolgen dann später auch keine separaten Passwortabfragen für diesen Schlüssel. Dies heißt jedoch nicht, dass der Schlüssel kein Passwort hat. Er hat nur dasselbe Passwort wie auch die Keystore-Datei und wird deshalb nicht separat abgefragt. Den Inhalt der Keystore-Datei kann man sich mit keytool -list ausgeben lassen. Nach einer Eingabeaufforderung für das Passwort des Keystores erfolgt dann die Ausgabe des Inhalts. Dieser sieht hier folgendermaßen aus: Keystore type: jks Keystore provider: SUN Your keystore contains 1 entry: maier, Sun Dec 05 15:12:41 GMT+01:00 1999, keyEntry, Certificate fingerprint (MD5): EF:98:66:4B:95:4D:28:B3:5E:26:4E:AD:43:7C:7D:3C

842

Anhang B

Mit keytool -list -v können weitere Informationen zu den Schlüsseleinträgen in der Keystore-Datei abgerufen werden. Keystore type: jks Keystore provider: SUN Your keystore contains 1 entry: Alias name: maier Creation date: Sun Dec 05 15:12:41 GMT+01:00 1999 Entry type: keyEntry Certificate chain length: 1 Certificate[l) : Owner: CN=Hugo Maier, OU=FHTE, 0= Fachhochschule Esslingen, L=Esslingen, ST=Germany, C=DE Issuer: CN= Hugo Maier, OU=FHTE, 0= Fachhochschule Esslingen, L= Esslingen, ST=Germany, C=DE Serial number: 384a72c8 Valid from: Sun Dec 05 15:12:24 GMT+01:00 1999 until: Sat Mar 04 15:12:24 GMT+01:00 2000 Certificate fingerprints: MD5: EF:98:66:4B:95:4D:28:B3:5E:26:4E:AD:43:7C:7D:3C SHA1: B1:81:2F:EB:41:2F:7A:62:C7:1F:2E:4B:22:BE:37:A9:7E:5A:E7:CB ******************************************* *******************************************

Jetzt, da ein Schlüsselpaar erzeugt ist, kann man dazu übergehen, Code zu signieren. Dies erfolgt mit dem Tool jarsigner.

B 4.2 Jarsigner Zum Signieren von Java-Code müssen sich die kompilierten . class-Files in einem jar-Archiv befinden. Der Aufruf zum Signieren eines test. jar Files ist relativ einfach: jarsigner -keystore myKeys test.jar maier Hierbei wird der private Schlüssel unter dem Alias "maier" aus der Keystore-Datei "myKeys" im aktuellen Verzeichnis verwendet. Nach Eingabe des Passworts für die Keystore-Datei und - wenn unterschiedlich - auch der Eingabe des Passworts für den spezifischen Schlüssel erfolgt die Signierung des j ar-Files.

B 4.3 Umgang mit Certification Authority-Zertifikaten Mit dem JDK 1.2 kann nun auch endlich mit CA-Zertifikaten umgegangen werden. Eine CA (Certification Authority) signiert ihrerseits einen public Schlüssel und bestätigt damit die Richtigkeit der Angaben, die zu einem Schlüssel gemacht wurden. Um einen sogenannten "Certificate Request" zu erzeugen, gibt es in keytool die Option -certreq. keytool -certreq -alias maier -file request -keystore myKeys Enter keystore password: testme

Java-Tools und -Laufzeitumgebung

843

Das von einer CA signierte Ergebnis kann dann in den Keystore importiert werden. Der angegebene Alias muss dabei vom alten Alias verschieden sein. keytool -import -alias maierCert -trustcacerts -file response Dies importiert das Zertifikat aus der Datei "response" in die Keystore Datei unter dem neuen Alias "maierCert". Die Option -trustcacerts weist keytool an, gegen die Root-Zertifikate zu verifizieren, die mit dem JDK ausgeliefert werden.

B 4.4 Schlüsselverteilung Um anderen zu ermöglichen die Signatur des j ar-Files zu prüfen, muss der public Schlüssel diesen Personen zugänglich gemacht werden. Um den Schlüssel zu verteilen, sieht keytool eine Export-Funktion vor. keytool -export -alias maier -file mykey -keystore myKeys Enter keystore password: testme Certificate stored in file Nun kann eine andere Partei diesen Schlüssel aus der Datei in die eigene KeystoreDatei importieren. Dies erfolgt mit der Option import: keytool -import -alias maier -file mykey Enter keystore password: testme Owner: CN=Hugo Maier, OU=FHTE, 0= Fachhochschule Esslingen, L=Esslingen, ST=Germany, C=DE Issuer: CN=Hugo Maier, OU=FHTE, 0= Fachhochschule Esslingen, L= Esslingen, ST=Germany, C=DE Serial number: 384a72c8 Valid from: Sun Dec 05 15:12:24 GMT+01:00 1999 until: Sat Mar 04 15:12:24 GMT+01:00 2000 Certificate fingerprints: MD5: EF:98:66:4B:95:4D:28:B3:5E:26:4E:AD:43:7C:7D:3C SRA1: B1:81:2F:EB:41:2F:7A:62:C7:1F:2E:4B:22:BE:37:A9:7E:5A:E7:CB Trust this certificate? [no]: y Certificate was added to keystore Damit ist der public Schlüssel in der Keystore Datei unter dem Alias "maier" als vertrauenswürdig gespeichert. Jetzt können Signaturen von j ar-Files, die mit dem privaten Schlüssel (dem Gegenstück zu diesem public Schlüssel) erstellt wurden, geprüft werden.

B 4.5 Policy Tool In JDK 1.1.x konnte Code von einer als vertrauenswürdig anerkannten Instanz alles tun. In JDK 1.2 ist das anderes. So hat das Speichern des Schlüssels und seine Anerkennung als vertrauenswürdig noch keinen weiteren Effekt. Damit der signierte Code von dieser Instanz auch besondere Rechte bekommt, wird eine Policy benötigt. Die Erstellung einer sicheren Policy ist ein komplexes Thema, auf das hier nicht genauer eingegangen werden kann. Es soll hier nur kurz auf die Erstellung einer

844

Anhang B

einfachen Policy eingegangen werden, wie sie nötig ist, um signierten Code einer bestimmten Instanz mit erweiterten Rechten auszuführen. Für die Erstellung einer Policy reicht ein simpler ASCII-Editor. Es gibt im JDK zwar ein Policytool genanntes Werkzeug für die Erstellung von Policy Dateien. Es lassen sich mit dem Policytool jedoch nicht alle Möglichkeiten ausschöpfen, so dass bei Kenntnis des Formats der Policy Datei die Erstellung mit einem normalen Editor vorzuziehen ist. Im Folgenden wird eine Policy Datei mit Namen "myPolicy" im aktuellen Verzeichnis (dem Verzeichnis, in dem sich auch die Keystore Datei befindet) mit einem normalen Editor erzeugt. Der erste Eintrag in dieser Policy Datei enthält den relativen Pfad zu unserer Keystore Datei "myKeys". Es folgt dann ein grant-Statement, welches Code, der vom Alias "maier" (wie in der Keystore Datei hinterlegt) signiert ist und von der entsprechenden Code Base kommt, das Recht zugesteht, alle Dateien in c: \ temp zu schreiben. Im zweiten grant-Statement wird von "schulze" signiertem Code, der sich lokal in c:\programme\java\ befindet, das Recht gewährt, alle Dateien unterhalb des Wurzelverzeichnisses c: \ zu lesen. keystore "myKeys"; grant signedBy "maier", codeBase .. http://www.nirgendwo.com/applets/ .. permission java.io.FilePermission "c:\\temp\\*",

"write";

};

grant signedBy "schulze", codeBase "file:/c:/programme/java/" { permission java.io.FilePermission "c:\\*",

"read";

};

Für eine Beschreibung der Syntax der Policy Datei siehe http://java.sun.com/products/jdk/1.21docs/guide/security/PolicyFiles.html Eine Auflistung aller verfügbaren Permission und deren Beschreibung kann unter http://java.sun.com/products/jdk/1.2/docs/guide/security/permissions.html gefunden werden.

Anhang C Gültigkeitsbereiche von Namen Unter dem GOltlgkeltsberelch eines einfachen Namens versteht man den Bereich im Programm, innerhalb dessen die Deklaration des Namens bekannt ist.

QualHizierte Namen dienen zum Zugriff auf die Komponenten eines Pakets und auf die Methoden und Datenfelder von Referenztypen wie einer Klasse oder Schnittstelle. Soll beispielsweise in einer Klasse eine Klasse eines anderen Pakets benutzt werden, so erfolgt der Zugriff mit Hilfe eines qualifizierten Namens. Ein qualifizierter Name besteht aus einem Namen, einem Punkt und einem Bezeichner. Hierbei versteht man unter einem Bezeichner einen einfachen Namen. Ähnliche Zugriffsformen sind die Zugriffe auf Datenfelder und Methoden von Objekten über Referenzen. Diese Zugriffe erfolgen auch mit Hilfe des PunktOperators. Bei den im folgenden erörterten Gültigkeitsbereichen geht es nicht um Zugriffe von außen, sondern um die Gültigkeit von Namen, die bei ihrer Deklaration, d.h. wenn sie dem Compiler bekannt gegeben werden, stets einfache Namen sind. Deklarationen können in Teilen ihres Gültigkeitsbereichs verdeckt werden durch andere Deklarationen mit demselben Namen. Wird der entsprechende Name durch eine weitere Einheit mit demselben Namen verdeckt, so ist der Name immer noch gültig, aber nicht sichtbar, da bei seiner Verwendung der Zugriff auf die verdeckende Einheit erfolgt. Ein Beispiel für das Verdecken ist das Verdecken eines Datenfeldes mit dem Namen x durch eine lokale Variable mit dem Namen x, oder das Verdecken einer Marke in einem äußeren Block durch eine Marke mit demselben Namen in einem inneren Block. Wird ein Name nicht verdeckt343 , so kann innerhalb des Gültigkeitsbereichs über den Namen auf die entsprechende Einheit Bezug genommen werden. Nicht immer führt ein gleicher Name dazu, dass ein anderer Name verdeckt wird. Durch die Verwendung von Kontexten kann Java Namenskonflikte minimieren. So dürfen beispielsweise Typen, Methoden und Datenfelder in Java denselben Namen tragen. Aus der Verwendung wird dabei klar, um was es sich jeweils handelt.

343

Das Überschreiben von Methoden und das Verdecken von Datenfeldern wird in Kap. 10.5 behandelt.

846

Anhang C

Man unterscheidet zwischen den Gültigkeitsbereichen: • • • • • • • •

von Paketen, von importierten Klassen und Schnittstellen, eines Klassen- oder Schnittstellennamens, von Datenfeldem und Methoden innerhalb einer Klasse oder einer Schnittstelle, von formalen Parametem einer Methode oder eines Konstruktors, von lokalen Variablen innerhalb eines Blocks. von lokalen Variablen, die In der Initiallsierungsklausel einer für-Schleife definiert werden, und eines Exceptlon-Parameters in einem catch-Block.

C 1 Pakete Pakete entsprechen Verzeichnissen in der Verzeichnisstruktur eines Speichermediums. Auf welche Pakete auf der obersten Ebene zugegriffen werden kann, d.h. welche Paketnamen auf der obersten Ebene gültig sind, wird durch Einstellungen auf der Betriebssystem-Ebene festgelegt.

C 2 Importierte Klassen und Schnittstellen Wird ein Klassenname oder ein Schnittstellenname in einer Übersetzungseinheit (Datei) importiert, so ist er ab der import-Vereinbarung in der ganzen Übersetzungseinheit sichtbar. Dies gilt für einen vollständig qualifizierten Namen wie z.B.: import java.awt.Frame; ebenso wie für die Verwendung von Wildcards import java.awt.*; Werden Wildcards verwendet, so werden alle entsprechenden public-Typen des genannten Pakets importiert, sofem sie benötigt werden. Die Gültigkeit der importierten Namen erstreckt sich nur auf die Datei, nicht auf das gesamte Paket.

C 3 Klassen- oder Schnittstellen namen Der Gültigkeitsbereich einer in einem Paket definierten Klasse oder Schnittstelle bezieht sich auf alle Übersetzungseinheiten (Dateien) des Pakets. Eine Vorwärtsdeklaration ist nicht erforderlich. In Kapitel 11.6 wurde für die Gültigkeit von Klassen ein Beispiel gegeben.

847

Gültigkeitsbereiche von Namen

C 4 Datenfelder und Methoden innerhalb einer Klasse oder einer Schnittstelle Wenn ein Attribut, d.h. ein Datenfeld oder eine Methode, in einer Klasse oder Schnittstelle definiert wird oder von der Klasse bzw. Schnittstelle geerbt wird, so ist das Attribut - unabhängig von der Reihenfolge der Attribute - in der gesamten Definition der Klasse bzw. Schnittstelle gültig, es sei denn, es wird ein Datenfeld zur Initialisierung eines Datenfeldes benutzt. Ist dies der Fall, dann muss das zur Initialisierung verwendete Datenfeld bereits selbst definiert sein, wenn es zur Initialisierung eines Datenfeldes herangezogen wird. Deshalb wird beim folgenden Beispiel ein Fehler erzeugt. II Datei: Inittest.java class Inittest {

int alpha int beta

LIJ 11

beta; Ilnicht zulaesssig 3;

Die Meldung des Compilers lautet: Inittest.java:3: Can't make forward reference to beta in class Inittest. int alpha beta; Ilnicht zulaesssig

=

Zulässig ist aber: II Datei. Inittest2.java class Inittest2.java {

Reihenfolgetest() {

alpha = 3; int beta 1; int alpha,

Ebenso ist zulässig: II Datei: Inittest3.java class Inittest3 {

int alpha = beta; atatic int beta 3;

=

da eine Klassenvariable bereits beim Laden initialisiert wird.

848

Anhang C

C 5 Formale Parameter Konstruktors

einer

Methode

oder

eines

Der Gültigkeitsbereich des Namens eines formalen Parameters ist der ganze Methodenrumpf. Es ist nicht zulässig, den Namen eines formalen Parameters zu verdecken, d.h. der Name eines formalen Parameters kann nicht für die Definition einer lokalen Variablen oder eines Exception-Parameters innerhalb der Methode verwendet werden. Auf formale Parameter kann nur unter Verwendung ihres einfachen Namens, nicht aber mit einem qualifizierten Namen Bezug genommen werden. Formale Parameter eines Konstruktors werden wie formale Parameter von Methoden behandelt.

C 6 Lokale Variablen innerhalb eines Blocks Der Gültigkeitsbereich einer lokalen Variablen ist der Rest des Blocks ab der Definition der Variablen einschließlich weiterer Definitionen im Rahmen ihrer Deklarationsanweisung. Lokale Variablen verlieren am Ende ihres Blockes ihre Gültigkeit.

C 7 Lokale Variablen in einer for-Anweisung Der Gültigkeitsbereich einer lokalen Variablen, die im Initialisierungskonstrukt einer for-Schleife definiert wird, erstreckt sich über die Ini tialisierungsklausel mit der eigenen Definition und den Definitionen rechts davon, über den Ausdruck BoolescherAusdruck, die Aktualisierungs-Ausdrucksliste und schließlich die Anweisung. An die Stelle der Anweisung kann ein Block treten. Nach der Schleife verlieren die in der Initialisierungsklausel definierten Variablen ihre Gültigkeit. Das folgende Beispiel demonstriert den Gültigkeitsbereich einer in der Initialisierungsklausel definierten lokalen Variablen i: // Datei: Calc.java class Calc {

public static void main (String [l args) {

for (int n = 10; n