AnacondaNet (webstart enabled)

[blahblahblahh]

[quote]Broken you say

The Executable JARred version works fine locally:
http://www.geocities.com/budgetanime/anacondanet.html
[/quote]
Yes, I mean what I say. You can hard-code a path to C:\Windows(something) in a JAR, and it will “work” when run from the command line.

But just because it runs does not mean that your code is correct. It is never ever correct to hard-code C:\ into a java program (unless you are deliberately trying to make it windows only). When you move to webstart, bad programming things like this that you were lucky enough to get away with won’t continue to work for you.

[moogie]

Yes, I mean what I say. You can hard-code a path to C:\Windows(something) in a JAR, and it will “work” when run from the command line.

But just because it runs does not mean that your code is correct. It is never ever correct to hard-code C:\ into a java program (unless you are deliberately trying to make it windows only). When you move to webstart, bad programming things like this that you were lucky enough to get away with won’t continue to work for you.

Ah, now i understand. You are assuming i am using a platform dependant hard coded absolute path…

What i find strange is that there seems to be multiple ways of obtaining the current directory but not all are supported for different deployment options.

[tom]

Ah, now i understand. You are assuming i am using a platform dependant hard coded absolute path…

What i find strange is that there seems to be multiple ways of obtaining the current directory but not all are supported for different deployment options.

The point is that you never need to know the absolute path to current directory. You always use relative paths with the classloader. Then the loading works the same no mather how you deploy…

[moogie]

does it work for directory structures below the current working directory? i.e. “...\data\graphics” etc. I would like to do this so that the resources are not deep in the package structure.

is “.” standard across all platforms?

[blahblahblahh]

NO, files do NOT go deep in the package structure - ever - it’s just that GTGE’s methods (which most of us here have no idea of since we don’t use it) does that for some reason.

Files are loaded from the root of the jar file, so just jar your files, filename1.jpg, f2.jpg, etc, and then use .getResource( “filename1.jpg” ) or getResourceAsStream( “f2.jpg” ) etc.

[tom]

[quote]does it work for directory structures below the current working directory? i.e. “...\data\graphics” etc. I would like to do this so that the resources are not deep in the package structure.

is “.” standard across all platforms?
[/quote]
Well, there is no current directory. There is just the directory structure of the jar. All paths given must be relative to the root. There is nothing below the root. To see how it looks open the jar in WinZip or similar. Make sure the paths are relative. It’s possible to create a zip with full absolute paths, and I don’t think that will work.

You must always use forward slashes. Your always allowed to start with a forward slash. So if you wan’t to get test.jpg in the data\graphics folder you would use “/data/graphics/test.jpg”. That will work on all platforms. In winzip the “path” will be shown as “data\graphics”, “name” as “test.jpg”. If it don’t show that in winzip then you have made a mistake making the jar.