---

Hej

Jeg skal for første gang beskæfte mig med pakke der ikke ligger i sdk'en,
men jeg fatter ikke helt hvordan.

f.eks.
import org.kxml2.io.*;

hvor skal org-mappen (og undermapper ligge)? og hvad er det der
org-egentlig?

--
/rasmus
"Only wimps use tape backup. Real men just upload their important stuff on
ftp, and let the rest of the world mirror it." - Linus Torvalds

---

Rasmus Skov wrote:
> Hej
>
> Jeg skal for første gang beskæfte mig med pakke der ikke ligger i sdk'en,
> men jeg fatter ikke helt hvordan.
>
> f.eks.
> import org.kxml2.io.*;

OK.
Først og fremmest er der ikke noget særligt ved "import".

"Import com.foo.bar.*" betyder bare "Jeg er lidt doven, så kære Java
compiler, når jeg skriver en type i mit program, gider du så ikke lige,
hvis du ikke kan finde typen, at prøve at sætte com.foo.bar. foran og
prøve igen ?"

Således må man selvom man vil skrive

import java.util.*;
class Stinker {
// blah blah
List myList = new ArrayList();
}

eller
class SuperStinker {
// blah blah
java.util.List myList = new java.util.ArrayList();
}

men det vidste du nok godt.

Når du compilerer din Java, skal compileren jo have adgang til alle de
typer der nævnes i din sourcekode, for at se at du ikke refererer til
noget som ikke findes i typerne.

Der er 4 muligheder:
1) Der refereres til noget der følger med JDKen. Det findes automagisk
2) Der refereres til nogle eksterne klasser, f. eks. jakarta-log4j.
Derfor skal du have classpath til at gå igennem det sted hvor denne kode
ligger. Hvis det er en jar fil, skrives hele filnavnet ind med i
classpath. Hvis det er et directory, som
c:\JavaLibs\SmellysJavaUtilities\build\
hvor UNDERdirectories hedder det samme som de packages du refererer til,
så tager du directoryet med i classpath.
Altså hvis du har, i dit program:
import com.foo.bar.*;
....
Skunk stinkdyr = new Skunk();

eller, som jeg nævnte ovenfor, måske istedet:

com.foo.bar.Skunk stinkdyr = new Skunk();

og du har downloadet Smelly's Super Stinkin' Java extensions, fordi du
ved at her ligger en god implementation af Skunk, og har pakket det ud
til directoriet:

c:\JavaLibs\SmellysJavaUtilities

så du her kan se class-filen:

c:\JavaLibs\SmellysJavaUtilities\build\com\foo\bar\Skunk.class

så er det c:\JavaLibs\SmellysJavaUtilities\build som skal med i classpath.

3) Der refereres til noget source, et andet sted fra. Kig på
--sourcepath parametren til javac for dette.
4) Der refereres til en anden klasse i din egen sourcekode. Dette hitter
javac ud af - vistnok ved at søge i sit eget output.

Den nemmeste måde at tage noget med i classpath er, synes jeg
efterhånden, er IKKE at bruge CLASSPATH environment variablen. Det er
bedre (synes jeg) at lave Ant-scripts (for de lidt mere erfarne), eller
at skrive det hele manuelt, som :

javac -classpath c:\JavaLibs\SmellysJavaUtilities\build;
-sourcepath src\
-d my_build\
src\*.java

og så bare bruge cursor-up i shellen til at builde forfra når du retter
noget.
-d er bare hvor javac skal smide de classfiler den laver.

MVH
Søren

---

"Rasmus Skov" <news@aey.dk> wrote in message
news:40916bca$0$28434$d40e179e@nntp05.dk.telia.net...

[Klip]

Søren har allerede svaret på resten af beskeden, men jeg vil da godt lige
knytte en kommentar til dette:

> hvad er det der
> org-egentlig?

Alle pakker i Java skal være unikke, men det behøver klasse navne ikke at
være. Der findes f.eks. to Date klasser i Java standart API'et:
java.util.Date og java.sql.Date. Når jeg skriver:

Date myDate = new Date();

Så kan Java kun vide hvilken Date klasse jeg ønsker, fordi de har hver sin
package. Jeg er altså nødt til at specificere hvilken Date jeg er
interesseret i. Det kan jeg f.eks. gøre således:

import java.util.Date;
....
Date myDate = new Date();

eller jeg kan skrive:

java.util.Date myDate = new java.util.Date();

Hvis du laver software som potentielt kan anvendes af andre på et tidspunkt,
eller hvis du vil anvende andres software, er det vigtigt at package navne
er globalt unikke. Derfor indleder man typisk sit package navn med sit
domænenavn (i bagvendt rækkefølge), for domæne navnene er jo unikke på tværs
af organisationer. Det er så op til den enkelte organisation hvordan de vil
administrere package navnene internt. De ikke-offentlige klasser bag Java
standard API'et starter derfor ofte med com.sun, alle de Open Source
software løsninger fra Apache Jakarta projektet starter med org.apache, osv.

Venlig hilsen

Anders