/ Forside / Teknologi / Udvikling / Java / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Java
#NavnPoint
molokyle 3688
Klaudi 855
strarup 740
Forvirret 660
gøgeungen 500
Teil 373
Stouenberg 360
vnc 360
pmbruun 341
10  mccracken 320
Hvorfor kan jeg ikke se mine ikoner?
Fra : Janus


Dato : 26-05-06 17:42

Hej NG!

Jeg har et projekt i Eclipse, hvor jeg i min GUI forsøger at benytte mig
af ikoner fra jlfgr-1_0.jar filen. Biblioteksstrukturen er som følger:


MyProject
start
etc

I package etc ligger jlfgr-1_0.jar.
I package start ligger så Start.java, hvori jeg forsøger at gøre følgende:

JMenuItem menuItemAbout = new JMenuItem("About", new
ImageIcon("toolbarButtonGraphics/general/About16.gif"));

I Eclipse er jar-filen både med i Classpath og Source. (Create, manage
and run applications).

Meeen ... det virker ik'. Er det fordi man ikke kan tilgå andet end
deciderede javafiler i en .jar, eller er det bare mig, der mangler en
pointer til den jar-fil et sted? Har prøvet at rykke rundt på jar-filen,
men det hjælper heller ikke...


Pft,

Janus

 
 
Niels Dybdahl (31-05-2006)
Kommentar
Fra : Niels Dybdahl


Dato : 31-05-06 08:07

> Meeen ... det virker ik'. Er det fordi man ikke kan tilgå andet end
> deciderede javafiler i en .jar, eller er det bare mig, der mangler en
> pointer til den jar-fil et sted? Har prøvet at rykke rundt på jar-filen,
> men det hjælper heller ikke...

Jeg plejer at loade billeder fra Jarfilen ved hjælp af:

Toolkit toolkit = Toolkit.getDefaultToolkit();
URL imgURL=parent.getClass().getResource("images/"+iconFilename);
if (imgURL==null || imgURL.getFile()==null || imgURL.getFile()=="")
throw new FormattedException(...);
Image image = toolkit.getImage(imgURL);

Billederne er i dette tilfælde placeret i en undermappe ("images") i forhold
til en eller anden klasse (parent).

Niels Dybdahl



Janus (31-05-2006)
Kommentar
Fra : Janus


Dato : 31-05-06 16:03

Hej Niels.

Dit forslag må jeg lige prøve på et tidspunkt :)
Mit spørgsmål kan også tolkes som af mere generel karakter: Når man i
sin classpath har en jar-fil, som indeholder klassefiler, kan man blot
tilgå disse ved deres navn, så som mypackageinjar.subpackage.MyClass.
Men hvis jar-filen indeholder ikke-java materiel så som billeder, skal
man åbenbart behandle dem anderledes, i Niels' eksempel som en datakilde
der skal tilgås via ToolKit.

Hvordan kan det være?


Vh Janus


Niels Dybdahl wrote:

> Jeg plejer at loade billeder fra Jarfilen ved hjælp af:
>
> Toolkit toolkit = Toolkit.getDefaultToolkit();
> URL imgURL=parent.getClass().getResource("images/"+iconFilename);
> if (imgURL==null || imgURL.getFile()==null || imgURL.getFile()=="")
> throw new FormattedException(...);
> Image image = toolkit.getImage(imgURL);
>

Johnnie Hougaard Nie~ (31-05-2006)
Kommentar
Fra : Johnnie Hougaard Nie~


Dato : 31-05-06 19:59

Janus wrote:
> Men hvis jar-filen indeholder ikke-java materiel så som billeder, skal
> man åbenbart behandle dem anderledes, i Niels' eksempel som en datakilde
> der skal tilgås via ToolKit.

Nej, ikke-class filer i en jar skal ikke behandles via Toolkit. Kernen
er at du f.eks kan:
InputStream is = getClass().getResourceAsStream("/resources/" + fn) ;
Eller
URL resource = getClass().getResource("/resources/" + fn) ;
Tingene bliver dog mere komplicerede hvis du har behov for en anden
classloader end den som har loaded den kaldende klasse. Men så længe
klasser og resource-filer ligger i samme jar, plejer det at gå nemt.

Skråstregen i starten af mine eksempel navne giver søgning i roden af
classpath; uden skråstreg søges der i eller under den aktuelle pakke.

/Johnnie

Janus (07-06-2006)
Kommentar
Fra : Janus


Dato : 07-06-06 16:11

Johnnie Hougaard Nielsen wrote:
> Janus wrote:
>> Men hvis jar-filen indeholder ikke-java materiel så som billeder, skal
>> man åbenbart behandle dem anderledes, i Niels' eksempel som en
>> datakilde der skal tilgås via ToolKit.
>
> Nej, ikke-class filer i en jar skal ikke behandles via Toolkit. Kernen
> er at du f.eks kan:
> InputStream is = getClass().getResourceAsStream("/resources/" + fn) ;
> Eller
> URL resource = getClass().getResource("/resources/" + fn) ;

Okay, men for at få tilgang til dem, skal de stadig behandles
"anderledes" end Class-filer, hvis tilgangsmetode er, som lå de ikke i
en Jar-fil?

