> Bryce McKinlay wrote: > Good question. As you point out, getSystemClassLoader() will give the > application classloader, so if we use the result of > getSystemClassLoader(), then resources could be loaded from the > application classpath instead of just the bootstrap classpath (ie > glibj.jar). Which one we want depends on whether users/applications > should be able to add their own locale data independently of > Classpath's. I'm not sure whether that would be a useful feature, but > I'm going on the assumption that its not really a _bad_ thing. > Any opinions?
I don't know enough about where these resources are supposed to be loaded from to know whether a user/application should be able to define them locally. But if they are allowed to do so, then it would seem to me that the calls to load the resources must always use the current classloader (the context classloader?) to ensure that locally defined resources are found. In which case any attempt to pre-cache the classloader to use (even if the one from getSystemClassLoader) could be incorrect as it could lead to a failure to load the resource. On the other hand, if we know these resources must be loaded from the application classpath, then caching the system/application class loader would be fine. David Holmes _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
