Continuing my tests on my hitching problem, I found out that asset loading from the assets.jar IS case sensitive when run from the .jar or the .exe even if jMP will happily load whatever you ask of it without regard for case-sensitivity.
I’d like to know which one is right? Case sensitive or insensitive? Either way it should be consistent in jMP and and jar/exe.
No, it definitely should be considered case sensitive. In jMP it works because its a folder and you use an OS that is oblivious to filename cases 
In release its a jar = classpath = case sensitive.
Windows is not entirely oblivious to case, but yeah. I get what you mean.
Nonetheless, shouldn’t jMP make entirely sure case is respected? It’s so easy to mistype and yes, I do try to double check but those sometimes happen as I’m sure you know.
At least now I know it could lead to problems. So I’ll take an even greater care when typing…
Actually you have teh same problem in any eclipse based stuff. How about just make yourself sure taht you don’t have any case errors?
Always lowercase for assets problem solved.
Yep. You’re right @EmpirePhoenix, but I was sure that the DesktopAssetManager was taking care of the whole thing once the assets were loading in memory or the .jar was “opened”… Now I know better. I usually use CamelCase as it’s a lot easier to understand long comopsite words.
I cannot determine if the case is right when the OS handles upper and lower case the same. I can ask windows and it will give me ambiguous answers, so… 
Well basically you could check fi the loaded Asset file has the same case, windows will return the corect case, just the open/safe stuff ignores case.
But I can ask windows “is it Model? or MOdeL? or model?” and it will always say yes…
No, if you compare it with the case of the File.getName() it will not, only the low level stuff (aka fopen and so are case insensitive)
A string comparison yeah. Still this wont keep one from loading a “MOdEl” instead of a “Model”, which is the main problem. The IDE also displays the correct case, however I cannot force the system to not accept wrong case.
We can do this, but only as an assert or so. We’ll need to query the directory contents each time and check if the file name matches … Probably not worth doing.
I mean, I haven’t looked at the code but I don’t understand why a directory listing is necessary:
[java]
String someFile = “ReAllYMessedUPCaSe.txt”;
File f = new File(someFile);
if( !f.getCanonicalPath().endsWith(someFile) )
// case did not match
[/java]
…or something along those lines.
Please feel free to flog me if I’m wrong… 
When the game queries for a file you do it the way Paul suggests. It doesn’t matter if a file with the same file name exist but the case is wrong, simply reject it (even though the resource could still be the right file). It’s our job (game programmers) to get our names right.
Think of the alternatives and people posting many duplicate posts complaining that their game can’t find the files… I can already read the hate posted.
One way or the other, I will now triple check my file names from now on just to be on the safe side. I’ll also run the dist files more often to make sure things are running as they are in the IDE.
Well I guess a good visible Notice in the JMP / Wiki / FAQ might do it.
The JVM does it, the IDE does it if you try to use a a class name that is wrongly capitalized, I don’t see why the asset manager couldn’t do it too without having to go through hoops.
FileLocator - maybe. I do not see an obvious way how classloader based locator can achieve that (and I think that classloader ones are quite common).
JVM/IDE does it, because contents of the class file contain class name repeated, so it can be checked against the requested name. If you will add a chunk with name to every png file, then yes, it would be possible to check against that.
What about creating a different class - something like CaseValidatingFileLocator? For people concerned with the case errors, they would add it instead of normal FileLocator to their asset manager.
Something like this (typing from my head, so might have errors)
[java]
public class CaseValidatingFileLocator extends FileLocator {
public AssetInfo locate(AssetManager manager, AssetKey key) {
String name = key.getName();
File file = new File(root, name);
if (file.exists() && file.isFile()){
validateFileCase(file,key.getName());
return new AssetInfoFile(manager, key, file);
}else{
return null;
}
}
private static validateFileCase(File file, String name) {
String path = file.getAbsolutePath().replace(File.separatorChar,’/’);
name = name.replace(File.separatorChar,’/’);
if ( !path.endsWith(name) ) {
throw new RuntimeException("Found file with conflicting case, requested " + name + " got " + path);
}
}
}
[/java]
Just give it a go in your code, see if it helps - if yes, you can clean it up and contribute back - maybe it will get included in the jme3.
Once again - NOT TESTED.
I think this is dangerous. Afaik DOS filesystems could report all kinds of shit like MYFIL~1.XML, then it would be completely messed up. We state that the assetmanager is case sensitive. If somebody finds out that isnt so in the project and thus doesn’t believe us thats his fault. I still dont think string comparison is a good idea.
getCanonicalFile() should always report the real file name that OS uses. That’s half of its point, actually. It resolves the abstract File object to a physical File so that you can get accurate information about the actual file on disk.
So you’re saying this will happen on WinXP for example? Afaik internally it uses those strange DOS “8.3” names.
It resolves to the same file you would get from File.listFiles(). So yes, it should be the name the user would see and I’ve tested it on NTFS. I will try to test it on FAT in a second.