Special cases in Java Overloading

As we all know, Java provides generic support in versions 1.5 and later, but the overload is affected by the large or small value. Many people know that the overload method will also be overloaded, however, I did not know the special cases of overloading. I saw a post earlier and discussed some special cases about Java overloading, which made me feel incredible, how can we reload it? When do we think that the reload is "cannot be reloaded "? When I got up early this morning to build a project, I suddenly remembered a program that was decompiled before. The program is an example that was used to test the reload in Java, in the decompiled code, I saw that the Java overload actually supports using the return value as the overload condition! This is incredible, but we cannot write code like this, and compilation will fail. But today we suddenly find that I have seen another aspect of heavy load, let's take a look at the following methods: ① public void test (List <String> arg0 ){

}

② Public void test (List <Integer> arg0 ){

}

③ Public void test (ArrayList <Integer> arg0 ){

}

④ Public Object test (List <String> arg0 ){
Return null;
}

⑤ Public <T extends Object> T test0 (List <String> arg0 ){
Return null;
}

⑥ Public <T extends Serializable> T test0 (List <String> arg0 ){
Return null;
}
We put these methods into a Java class and open them in eclipse. We can easily find that Methods ① and ② cannot coexist. METHODS ① cannot coexist with methods ④, this is not surprising to me, because this was the case during the previous test. This is because the implementation of generics in Java is in the syntax rather than at the compiler level, any generic type directly or indirectly inherits the Object class, therefore, all generic types are considered to be of the same type (theoretically, List <String> and List <Integer> are not of the same type, which is embodied in C, but Java is Java! Don't ask me why. This is the Java rule !); But when we comment out the first method, we are surprised to find that there is no conflict between methods! Then, according to the previous statement, method 2 and method 4 should conflict with each other at this time, because in the conclusion at the beginning, list <String> and List <Integer> are considered to be of the same type. Are List <String> and List <Integer> of the same type? Why can methods of the same type be reloaded? This is incredible! Can the return value of a method be used as a basis for method overloading? The answer is no, believe it? We can change the return value void of method ② to Integer or any other non-Object type (any non-Object type? Any type will be the child type of the Object !), The method is naturally underlined in red! What does this mean? Method return values cannot be used as the basis for overloading! Some readers will certainly ask, why is there no error before the return value type of method ② is changed? This is simple. Can you use a variable to accept the value of method ②? Method ② does not return a value! At this point, some readers will continue to ask, so I don't need variables to accept the return value of the method. How can I determine which method is called? What are the parameters in the method defined here? List <String> and List <Integer>: Can the same parameters be passed when the method is called? Well, we will discuss the return value of the method here. I believe everyone knows that the return value of the method cannot be used as the basis for method overloading! Let's take a look at the next two more special methods. Their common feature is that the method parameters are completely consistent, but the type of return values of methods is different. The return values of methods are somewhat special, the Return Value of the method is uncertain. It seems that there is no error in writing this method, but when we call this test0 method, we will find that, "The method test0 (List <String> arg0) is ambiguous "! Method test0 (List <String> arg0) is an uncertain method! However, this class can be compiled. I think this may be a vulnerability in the compiler. It can define methods but cannot be called!
Well, this is the end of the article. I have almost finished all of the above. There are some mistakes in this article. Please give your own opinions and welcome everyone to make a picture!

This article is from "focus on achieving the future !" Blog, please be sure to keep this source http://xiaodpro.blog.51cto.com/744826/423448