Following the book?extends T and?After Sup T, let's talk about generics.

Demo 1

public interface Generator {
    <T> T next();
}

The first solution is to add'<T>'before the method return type to make it a generic method.

public interface Generator<T> {
    T next();
}

The second solution is to add'<T>'to the interface name to make it a generic interface.

Generic classes/interfaces must specify parameter types before they can be used, where generic parameters other than generic methods will be of the specified type.The following:

// Generic interfaces and their subclasses
public interface Generator<T> {
    T next(T t);
    void print(T t);
}

public class SubGenerator implements Generator<String>{

    @Override
    public String next(String t) {
        // TODO Auto-generated method stub
        return null;
    }

    @Override
    public void print(String t) {
        // TODO Auto-generated method stub
        
    }

}

// Interfaces with generic methods and their subclasses
public interface Generator<T> {
    T next(T t);
    <U> void print(U t);
}

public class SubGenerator implements Generator<String>{

    @Override
    public String next(String t) {
        // TODO Auto-generated method stub
        return null;
    }

    @Override
    public <U> void print(U t) {
        // TODO Auto-generated method stub
        
    }

}

Demo 2

That is, static methods cannot access generics defined on generic classes, and generic methods can be used to solve this problem.

// Correct practices
public class StaticGenerator {
    public static <T> T rebey(T t) {
        return null;
    }
}

Demo 3

An example of "When generics encounter overload" is presented in P271, "Deep understanding of Java virtual machine JVM advanced features and best practices (full HD version).The conclusion is:

Both methods can legally coexist in a Class file if they have the same name and signature with different return values.

public String url(String s) {
    return "rebey.cn";
}

public int url(String s) {
    return 0;
}

However, the above code cannot be compiled and passed.Because JDK7 was not published at the time of publication, only JDK1.6 and below can be compiled and passed.Over time, it may be wrong to interpret overload as we understood it.The number, order, and type of method parameters with the same name are different, independent of the return value type.

Demo 4

public class Utilities {
    public static <T> HashSet<T> create(int size) {
        return new HashSet<T>(size);
    }
     
    public static void print( HashSet<String> h) { 
        for (String s : h) System.out.println(s);
    }
}

public class ResultGerneric {
    public static void main(String[] args) {
        Utilities.print(Utilities.create(10));    // error in Java 5,6,7 ; fine in Java 8
    }
}

This is an example from GenericsFAQ403.The author tested it on java7 and expected to see the error prompt: "The method print (HashSet <String>) in the type Utilities is not applicable for the arguments (HashSet <Object>)."Utilities.print cannot receive a parameter of type String at this time because the Utilities.create method does not specify a specific type and defaults to Object.In Java 8, type argument inference was added, which automatically infers the right based on the left-hand value type of the assignment symbol.

In addition, the above problem can be solved by displaying the specified parameter type:

public class ResultGerneric {
    public static void main(String[] args) {
        Utilities.print(Utilities.<String>create(10));//Between point operator and method name
    }
}

A similar example (P363) is mentioned in the generics section of Think In Java 4th.

Say something

Through several generic examples, we can see that over time, right can be wrong, and wrong can be right.

Isn't that fun?

To Be Continued

More interesting content, please visit the author's website: rebey.cn