I don’t buy the argument that SPI breaks the parental delegation model. Just a quick word.
The parent delegate model is a convention for loading classes. One use of this convention is for security. For example, if you are writing Java using the String class, how can you be sure that the String class you are using is the same one provided in the JDK? The answer is that for JDK base classes, the JDK uses special classloaders to ensure that they are loaded in the right place. The JDK has three built-in classloaders:
• Bootstrap ClassLoader (Bootstrap ClassLoader
•ClassLoader (loading classes in the /lib/ext directory of the JDK)
• Common: Application ClassLoader (class in the Application’s own classpath)
The parent delegate model requires that if a class can be loaded by the delegate base ClassLoader, it cannot be loaded by the higher ClassLoader. This way you know that the String class you are using must be the same Java /lang/ string.class as rt.jar in /lib loaded by BootstrapClasserLoader.
But this model is not mandatory. If you write your own ClassLoader, you can ignore it. For example, you can write your own ClassLoader to load your own String. Of course the Java Runtime recognizes that these two strings are not a Class, even though their Full Qualified Class Name is the same. So if you do this, you’re probably doing it to yourself. When you really know what you’re doing, you can play with some flowers.
Incidentally, the security of this mechanism is limited. If someone has access to the server, they can replace the JDK directory files directly. The mechanism fails. To ensure strict security, system files should also be digitally signed.
Another point is that this model, while “safe,” loses a bit of flexibility. For example, java.sql.Driver. The JDK provides only a canonical interface, not an implementation. It is the actual database provider that provides the implementation. Vendor libraries cannot be placed in the JDK directory.
Ava created SPI in 1.6 as an elegant solution to this kind of problem — the JDK provides the interface and the vendor provides the service. Wouldn’t it be nice if the programmer could code to an interface, and then the JDK could automatically find the right implementation?
But convenience comes with a twist. Classes provided by the provider cannot be placed in the LIB directory of the JDK, so they cannot be loaded with the BootstrapClassLoader. So when you write code
Class clz = Class.forName(“java.sql.Driver”); Driver d = (Driver)clz.newInstance();
The code will try to load using the Bootstrap ClassLoader. Java.sql.Driver is an interface that cannot be instantiated.
Without SPI, you can add mysql-connector-java.jar to your classpath and write it like this
Class clz = Class.forName(“com.mysql.jdbc.Driver”); Driver d = (Driver) clz.newInstance();
Mysql-connector-java.jar com.mysql.jdbc.driver; The problem is that you have hard code and must load “com.mysql.jdbc.driver”, which is not very elegant, and does not implement “interface programming, automatic instantiation of real implementation”.
With SPI, the code looks something like this
Connection connection = DriverManager.getConnection(“jdbc:mysql://xxxxxx/xxx”, “xxxx”, “xxxxx”);
DriverManager uses the “JDBC :mysql” prompt to find the implementation.
then
System.out.println(connection.getClass().getClassLoader());
You’ll see that the result here is Application ClassLoader. This is as if the Application ClassLoader loaded the java.sql.Connection that should have been loaded by BootstrapClassLoader. Looks like a violation of the parental delegation model. But in fact, the type of Connection here is actually “. Com. Mysql. JDBC JDBC4Connection “, is also a third party. Loading a third-party class by AppClassLoader does not seem to violate the model.
Further investigate the loading situation of the Connection interface:
System.out.println(java.sql.Connection.class.getClassLoader());
Null is returned. The Connection itself is loaded by the Bootstrap ClassLoader.
In general, Bootstrap ClassLoader does not load a third-party library or Application ClassLoader loads JDK libraries.
So can you tell me exactly where SPI breaks the parental delegation model? Let me see if I got it wrong. Maybe I was wrong, or maybe the reference was wrong.