Yes, but even if you write this class, it doesn't work.
This issue involves the delegate mechanism of the loader, in the class loader's structure diagram (below),
Bootstrap is the top-level parent class, Extclassloader is a subclass of the Bootstrap class, and Extclassloader is also the parent of Appclassloader
Here in java.lang.String, for example, when I use this class, the Java virtual Opportunity loads the bytecode of the Java.lang.String class into memory.
Why load only the Java.lang.String class passed by the system without loading the user-defined java.lang.String class?
When loading a class, it takes precedence to load the classes that need to be used by the parent ClassLoader. If we customize the Java.lang.String class,
Load the custom string class, the custom string class used by the loader is Appclassloader, based on the preferred use of the parent ClassLoader principle,
The Appclassloader loader's parent class is extclassloader, so loading the string using the ClassLoader is Extclassloader,
However, the class loader Extclassloader did not find the String.class class in the Jre/lib/ext directory. Then use the loader bootstrap of the Extclassloader parent class,
The parent ClassLoader Bootstrap found String.class in the Jre/lib directory and loaded it into memory rt.jar. This is the delegate mechanism of the ClassLoader.
Therefore, user-defined java.lang.String are not loaded, that is, they will not be used.
Transferred from: http://blog.csdn.net/caolaosanahnu/article/details/19502005
Java face question 53 can you write a class, also called java.lang.String?