| LadyLucky |
| (stranger) |
| 08/25/03 10:19 PM |
Neat.. .also can extend to loading from a class
|
Great article, I am incorporating this code into our app as I type this.
Question: The way I understand it, loading from a class (as in Class.getResource()) works slightly differently to the classloader, even for that class. So if I have a resource bundled in my package, then I want to load it from the class?
So I think this could be extended to have something like:
class:com.acme.widgets.MyWidget/MyResource.xml
yes? Though then you have to worry about how to load that class. You almost need a URL just for the class :-)
| vlad_roubtsov |
| (member) |
| 08/26/03 01:14 PM |
Re: Neat.. .also can extend to loading from a class
|
If you are already using a well-defined resource naming scheme (inside URLs or otherwise), using Class.getResourceAsStream() offers almost no advantages, IMHO. This method is implemented as a very thin layer of abstraction over ClassLoader.getResourceAsStream(), with the classloader being the classloader that loaded the class in question.
Class.getResourceAsStream() provides a bit of value by supporting package-relative names, but since you already have to name the class in your example I don't think this is a real advantage. Such a class: scheme might be useful in its own right, though: as a scheme for "load this resource using whichever classloader will load this class" type of thing.