Class loaders's allow an application to dynamically extend a Java application at runtime by loading classes. For each class it loads, the JVM keeps track of which class loader loaded the class. When a loaded class first refers to another class, the virtual machine requests the referenced class from the same class loader that originally loaded the referencing class. Classes loaded by different class loaders are in different name-spaces and cannot gain access to each other unless the application explicitly allows it. By default, classes can only see other classes that were loaded by the same class loader.
Java's class loader architecture to control controls interaction between code loaded from different sources by using different class loaders to load code from different sources. This prevents malicious code from gaining access to and subverting trusted code. A A class loader that loads untrusted code should not interact with trusted code that invokes any of the methods from the following table:
Methods |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
The invocation of these methods is allowed by the trusted code's class loader, however, untrusted code's class loader may lack these privileges. Failure to comply with this guideline may result in compromise of the trust boundary between the trusted and untrusted code. When the untrusted code's class loader delegates to the trusted code's class loader, the untrusted code has visibility to the trusted code according to the declared visibility of the trusted code. In the absence of such a delegation relationship, the class loaders would ensure namespace separation; consequently, the untrusted code would be unable to observe members or to invoke methods belonging to the trusted code. Such a delegation model is imperative to many Java implementations and frameworks so the best advice is to avoid exposing these methods to untrusted code.
...