It looks like the recent addition of close method to URLClassLoader gives the user ability to close System Class Loader and Extension Class loader which are unique resources in the entire life time of java program.
1) Ideally nobody wants to close System Class Loader and Extention class Loader. These are the resources which should be available during runtime of Java program. The new addition close method to URLClassLoader gives the ability to user to close the System and extention class loader. Actually the issue mentioned in bug 4167874 is for Application servers or in any application loads classes using URLClassLoader runs short of file descriptors as the jar files never gets closed even URLClassLoader gets garbage collected. The fix should address only this issue. I think this fix added unwated functionality to System and extension class loaders as thease extends URLClassLoader.
2) If you close URLClassLoader you can create one more URLClassLoader to load new classes by creating a new URLClassLoader but there is no way of loading the classes from the class path and extiontion directory once System and Extention class loaders gets closed.
3) The RuntimePermition check "closeClassLoader" is generalized. There should be specific runtime permission for the System and Extension class loader. The point is if one wishes only to close URLClassloader and user allows permission "closeClassLoader" he/she will get ability to close System/Extension class Loader which can not be reopened during the life time of Java.
<Test1.java>
import java.net.URLClassLoader;
import com.foo.*;
import com.zoo.*;
public class Test1 {
public static void main(String... args) throws Exception {
URLClassLoader ucl = (URLClassLoader) ClassLoader.getSystemClassLoader();
ucl.close();
Test1 t2 = new Test1();
Test3 t3 = new Test3(); // this throws ClassNotFoundException: com.zoo.Test3
}
}
</Test1.java>
<output>
The above program not able to load the class
C:\>"c:\My Downloads\URLClassLoader\jdk1.7.0\bin\javac" -cp c:/zips;. Test1.java
C:\>"c:\My Downloads\URLClassLoader\jdk1.7.0\bin\java" -cp c:/zips;. Test1
Exception in thread "main" java.lang.NoClassDefFoundError: com/zoo/Test3
at Test1.main(Test1.java:11)
Caused by: java.lang.ClassNotFoundException: com.zoo.Test3
at java.net.URLClassLoader$1.run(URLClassLoader.java:299)
at java.net.URLClassLoader$1.run(URLClassLoader.java:288)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:287)
at java.lang.ClassLoader.loadClass(ClassLoader.java:391)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:331)
... 1 more
</output>
1) Ideally nobody wants to close System Class Loader and Extention class Loader. These are the resources which should be available during runtime of Java program. The new addition close method to URLClassLoader gives the ability to user to close the System and extention class loader. Actually the issue mentioned in bug 4167874 is for Application servers or in any application loads classes using URLClassLoader runs short of file descriptors as the jar files never gets closed even URLClassLoader gets garbage collected. The fix should address only this issue. I think this fix added unwated functionality to System and extension class loaders as thease extends URLClassLoader.
2) If you close URLClassLoader you can create one more URLClassLoader to load new classes by creating a new URLClassLoader but there is no way of loading the classes from the class path and extiontion directory once System and Extention class loaders gets closed.
3) The RuntimePermition check "closeClassLoader" is generalized. There should be specific runtime permission for the System and Extension class loader. The point is if one wishes only to close URLClassloader and user allows permission "closeClassLoader" he/she will get ability to close System/Extension class Loader which can not be reopened during the life time of Java.
<Test1.java>
import java.net.URLClassLoader;
import com.foo.*;
import com.zoo.*;
public class Test1 {
public static void main(String... args) throws Exception {
URLClassLoader ucl = (URLClassLoader) ClassLoader.getSystemClassLoader();
ucl.close();
Test1 t2 = new Test1();
Test3 t3 = new Test3(); // this throws ClassNotFoundException: com.zoo.Test3
}
}
</Test1.java>
<output>
The above program not able to load the class
C:\>"c:\My Downloads\URLClassLoader\jdk1.7.0\bin\javac" -cp c:/zips;. Test1.java
C:\>"c:\My Downloads\URLClassLoader\jdk1.7.0\bin\java" -cp c:/zips;. Test1
Exception in thread "main" java.lang.NoClassDefFoundError: com/zoo/Test3
at Test1.main(Test1.java:11)
Caused by: java.lang.ClassNotFoundException: com.zoo.Test3
at java.net.URLClassLoader$1.run(URLClassLoader.java:299)
at java.net.URLClassLoader$1.run(URLClassLoader.java:288)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:287)
at java.lang.ClassLoader.loadClass(ClassLoader.java:391)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:331)
... 1 more
</output>
- relates to
-
JDK-7183373 URLClassloader.close() does not close JAR files whose resources have been loaded via getResource()
-
- Closed
-