java.lang.Object | ||
↳ | java.lang.ClassLoader | |
↳ | dalvik.system.PathClassLoader |
Provides a simple ClassLoader
implementation that operates on a list
of files and directories in the local file system, but does not attempt to
load classes from the network. Android uses this class for its system class
loader and for its application class loader(s).
Public Constructors | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Creates a
PathClassLoader that operates on a given list of files
and directories. | |||||||||||
Creates a
PathClassLoader that operates on two given lists of
files and directories. |
Public Methods | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Returns a string containing a concise, human-readable description of this
object.
|
Protected Methods | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Finds a class.
| |||||||||||
Finds a native library.
| |||||||||||
Finds a resource.
| |||||||||||
Finds an enumeration of URLs for the resource with the specified name.
| |||||||||||
Returns package information for the given package.
|
[Expand]
Inherited Methods | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
From class java.lang.ClassLoader
| |||||||||||
From class java.lang.Object
|
Creates a PathClassLoader
that operates on a given list of files
and directories. This method is equivalent to calling
PathClassLoader(String, String, ClassLoader)
with a
null
value for the second argument (see description there).
path | the list of files and directories |
---|---|
parent | the parent class loader |
Creates a PathClassLoader
that operates on two given lists of
files and directories. The entries of the first list should be one of the
following:
path | the list of files and directories containing classes and resources |
---|---|
libPath | the list of directories containing native libraries |
parent | the parent class loader |
Returns a string containing a concise, human-readable description of this
object. Subclasses are encouraged to override this method and provide an
implementation that takes into account the object's type and data. The
default implementation simply concatenates the class name, the '@' sign
and a hexadecimal representation of the object's hashCode()
,
that is, it is equivalent to the following expression:
getClass().getName() + '@' + Integer.toHexString(hashCode())
Finds a class. This method is called by loadClass()
after the
parent ClassLoader has failed to find a loaded class of the same name.
name | The "binary name" of the class to search for, in a human-readable form like "java.lang.String" or "java.net.URLClassLoader$3$1". |
---|
Class
object representing the classClassNotFoundException | if the class cannot be found |
---|
Finds a native library. This method is called after the parent ClassLoader has failed to find a native library of the same name.
libname | The name of the library to find |
---|
null
if the library
is not found.
Finds a resource. This method is called by getResource()
after
the parent ClassLoader has failed to find a loaded resource of the same
name.
name | The name of the resource to find |
---|
null
if the
resource is not found.
Finds an enumeration of URLs for the resource with the specified name.
resName | the name of the resource to find. |
---|
URL
objects for the requested resource.Returns package information for the given package. Unfortunately, the
PathClassLoader doesn't really have this information, and as a non-secure
ClassLoader, it isn't even required to, according to the spec. Yet, we
want to provide it, in order to make all those hopeful callers of
myClass.getPackage().getName()
happy. Thus we construct a
Package object the first time it is being requested and fill most of the
fields with dummy values. The Package object is then put into the
ClassLoader's Package cache, so we see the same one next time. We don't
create Package objects for null arguments or for the default package.
There a limited chance that we end up with multiple Package objects representing the same package: It can happen when when a package is scattered across different JAR files being loaded by different ClassLoaders. Rather unlikely, and given that this whole thing is more or less a workaround, probably not worth the effort.
name | the name of the class |
---|
null
if there
is not package information available for it