getResource() findet nur bestimmte Dateiformate

SCrackerX

Grünschnabel
Hallo,
ich habe ein Problem mit der getResource()-Methode. Sie liefert für einige Dateiformate 'null'. Das selbe gilt für getResourceAsStream(). Bisher habe ich nur PNG-Dateien bezogen und da gab es keine Probleme. Ich habe eine gültige URL bekommen und konnte so auf die Datei zugreifen. Als ich nun aber eine Schriftart laden wollte und eine TFF-Datei angegeben habe, bekam ich 'null' zurück. Ich habe anschließend weitere Dateiformate ausprobiert, wie TXT, WAV, BMP und bei allen war das selbe Problem.
Am falschen Pfad kann es eigentlich nicht liegen, bei den PNGs habe ich es ja auch richtig gemacht.. Mein Betriebssystem ist Windows 7 64bit, als IDE nutze ich IntelliJ IDEA 10 und meine Java-Version ist 1.6.0_24.
Funktioniert die Methode nicht mit allen Dateiformaten oder wo liegt das Problem?

Ich wäre sehr dankbar, wenn mir jemand helfen könnte!
 
Hi,

soweit ich weiß klappt die methode ja nur, wenn die datei auch bei der class datei ist, (falls das nicht so ist, bitte verbessern). sollte deine datei also auch im selben path sein wie die class datei die du gerade ausführst, sollte es kein problem sein.

Code:
public class Test {
	
	public Test() {
		System.out.println(getClass().getResource("txt.txt"));
		System.out.println(getClass().getResource("bmp.bmp"));
		System.out.println(Test.class.getResource("txt.txt"));
		System.out.println(Test.class.getResource("bmp.bmp"));
	}
	
	public static void main(String[] args) {
		new Test();
	}
}

Output:
file:/C:/Users/Maik/workspace/Test/bin/txt.txt
file:/C:/Users/Maik/workspace/Test/bin/bmp.bmp
file:/C:/Users/Maik/workspace/Test/bin/txt.txt
file:/C:/Users/Maik/workspace/Test/bin/bmp.bmp

Grüße Maik
 
Da muss ich dich jetzt aber korrigieren : man kann ClassLoader.getResource() auch ABSOLUTE Pfadangaben übergeben die dann auch erfolgreich geladen werden.

@TO
ClassLoader.getResource() funktioniert grundsätzlich mit ALLEM was du ihm übergibst. Dein Problem wird sein das die entsprechenden Dateien nicht gefunden werden. Das ist ins besondere bei RELATIVEN Pfadangaben das Problem. Wenn du z.B. ne Klasse in nem Paket-Pfad hast musst du diesen auch so bei getResource angeben da immer relativ vom ClassLoader gesucht wird. Wenn du als ne Klasse foo.Bar hast und ne Datei im selben Verzeichnis der Class-Datei musst du bei getResource auch foo/File.ext angeben da du ja vom überordner von foo aus startest mit dem Command : java foo.Bar ...
Wie gesagt : probiere es mal mit ABSOLUTEN Pfaden. Das sollte auf jeden Fall funktionieren. Einzige Ausnahme : falscher Pfad oder Datei existiert nicht.
 
Wie gesagt, mit meinen PNGs gab es keine Probleme und die sind auch in verschiedenen Ordnerstruckturen verstreut. Als Beispiel:
Code:
URL resourceURL = Main.class.getClassLoader().getResource("streetfighter/img/menu/MainMenu.png");
System.out.println(resourceURL);
(Die Main.class liegt unter 'streetfighter')
Output:
file:/C:/Users/Public/development/projects_local/StreetFighter/out/production/StreetFighter/streetfighter/img/menu/MainMenu.png

Wenn ich nun aber im selben Verzeichnis ein anderes Dateiformat angebe gibt es Probleme..
Code:
URL resourceURL = Main.class.getClassLoader().getResource("streetfighter/img/menu/test.txt");
System.out.println(resourceURL);
Output:

Ist doch irgendwie seltsam oder?
 
Nach einem kleinen Test weis ich jetzt wo dein Problem liegt : fehlerhafter Dateiname
Ich wette mit dir das deine test.txt in wirklichkeit test.txt.txt heißt ...
Geh mal Systemsteuerung > Ordneroptionen > Ansicht > Erweiterungen bei bekannten Dateitypen ausblenden > Haken raus und OK ... und sieh dir dann mal an wie die Datei WIRKLICH heißt.
Falls das nicht helfen sollte dürfte es ein Rechteproblem sein. Laut Doc ist return nämlich nur dann NULL wenn das Objekt nicht gefunden wurde oder du keine Rechte darauf hast. Und da du die Datei mit dem selben User erstellst mit dem du auch das java-Command startest solltest du zumindest Read/Write Rechte haben. Es gab hier zwar mal n Thread über Unix das man nur Zugriff hat wenn das x-Flag gesetzt ist ... habe mir das aber nicht bis zum Ende durchgelesen und kann daher nicht sagen ob änliches für Windows gilt.
 
Also das Anzeigen der Erweiterungen bekannter Dateitypen habe ich seit Installation meines OS aktiv ;)
Dann muss ich mal schaun, ob es Probleme mit Rechten gibt. Ich habe allerdings jetzt einfach mal die Dateiendung meiner 'test.txt' geändert in 'test.png' (ist jetzt natürlich keine gültige PNG), aber dann funktioniert es wieder.. es scheint also wirklich am Dateiformat zu liegen. Ich versteh das nicht...
 
Ähäm soll ich mal erlich sein : das kann ich einfach nicht glauben. Warum sollte ClassLoader.getResource() in irgendeiner Art und Weise Dateityp-Abhängig sein ? Allerhöchstens ein CUSTOM ClassLoader mit überschriebener getResource Methode könnte ne Prüfung drin haben. Aber das ist hier scheinbar nicht der Fall. Von daher mal bitte mit der CMD checken od das File wirklich so heißt wie du glaubst. Alternativ mal n File-Object des Ordners erstellen und über File.list() dir ne List der gefundenen Dateien holen und dann das String-Array inner for-Schleife ausgeben.
 
Im CMD wird die Datei so angezeigt, wie ich sie angegeben habe. Ich habe jetzt mal ein File-Objekt mit absolutem Pfad erstellt, da konnte ich auf die TXT-Datei zugreifen! Ist halt nur blöd mit absoluten Pfaden zu arbeiten, wenn die Anwendung von überall ausführbar sein soll..
Liegt es vielleicht an der IDE? Ich werde mal versuchen ein Testprogramm im CMD auszuführen.
 
Ok, ich habe endlich herausgefunden, woran es liegt. Nämlich an der IDE^^ Es werden beim Build nicht alle Dateien vom Source-Ordner in den Output-Ordner kopiert.. Weiß jemand warum IntelliJ nicht alle Dateitypen berücksichtigt? Oder kann man angeben welche Dateitypen mit in den Output-Ordner kopiert werden sollen?
 
Habe jetzt auch herausgefunden, dass man in den Projekt-Einstellungen unter 'Compiler' resource pattern angeben kann. Nachdem ich die fehlenden Dateiendungen eingetragen hatte, funktionierte alles ohne Probleme!
Trozdem vielen Dank für die Hilfe! :)
 
Zurück