Re: Opening a file that is on the classpath.
Luke Yan wrote:
in my option, java has two kinds of library, system library and none-system
library (i am not sure whether the names are correct). System library is located
in JRE or JDK directory and none-system library is added to CLASSPATH by user.
So, "getSystemResource()" will find the resource in system library
You guys got me curious, so I looked it up.
<http://java.sun.com/javase/6/docs/api/java/lang/ClassLoader.html#getResource(java.lang.String)>
public URL getResource(String name)
This method will first search the parent class loader for the resource;
if the parent is null the path of the class loader built-in to the
virtual machine is searched. That failing, this method will invoke
findResource(String) to find the resource.
<http://java.sun.com/javase/6/docs/api/java/lang/ClassLoader.html#getSystemResource(java.lang.String)>
public static URL getSystemResource(String name)
Find a resource of the specified name from the search path used to load classes.
This method locates the resource through the system class loader
(see getSystemClassLoader())
So, the static getSystemResource() is like the instance method getResource()
if it were called through the system Classloader instance.
Nothing yet about "system library" vs. "non-system library".
<http://java.sun.com/javase/6/docs/api/java/lang/ClassLoader.html#getSystemClassLoader()>
public static ClassLoader getSystemClassLoader()
Returns the system class loader for delegation.
This is the default delegation parent for new ClassLoader instances,
and is typically the class loader used to start the application.
....
The default system class loader is an implementation-dependent instance of [ClassLoader].
Still nothing yet about "system library" vs. "non-system library".
There isn't such a distinction. The system class loader is often the only
class loader in an application, and loads everything from every class path.
It's only when the application instantiates its own ClassLoaders that the
methods diverge.
--
Lew