quick question…when doing quick tests on different things i usually cut'n'paste stuff from the jme tests and allways have to change the class-specific call for getResource…like:
TestMultitexturePass.class.getClassLoader().getResource(…)
why not just change all tests etc to:
getClass().getClassLoader().getResource(…)
or does that introduce any problems?
It does: when you subclass a class doing getClass().getResource() and your subclass is in another package the superclass does not find its resources anymore (under some circumstance it still does, yes, but most likely not).
oh, and with getClass().getClassLoader().getResource() you cannot use relative paths (not used in jME either way afaik) and get the same problem for different jars (not packages)
get your point…i would never do it in a core-class that was meant to be extended…just the TestXXX classes
Hmm, I find it a bit tedious to alter those references, too. But I think we should keep it that way as the Tests tell people what they should do - it's some kind of documentation/tutorial. So I think we shouldn't have anything in there that we think is bad practice.
good points! question answered 
irrisor said:
oh, and with getClass().getClassLoader().getResource() you cannot use relative paths (not used in jME either way afaik) and get the same problem for different jars (not packages)
I don't think this is true....I use it frequently as a direct alternative to MyClass.class.getClassLoader()... and I believe it's exactly the same thing just referencing your class via instance. The big problem I have with it though is when I'm trying to do something via a static method and I have to reference the static class to get it.
I often have like a Util object in my projects that I would add something like this to and just have Util.getResource(...) and internally it could call the Util.class.getClassLoader().getResource(...) so we can copy and paste anywhere in our projects and that can remain the same. Thoughts on this?
darkfrog
darkfrog said:
and I believe it's exactly the same thing just referencing your class via instance.
It is not - as I said it references a different class (the subclass obviously) and thus a different classloader if those classes have been loaded with a different one. (Of course it does not matter if all classes have been loaded with the system classloader, it does matter if you use webstart or e.g. the eclipse plugin framework)
Anyways your suggestion to use a Utility class for obtaining urls is good. I think most people do something similar in all bigger apps.
My mistake Irrisor, I misread your statements and thought they were two separate statements…I didn't put two and two together…now I understand, and knowing's half the battle. 
(sorry, just recollecting the days of G.I. Joe)
darkfrog
I may have screwed up with most of the getClassTag() implementations for Savables then?
I return this.getClass() for most classes thinking that it would save work and subclasses would only need to override it if they are a special case (see render states). I didn't really think of subclasses loaded with a different classloader.
mojomonk said:
I didn't really think of subclasses loaded with a different classloader.
...me neither...
mojomonk said:
I may have screwed up with most of the getClassTag() implementations for Savables then?
No. For obtaining the class of an object it is fine.
The only problem with classloaders and storing objects occur here:
String savableName = savable.getClassTag().getName();
and
return (Savable)Class.forName(className).newInstance();
You would probably need to store info about a classloader or factory when the class cannot be found by the context classloader while loading from file. But this should not be a problem in most applications (i.e. webstart). It would become a problem with an eclipse application that uses jME as a plugin (but e.g. MonkeyWorld does not do that).
But still - when this occurs some time in the future getClassTag implementation would be fine :)