Eksempelvis:
Jeg laver en MyJar.jar og lægger 2 filer i den: HelloWorld.class og
flower.GIF. Herefter hæfter jeg MyJar.jar til min classpath.

I mit program kan jeg nu tilgå ressourcen HelloWorld.class ved at
skrive: HelloWorld hw = new HelloWorld();

Men jeg kan ikke tilgå ressourcen flower.GIF på samme simple måde:
JMenuItem menu = new JMenuItem("Pretty", new ImageIcon("flower.GIF"));


Er det korrekt? Og i så fald, skal jeg så gøre noget lignende dette:

JMenuItem menu = new JMenuItem("Pretty", new
ImageIcon(getClass().getResource("flower.GIF")));

(Jeg kan ikke afprøve det på dette tidspunkt, derfor spørgsmålet)


Mvh Janus

Johnnie Hougaard Nie~ (07-06-2006)
Kommentar
Fra : Johnnie Hougaard Nie~


Dato : 07-06-06 23:59

Janus wrote:
> Okay, men for at få tilgang til dem, skal de stadig behandles
> "anderledes" end Class-filer, hvis tilgangsmetode er, som lå de ikke i
> en Jar-fil?

Tjah, forskellen er såmænd ikke så stor endda. ImageIcon arbejder
grundlæggende på URL objekter, og constructor'en med String kan egentlig
betegnes som en convenience constructor, der (i princippet) laver et
filnavn om til en URL, i stedet for at du selv gør det.

Og ja, der er jo forskel på hvordan et URL objekt instantieres, afhængig
af hvor data ligger. En classpath søgning er noget andet end at henvende
sig direkte til filsystemet. Sånt er livet.

Men det med at lave en URL har INTET specielt med jar filer at gøre; det
kører ligeså godt alligevel, så længe at image filen er tilgængelig på
classpath.

I øvrigt ser jeg at ImageIcon internt bruger Toolkit til at tage fat i
image filen.

> Er det korrekt? Og i så fald, skal jeg så gøre noget lignende dette:
>
> JMenuItem menu = new JMenuItem("Pretty", new
> ImageIcon(getClass().getResource("flower.GIF")));

Jeg vil gætte på at det virker; som skrevet også selv om du ikke jar'er
din runtime. Men Swing er det lykkedes mig at holde mig fra

Janus (08-06-2006)
Kommentar
Fra : Janus


Dato : 08-06-06 08:39

Johnnie Hougaard Nielsen wrote:

> Og ja, der er jo forskel på hvordan et URL objekt instantieres, afhængig
> af hvor data ligger. En classpath søgning er noget andet end at henvende
> sig direkte til filsystemet. Sånt er livet.

Ah, i så fald vil det ikke være helt forkert at tolke class path'en som
JRE'ens lokale filsystem?

> Men det med at lave en URL har INTET specielt med jar filer at gøre; det
> kører ligeså godt alligevel, så længe at image filen er tilgængelig på
> classpath.

Jæs jæs, den er jeg med på :) Jeg har bare haft opfattelsen, at JAR
filers indhold på run time tidspunktet automatisk blev "pakket ud",
hvorfor det i så fald skulle virke at tilgå flower.GIF uden at bruge
getResource(). Nu er jeg blevet så meget klogere, mange tak for hjælpen!

Slutteligt kan jeg da lige tilføje, at jeg har prøvet med getResource()
nu, og det virker!


Med venlig hilsen Janus

Thorbjørn Ravn Ander~ (08-06-2006)
Kommentar
Fra : Thorbjørn Ravn Ander~


Dato : 08-06-06 09:28

Janus <invalid@invalid.dk> writes:

> Ah, i så fald vil det ikke være helt forkert at tolke class path'en
> som JRE'ens lokale filsystem?

Sådan kan man vælge at se på det. Classpath er der hvor
standardclassloaderen kigger efter ting, og resourcer indlæses via
classpath.

> Jæs jæs, den er jeg med på :) Jeg har bare haft opfattelsen, at JAR
> filers indhold på run time tidspunktet automatisk blev "pakket ud",

Nøp.

--
Thorbjørn Ravn Andersen


Johnnie Hougaard Nie~ (08-06-2006)
Kommentar
Fra : Johnnie Hougaard Nie~


Dato : 08-06-06 09:57

Janus wrote:
> Ah, i så fald vil det ikke være helt forkert at tolke class path'en som
> JRE'ens lokale filsystem?

Den analogi kan et stykke vej fungere. Når tingene bliver mindre end
simple bryder den sammen, og det vil være mere rigtigt at sige at
en classpath kan hente fra et af operativsystemets filsystemer, men kan
en del mere end et filsystem.

Forskellen begynder at markere sig ifm flere classloadere, sikkerhed og
de finurligheder som kan styres via jar manifest filer. Visse måder at
køre en jar-pakket applikation på vil aktivt adskille denne fra hvad der
ligger uden for jar filen, som f.eks. classpath system property.
Et typisk eksempel er "java -jar myappl.jar".

Søg
Reklame
Statistik
Spørgsmål : 177438
Tips : 31962
Nyheder : 719565
Indlæg : 6408043
Brugere : 218879

Månedens bedste
Årets bedste
Sidste års bedste