Kapitel 10 Dokumentation af kode

Kode skrevet i et objektorienteret programmeringssprog som Java er let at genbruge. Man kan blot tage klassefilerne fra et projekt og bruge dem direkte i et andet uden at behøve rekompilering. Denne tidsbesparelse kan være mange penge værd på store projekter. Det eneste problem ved denne fremgangsmåde er, at det kan være svært at huske, hvordan koden virker. Det kan godt være, at man kan se, at en funktion tager tre tekststrenge som parametre, men hvad hjælper det, hvis man ikke aner, hvad de betyder? Problemet er endnu større, hvis man udvikler frameworks, der skal sælges til tredjepart, der slet ikke har noget kendskab til klasserne og deres metoder.

Du læser en gammel bog
Den bog, du læser her, er fra 1998, og mange ting kan have ændret sig siden da.
Vi håber, at du stadig kan finde relevant information i den.
Hvis du vil læse aktuelle oplysninger om de avancerede dele af Java, anbefaler vi
bogen Core Java – Advanced Features

Der er således brug for en måde at dokumentere koden på. Det, der er behov for, er en beskrivelse af pakker, klasser og metoder. For hver metode er det endvidere ønskeligt, at parametrene er beskrevet.

 

Med Java Development Kit følger et program, der kan oprette den slags dokumentation. Det hedder JavaDoc og arbejder ved at læse kildeteksten igennem og kigge på de specielle JavaDoc-kommentarer, der kan indsættes. På baggrund af disse oprettes en række HTML-dokumenter, der indeholder beskrivelser af klasserne og deres metoder. Dokumenterne indeholder også henvisninger til superklasser.

 

JavaDoc er blandt andet brugt til at generere den beskrivelse af samtlige Java-pakker, der findes på JavaSofts hjemmeside.

 

Figur 10-1: Sun bruger selv JavaDoc til at dokumentere kode.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

I dette kapitel beskrives, hvordan JavaDoc bruges, og hvordan JavaDoc-kommentarer indsættes i kildeteksten.

Mulighederne i JavaDoc

JavaDoc giver mulighed for at håndtere følgende dokumentation:

 

  • Angivelse af klasser og interfaces programmører
  • Angivelse af klasser og interfaces versionsnumre
  • Beskrivelse af pakker
  • Beskrivelse af klasser
  • Beskrivelse af metoder
  • Beskrivelse af metoders parametre
  • Beskrivelse af metoders returværdi
  • Beskrivelse af metoders exceptions
  • Henvisning til andre metoder og/eller klasser
  • Angivelse af, at en metode eller klasse er forældet.

 

 

Angivelse af dokumentation i kildeteksten

 

Som nævnt tidligere skal den dokumentation, JavaDoc skal arbejde på, angives i kildeteksten. Det gøres ved hjælp af bestemte kommandoer. Alle kommandoerne skal skrives i kommentarer, så de ikke forstyrrer den rigtige Java-kode. I modsætning til almindelige kommentarer, der indledes med /*, indledes JavaDoc-kommentarer med /**. De afsluttes ligesom almindelige kommentarer med */. Nedenstående eksempel viser, hvordan man kan beskrive en metode i kildeteksten:

 

public class Test

{

 

/**

* Beskrivelse af en metode

*/

 

public void run()

{

}

}

 

Bemærk, at alle linier i JavaDoc-kommentarer indledes med en stjerne. Den tekst, der bare skrives i JavaDoc-kommentaren, vil altid blive regnet for at være beskrivelse af den næste metode. For at angive andre oplysninger, skal man bruge de specielle JavaDoc-parametre. Fælles for alle parametrene, der også skrives i JavaDoc-kommentarer, er, at de indledes med @. Der findes følgende JavaDoc-parametre:

 

 

  • @author
    Navnet på den eller de programmører, der har skrevet klassen.
  • @version
    Klassens versionsnummer og eventuelt dato.
  • @param
    Beskrivelse af en af parametrene i en metode.
  • @return
    Beskrivelse af en metodes returværdi.
  • @exception
    Beskrivelse af den eller de exceptions, der kan opstå ved at bruge metoden.
  • @see
    Henvisning til en anden metode eller klasse.
  • @since
    Den version af produktet, metoden først optrådte i.
  • @deprecated
    Angivelse af at en metode er forældet, samt eventuelt hvilken metode, der skal bruges i stedet.

