Browsing files in jar and outside jar

Newbie & Debugging Questions
#1

Ok, in my solitaire software (version 0.3 will be public soon) I wanto to use multiple cards and deck backside. The technique I used to provide themes i pretty simple: for cards every subdirectory in imgs/cards is a deck theme, and for the cards backside the program should look in imgs/backs.

The only problem is that, after a week of tampering I was unable to browse effectively the files available in the jar and othside the Jar.

(In the Jar)
I can access single reources with ClassLoader.getResource() and getResourceAsStream() but as far I tried I cannot use File to enumerate the files in a directory (for example to browse the backsides…).
Another thing I noticed in many other apps for java is that usually the program can check for data in the folders in the jar or in a same folder placed at the jar level where the application is installed (since my solitary architecture is pluggable this is a must to allow others to add their solitaires preserving the application integrity).

(Outside Jar)
Another thing that bothers me is that File seems not be able to resolve relative pathnames in Windows, no matter i use “imgs\” or “.\imgs\” to locate the imgs directory it will fail always. Only if I provide the integral pathname of the directory it will locate it and let me browse files.
I tried system preferences to retrieve the path where the application is installed but the only place is store is in the classpath, togheter with other directories (and how the program will know where the user put it?).

#2

Okay, inside the jar you need to open a JarInputStream and parse it manually. The URL returned from getResource isnt a file URL in this case, its a jar entry URL which is why you cannot open it as a file. Forget getResource and scan the jar yourself. OR put a text list of your files in a well known place so you can use getResource to get it and then use it to get the rest.

Outside the jar you need to use System.getProperty(“user.dir”) to get the CWD and append it to your file path.

#3

Huh? That returns the CWD?

More to the point, why isn’t the CWD correctly set automatically? I know it is for a “normal” installation, and the only times I remember problems with this were e.g. with J2EE implementations that started java from some weird and wonderful places, and loaded your WAR/JAR from somewhere else entirely.

#4

Is there an RFE for this? I’d actually thought it was in the standard libraries by now (1.5?) but I haven’t looked at it in ages…

#5

Thanks Jeff, it works.

But only if I run the JRE in the console from the same directory of the jar/class files, otherwise it returns the working path of the java executable.
It works also if I prepare a shortcut with the given working directory in Windows.

Any deployment hints? Will Webstart set it up by itself the right way (cannot try because don’t have a web server configured to handle jnlp properly right now)?
I have to provide some installation/running script (that can be broken easily and is hard to work with for the average user - expecially for Windows users -)?

#6

[quote]Thanks Jeff, it works.

But only if I run the JRE in the console from the same directory of the jar/class files, otherwise it returns the working path of the java executable.
It works also if I prepare a shortcut with the given working directory in Windows.
[/quote]
Right because if you double click a document in Windows, the CWD is set to the dir of the executing program.

So yes if you don’t do something to make sure your CWD is set right (eg set by a shortcut or run from the console after you CD to the app dir) you wont get the right answer.

GIGO :slight_smile:

#7

Wouldn’t it be great if there was a Java API to change the CWD? :slight_smile:

#8

…or just an API to retrieve the path of the class starting the application (assuming that as application root)

…or the path of the class file the current instance is based of

I must also admit that knowing too much on the application surroundings can be prone to security exploits if the application is allowed to have unlimited control on the machine.

Doh! for example an app with a pluggable interface (like mine) can be prone to maliciuos pluggable classes (maybe is better using a data file for defining solitaires and a simple editor???)

#9

These are all things that Tomcat users were begging for circa 4 years ago (TC was a proverbial steaming pile back then, and sooooo many people couldn’t run servlets etc because of these CWD issues).

Hence I’d assumed Something Had Been Done by now…