Java define a class called Object

Question

I created a class called Object in the java.lang . In another package, I created the Main class. Now in the main method of the Main class, when I write new Main() and put a dot after this, I do not see equals() , wait() , etc. Ie methods of the actual class Object.

My question is: do you think that creating a class called Object (especially with the java.lang package) should not be allowed. Since the class Object is by default inherited by all classes, so in my case, any class that I define automatically inherits my class, not the actual class of the object, because the class name and package name of my object class are the same as the class of the actual object.

Answer 1

This is a fairly open question.

Should it be allowed? Why not, if you know what you are doing, go crazy.

I agree that this is somewhat dangerous theoretically, but I don’t see anyone doing this by mistake. If someone really wants to redefine the entire Object class for some reason, for example, academic, then he / she can do it at your own peril and risk.

No language can completely stop you from shooting an arrow on your own knee.

Answer 2

I can confirm that even if you write one, it will not be useful (at least with the usual loading of java classes). The priority is in java.lang, since they are already loaded by the system class loader, and your Object class will never be selected and calling any custom methods will only lead to runtime errors (java.lang.NoSuchMethodError)

But I'm not sure of the behavior when using a custom classloader, and overriding its loadClass method so that it explicitly loads your cool byte, but does not search in the parent classloader. Maybe at home :)

Answer 3

I use this trick (having some third-party same package and class name in our class path), often overriding the functionality of third-party libraries if I cannot wrap them.
In any case, all system classes must be loaded into jvm before downloading the client program (our application). It's all about ClassLoader , a compiler that allows this, because in reality it doesn't care too much about all classes, but at run time, JVM loader classes will take these things into account. If you look at the default source code ClassLoader (oracle jdk). You can see that there will be a check that you should not run the package with java.

 private ProtectionDomain preDefineClass(String name, ProtectionDomain protectionDomain) { ... if ((name != null) && name.startsWith("java.")) { throw new SecurityException("Prohibited package name: " + name.substring(0, name.lastIndexOf('.'))); } ... } 

Even with well-known bite code tools such as javaassist , this behavior will be limited, they will check if the class can be instrumental or not Instrumentation.isModifiableClass .
Finally, it all depends on the implementation of ClassLoader and, since it must adhere to the specifications, you need to consider the order of the classes from the class path to load.