Hvis klassens forfatter er ukendt, bør den angives som unascribed. Det vil sige:

/**

* @author unascribed

*/

@deprecated bruges, når en metode er blevet forældet og erstattet af en nyere. Den besked, der skrives efter @deprecated, skal beskrive hvorfor funktionen er forældet, samt hvilken funktion man bør bruge i stedet. @deprecated bør efterfølges af en @see, der angiver navnet på den nye metode.

/**

* Starter udførslen af programmet

*

* @deprecated        Denne funktion er ALT for langsom. Brug i stedet runMe()

* @see               #runMe()

*/

Hvis metoden ikke længere er nødvendig og derfor ikke er erstattet af en anden funktion, bør @deprecated efterfølges af No replacement. Der skal i så fald ikke være henvisninger til andre funktioner:

 

/**

* Starter udførslen af programmet

*

* @deprecated        No replacement

*/

 

Ved hjælp af @see-parametren er det muligt at lave henvisninger både til klasser og til metoder. Det generelle format for @see er

 

@see klasse#metode

 

 

 

Hvis man vil lave en henvisning til en klasse, kan man nøjes med at skrive navnet på klassen. Vil man derimod lave en henvisning til en metode, skal både klasse og metodenavn skrives adskilt af en havelåge (#). Henviser man til en metode i samme klasse som metoden selv, kan man nøjes med en havelåge og funktionsnavnet. Man kan også lave en henvisning til en side, der ikke er genereret af JavaDoc. Det gør man ved at skrive henvisningen som HTML-kode. Hvis man vil henvise til et dokument, der ikke findes online – for eksempel en bog – kan man gøre det, ved at angive navnet i anførselstegn. Nedenstående viser forskellige former for henvisninger:

 

@see String

@see String#toString

@see #toString

@see <a href = ”http://www.javasoft.com”>JavaSoft</a>

@see ”Avanceret Java-programmering”

 

Med tiden forventes det, at @return bliver til @returns, og at @exception bliver til @throws. Dette er endnu ikke sket i Java Development Kit 1.2.

Organisering af JavaDoc-kommentarer

 

JavaDoc-kommentarer skal altid placeres før den del af programmet, de beskriver. Det vil sige, at kommentarer, der beskriver en klasse, skal placeres før definitionen af klassen, ligesom kommentarer, der beskriver en metode, skal placeres før definitionen af metoden.

 

Parametrenes rækkefølge er heller ikke helt ligegyldig. Generelt bør de placeres i samme rækkefølge, som de er blevet gennemgået i dette kapitel. Hvis den samme parameter skal bruges flere gange med forskellige værdier, bør følgende regler iagttages:

 

  • Ved flere programmører bør programmørerne angives i kronologisk orden. Det vil sige, at den programmør, der oprettede klassen, står øverst.
  • Ved flere parametre til en metode skal der oprettes en @param til hver. Parametrene angives i samme rækkefølge, som de står i metodens signatur.
  • Hvis en metode kaster flere exceptions, angives disse med hver deres @exception i alfabetisk rækkefølge.
  • Hvis der er flere henvisninger, angives disse med hver deres @see i alfabetisk orden.

 

For at gøre JavaDoc-kommentaren mere overskuelig kan den opdeles i flere blokke. Der kan skabes afstand mellem to blokke i kommentaren ved at lave en linie, der kun indeholder en stjerne.

Brug af HTML-kode

Da JavaDoc genererer HTML-dokumenter, kan man også bruge HTML-kommandoer i kommentarerne. De bruges præcis som man ville bruge dem i et almindeligt HTML-dokument. Man bør dog undlade at bruge <H1> og <H2>, da de bliver brugt af JavaDoc. Til gengæld kan man med fordel

 

bruge <code>…</code> til at omkranse kodeeksempler og <p> til at adskille afsnit i en beskrivelse:

 

/**

* Denne beskrivelse er temmelig lang

* .

* .

* <p>

* Derfor er det rart, at den er delt i flere afsnit

*

*

*/

 

public class test

{

}

 

Brug af JavaDoc-programmet

 

Når kildeteksten er dokumenteret, behøver man blot at bruge JavaDoc-programmet for at få genereret specifikationerne i HTML-format. JavaDoc-programmet ligger i bin-biblioteket i Java-installationen. Programmet har følgende syntaks:

 

javadoc [-options] fil|pakke

 

Som det ses, kan man vælge at generere dokumentation for en enkelt fil eller for en hel pakke. For at give brugeren mulighed for få dokumentationen genereret præcis, som han vil have den, er det muligt at angive en række options.

 

  • -public
    Angiver, at kun public klasser, metoder og attributter vises.
    -protected
    Angiver, at kun public eller protected klasser, metoder og attributter vises. Angives ingen options anvendes denne.
    -package
    Angiver, at kun pakker samt public eller protected klasser, metoder og attributter vises.
    -private
    Angiver, at alle klasser og alle metoder og attributter vises.
    -Jflag
    Overfører flag direkte til runtime-systemet.
    -encoding navn
    Angiver den måde, kildeteksterne er kodet på.
    -docencoding navn
    Angiver den måde, HTML-filerne skal kodes på.
    -version
    Angiver, at @version-parametre skal medtages. Angives –version ikke, bliver disse udeladt.
  • -author
    Angiver, at @author-parametre skal medtages. Angives –author ikke, bliver disse udeladt.
    -noindex
    Angiver, at der ikke skal oprettes en liste over pakker.
    -notree
    Angiver, at der ikke skal oprettes en oversigt over klasser og interfaces.
    -d bibliotek
    Angiver det bibliotek, HTML-filerne skal gemmes i. Biblioteket kan angives som en absolut eller en relativ sti.
    -verbose
    Angiver, at JavaDoc-programmet skal generere mere output end sædvanligt. Angives
    -verbose ikke, vises kun en besked pr. fil. Hvis –verbose angives, bliver det derudover også vist, hvor mange millisekunder, der er blevet brugt på at behandle hver java-fil.
    -sourcepath sti
    Angiver den sti, der skal søges efter java-filer i. Hvordan stien angives afhænger af, om man angiver java-filer eller pakker som parameter. Når man angiver pakker, skal sourcepath være stien til den pakke, der ligger øverst i hierakiet. Hvis man vil dokumentere en pakke, der hedder java.tree, der ligger i biblioteket
    \prog\java\tree\*.java
    skal sourcepath sættes til
    -sourcepath \prog
    Når der genereres dokumentation for enkelte klasser, skal sourcepath angive det bibliotek, java-filerne ligger i. Det vil altså sige, at hvis man vil have genereret dokumentation for filen
    \prog\java\tree\Tree.java
    skal sourcepath sættes til
    -sourcepath \prog\java\tree
    Det er ikke nødvendigt at angive en sourcepath, hvis man starter JavaDoc-programmet fra det bibliotek, man ville have angivet som sourcepath.
    -classpath sti
    Som regel er det ikke nødvendigt at bruge –classpath. Hvis man vil angive placeringen af de java-filer, der skal dokumenteres, skal man bruge –sourcepath i stedet (se ovenstående).
    Stien angivet efter –classpath, angiver placeringen af de klassefiler, JavaDoc-programmet skal bruge. Hvis –sourcepath ikke er angivet, angiver stien også placeringen af de filer, der skal dokumenteres.
    Angives –classpath ikke, sættes det til det aktuelle bibliotek plus de biblioteker, der r angives i CLASSPATH-variablen.
    -nodeprecated
    Angiver, at elementer markeret med @deprecated-parametren skal udelades.
    overview sti
    Læser oversigt over dokumentationen fra en HTML-fil.
    nodeprecatedlist
    Angiver, at der ikke skal oprettes en oversigt over elementer markeret med @deprecated-parametren.
  • -linkall
    Angiver, at der skal oprettes henvisninger til klasser og pakker, selvom der ikke bliver genereret dokumentation for dem i denne omgang. Denne option gør det muligt at generere en samlet dokumentation for flere projekter ad flere gange. Det gør det også muligt at nøjes med at opdatere en del af dokumentationen, hvis man kun foretager ændringer i nogle få klasser.
  • -breakindex
    Angiver, at indeksfilen skal opdeles i flere filer. Hvis man genererer dokumentation for mange klasser, kan indeksfilen blive så stor, at den er tung at hente over Internet. I disse tilfælde kan det anbefales, at bruge –breakindex til oprette en indeksfil til hvert bogstav.
  • -frame
    Angiver, at dokumentationen skal organiseres ved hjælp af HTML-frames. Med denne option sat, bliver der oprettet en frame med en oversigt over samtlige pakker. Der bliver også oprettet en frame med en oversigt over de klasser, der findes i pakken, mens hovedparten af vinduet bruges til en beskrivelse af den aktuelle klasse.
  • -nohelp
    Angiver, at der ikke skal oprettes et link til en hjælpeside. Hjælpesiden bliver ikke automatisk genereret af JavaDoc. Angives andet ikke med –helpfile hedder hjælpefilen help.html.
  • -title html-kode
    Angiver et stykke HTML-kode, der skal indsættes øverst på hver side.
  • -footer html-kode
    Angiver et stykke HTML-kode, der skal indsættes som bundtekst på hver side.
  • -header html-kode
    Angiver et stykke HTML-kode, der skal indsættes som toptekst på hver side.
  • -bottom html-kode
    Angiver et stykke HTML-kode, der skal indsættes nederst på hver side.
  • -helpfile fil
    Angiver navnet på den fil, der skal bruges som hjælpefil. Angives intet navn anvendes help.html. Hvis der slet ikke skal laves en henvisning til en hjælpefil, skal man bruge –nohelp.


 

Retningslininer for dokumentation

 

Formålet med dokumentationen er, at andre skal kunne bruge ens klasser, og at man selv kan bruge dem, også et par dage efter man har programmeret dem. Derfor er det en fordel, hvis man formulerer dokumentationen så klart som muligt. Det vil også lette arbejdet med at sætte sig ind i flere klassers funktionalitet, hvis alle klasser er beskrevet på nogenlunde samme måde. Større projektgrupper bør have retningslinier for udarbejdelse af dokumentationen – det er vigtigt i retningslinierne at sikre, at dokumentationen bliver fyldestgørende, men samtidig skal man være sikker på, at det ikke bliver så kompliceret og tidskrævende at skrive dokumentationen, at folk simpelthen lader være. Dette afsnit beskriver, hvordan sådanne retningslinier kan se ud.

 

 

 

Et eksempel på retningslinier

 

  • Den første sætning i dokumentet bør være en opsummering, der indeholder en kort men komplet beskrivelse af API’et. Denne sætning afsluttes ved det første punktum eller tvungne linieskift.JavaDoc kopierer denne første sætning til starten af dokumentet, så derfor er det vigtigt, at den er kort, men præcis. Det er også vigtigt, at kommentarerne gør det muligt at skelne mellem overloadede metoder (metoder med samme navn, men med forskellig signatur).
  • Nøgleord og navne i API’et omgives af <code>…</code>.  Navne på parametre angiver umiddelbart efter @param, skal ikke omgives af <code>…</code>. Af de elementer, der skal markeres med <code>…</code>, kan blandt andet følgende nævnes:
    • Java nøgleord (void, class, osv.)
    • Navne på pakker (java.lang, java.awt, osv.)
    • Navne på klasser (String, Frame, osv.)
    • Navne på metoder (main, setVisible, osv.)
    • Navne på interfaces (Runnable, Remote, osv.)
    • Navne på variable (count, visible, osv.)
    • Navne på argumenter (args, title, osv.)
    • Programeksempler.

 

  • Generelt bruges ikke parenteser efter navne på metoder og constructors. Det vil altså sige, at man skriver getName i stedet getName(). getName() bruges kun, hvis man vil understrege, at det er den getLabel-funktion, der ingen parametre tager, man refererer til.
  • Hvis det er muligt, så brug udtryk i stedet for hele sætninger, hvis meningen forbliver den samme. For eksempel@param title    den titel, vinduet skal havei stedet for

    @param title    Title angiver navnet på vinduet.

  • Man bør bruge tredje person i stedet for anden person. For eksempelSætter dette vindues titeli stedet for

    Sæt vinduets titel

  • Da metoder angiver en handling, bør beskrivelsen af dem starte med et udsagnsord. Dette inspirerer også folk til at bruge udtryk i stedet for hele sætninger. Det vil sige, atSætter dette vindues titel
    er at foretrække, fremfor
    Denne metode sætter titlen på dette vindue.
  • Ved beskrivelser af klasser, interfaces og felter, kan man undlade grundledet og i stedet bare beskrive objektet. For eksempel
    En knap
    i stedet for
    Dette element er en knap.
  • Mange funktionsnavne forklarer sig selv. I disse tilfælde bør man tilstræbe at beskrivelsen af funktionerne ikke bare gentager funktionsnavnet i en sætning. For eksempel er beskrivelsen/**
    * Sætter vinduets titel
    *
    * @param title    vinduets titel
    * / 

    public void setWindowTitle (String title) { … }

    ikke meget værd. I stedet bør man tilføje noget information, man ikke umiddelbart kan se ud af signaturen:

  • /**
    * Sætter en brugerdefineret titel. Titlen vises i vinduets
    * titellinie.
    * Indtil denne metode kaldes, er titlen ”Java vinduer”.
    *
    * @param titel    Den tekst, der skal skrives i titellinien.
    * Hvis <code>null</code>angives ændres titlen ikke.
    */
  • Udtryk, der bruges i stedet for hele sætninger, skal ikke starte med stort bogstav og skal heller ikke afsluttes med et punktum:@param x    x-koordinaten.
  • Sætninger skal starte med et stort bogstav og skal også afsluttes med et punktum.
  • Hvis en beskrivelse består af flere sætninger, skal de generelle regler om tegnsætning benyttes.
  • Hvis flere udtryk benyttes skal de adskilles med semikolon.
  • Hvis man både benytter et udtryk og en sætning, skal udtrykket ikke starte med stort, men skal afsluttes med et punktum for at adskille det fra sætningen. Sætningen startes med stort begyndelsesbogstav og afsluttes med punktum.

 

 

Et eksempel

 

Dette afsnit vil vise et eksempel på brugen af JavaDoc. Eksemplet tager udgangspunkt i en graph-pakke, der indeholder forskellige grafiske klasser. I dette eksempel er klassen  PieChart vist. Nedenfor er JavaDoc-koden til dokumentation af klassen vist:

package graph;

import java.util.Vector;

import java.awt.Graphics;

/**

* PieChart-klassen definerer et cirkeldiagram. Cirkeldiagrammet

* er en cirkel, der er inddelt i skiver, hvor hver skive har en

* størrelse svarende til den tilknyttede værdi.

* <p>

* Grafen kan – men behøver ikke at – have et 3D-udseende.

*

* @author    Kristian Hansen

*/

 

public class PieChart

{

 

/**

* Default constructor. Opretter et cirkeldiagram uden 3D-udseende.

*/

 

 

 

public PieChart()

{

// …

}

 

/**

* Constructor, der tillader klienten at angive, om grafen skal have

* et 3D-useende.

*

* @param is3D    angiver om grafen skal have et 3D-udseende.

*/

 

public PieChart (boolean is3D)

{

// …

}

 

/**

* Angiver de værdier, der bruges til at tegne grafen. Værdierne gemmes i

* en <code>Vector</code> og skal kunne castes til en <code>Integer</code>.

*

* @param values    de værdier, der bruges, når grafen tegnes.

*

* @see java.lang.Integer

* @see java.util.Vector

*/

 

public void setValues (Vector values)

{

// …

}

 

/**

* Tegner grafen på det angivne <code>Graphics</code> object.

* Opdelingen af grafen bestemmes på baggrund af de værdier, der er angivet

* med <code>setValues</code>-metoden.

*

* @param g    Det <code>Graphics</code>-objekt, der skal tegnes på

*

* @exception  NoValuesException    opstår, hvis denne metode kaldes

*                                  før <code>setValues</code>.

* @see java.awt.Graphics

* @see #setValues

*/

 

public void draw (Graphics g)

{

 

// …

}

}

 

Dokumentationen er blevet genereret ved hjælp af nedenstående kommando:

 

javadoc -sourcepath . -d docs\ -verbose -author -classpath %classpath% -J-mx32m -J-ms32m graph

 

Kommandoen bruger det aktuelle katalog som sourcepath og kataloget docs\ som output-katalog. For at kunne referere til klasser udenfor pakken, angives også classpath’en. For at sikre at programmet har hukommelse nok at arbejde med, bruges –J til at reservere 32 MB.

 

Kommandoen resulterer i nogle HTML-dokumenter, der ser således ud:

 

Figur 10-2: Dokumentationen til graph-eksemplet.

 

Sammenfatning

I dette kapitel er det blevet gennemgået, hvordan man kan bruge programmet JavaDoc til at udarbejde dokumentation af et program. Mulighederne i JavaDoc er blevet beskrevet, og det er ligeledes gennemgået, hvordan man skal angive kommentarerne i kildeteksten.

FAQ

 

Jeg har installeret JDK 1.2, men vil gerne generere JavaDoc-filer, der ligner de fra JKD1.2. Behøver jeg at installere JDK 1.1 for at kunne det?

 

Nej, men man kan ikke bruge den JavaDoc, der ligger i bin-biblioteket. I stedet skal programmet OldJavaDoc bruges. Det er en kopi af det JavaDoc-program, der fulgte med tidligere versioner af JDK. Det betyder også, at man skal være opmærksom på, at det ikke er alle de options, der er blevet gennemgået i dette kapitel, der er implementeret.

 

Når jeg bruger OldJavaDoc eller JavaDoc fra JDK 1.1, mangler der nogle billeder i dokumentationen. Hvorfor det, og hvor finder jeg billederne?

JavaDoc fra JDK version 1.2 benytter sig af tabeller og forskellige skrifttyper for at lave et pænt layout. I tidligere version blev gif-billeder

 

brugt til at opnå denne effekt. Disse billeder, bliver ikke leveret sammen med JavaDoc-programmet, men har man downloadet Suns dokumentation til den pågældende JDK, kan man finde dem i biblioteket docs\api\images\.

 

Jeg har lige genereret dokumentation med JavaDoc, men når jeg klikker på en henvisning til en af klasserne i JDK, får jeg at vide, at den ikke kan finde filen. Hvad er der galt?

 

JavaDoc antager, at al dokumentationen – det vil sige alle HTML-dokumenterne – befinder sig i det samme bibliotek. Er det ikke tilfældet, kan programmet ikke finde ud af at lave henvisningerne rigtigt.

 

Med JavaDoc fra JDK version 1.0 eller 1.1 er løsningen på problemet at generere dokumentationen for alle pakker samtidigt – det tager et stykke tid og kræver, at man har kildeteksten til alle klasser, men er desværre den eneste udvej.

 

 

 

Bruger man i stedet JavaDoc fra JDK version 1.2, kan man ved hjælp af options som –linkall og –overview angive, hvordan JavaDoc skal håndtere henvisninger til dokumentation, der er genereret tidligere.

 

Jeg kan ikke få JavaDoc til at generere dokumentation for al kildeteksten? Hvad kan jeg gøre for at få det til at virke?

Hvis du bruger JavaDoc fra JDK version 1.1, kan det skyldes, at der er brugt navne, der indeholder understregninger eller andre tegn, der ligger udenfor A-Z, a-z, 0-9 og punktum.

 

Jeg får en fejlmeddelelse om, at der ikke er tilstrækkeligt hukommelse. Hvor meget hukommelse kræver JavaDoc?

Sun siger, at JavaDoc version 1.1 brugte 40 MB til at generere dokumentationen til JDK version 1.1, mens JavaDoc version 1.2 brugte 70 MB til at generere dokumentationen til JDK version 1.2. Ved hjælp af –J kommandoen er det muligt at angive, hvor meget hukommelse JavaDoc skal reservere. Vil man reservere 40 MB, skal man skrive

 

Javadoc –Jms39m –Jmx40m

 

Der er en fejl i JavaDoc version 1.1.2, der gør, at ms skal være mindre end (ikke lig med) mx. Denne fejl er rettet i version 1.2.

 

JavaDoc version 1.1 ser ud til at blive kørt succesfuldt, men indeks-siden er tom. Hvad sker der?

Dette skyldes en fejl i JavaDoc version 1.1, og problemet opstår ikke i JavaDoc 1.2. Den tomme indeksside opstår, når man har et element i kildetekst, der starter med en understregning. For eksempel

 

public class MinKlasse

{

protected int _integer;

 

 

}

 

Problemet kan også opstå, hvis man har en klasse, der kun indeholder statisk kode. For eksempel

 

public class EndnuEnKlasse

{

static

{

System.out.print(“Indlæser…”);

}

}

 

I så fald har klassen ingen signatur, og det forvirrer JavaDoc.

 

Du læser en gammel bog
Den bog, du læser her, er fra 1998, og mange ting kan have ændret sig siden da.
Vi håber, at du stadig kan finde relevant information i den.
Hvis du vil læse aktuelle oplysninger om de avancerede dele af Java, anbefaler vi
bogen Core Java – Advanced Features

Comments are closed.