On Thu, Jul 21, 2011 at 12:26 PM, Christopher Schultz <[email protected]> wrote: > All, > > In a somewhat unrelated thread on the user's list, Nathan and I have > been discussing changing the ClassUtils.getResource method from calling > (in order): > > Thread.currentThread.getContextClassLoader().getResource() > ClassUtils.class.getResource() > callingObject.getClass().getResource() > > This is the current code in that method: > > 1 public static URL getResource(String name, Object caller) > 2 { > 3 URL url = getThreadContextLoader().getResource(name); > 4 if (url == null) > 5 { > 6 url = getClassLoader().getResource(name); > 7 if (url == null) > 8 { > 9 url = ClassUtils.class.getResource(name); > 10 if (url == null && caller != null) > 11 { > 12 Class callingClass = caller.getClass(); > 13 if (callingClass == Class.class) > 14 { > 15 callingClass = (Class)caller; > 16 } > 17 url = callingClass.getResource(name); > 18 } > 19 } > 20 } > 21 return url; > 22 } > > I will be removing lines 6-8 and 19 because calling Class.getResource is > the same as calling Class.getClassLoader.getResource. > > I was wondering about the additional work of calling > callingClass.getClass() and then re-setting callingClass to "caller" > which is a java.lang.Class. I'm pretty sure if "caller" is already a > java.lang.Class, then the getClass method will just return "this", so
if java.lang.Class overrides the getClass() method it inherits from Object, that is news to me. i'm stuck in javascript land right now and am too lazy to fire up a JVM before writing this, but i'm fairly certain that doing ClassUtils.class.getClass() returns Class and not ClassUtils > there's no real good reason to re-check the object, cast the "caller" > reference to java.lang.Class and re-set the "callingClass" local. > > Maybe something is going on that I don't understand. Before I "simplify" > this code, I wanted to make sure that nobody had a specific reason for > performing this awkward manipulation of object references. If the idea > was to avoid a method call in favor of an instanceof and then checkcast > operation, I'm not sure there's any savings, there: you should just > write the code in a straightforward way so bugs don't creep-in. no, the idea was that the caller argument could be either an instance of the class (new Foo()) or the class itself (Foo.class). > > If anyone has any thoughts, please let me know. Otherwise, I'll be > reducing the complexity of this code. > > Thanks, > -chris > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
