java 擦除如何决定返回类型的转换？

Question

i am spending a lot of time on learning Generic feature in Java. I tried to read explanation in the following link: https://docs.oracle.com/javase/tutorial/java/generics/bridgeMethods.html , and i didn't understand and also tried to understand the issue by the following link from the forum: Java Type Erasure: Rules of cast insertion? , but still things are far a way from being clear for me, and i also added a comment to post but i'm doubt if someone will refer to a comment because the post is very old.

I'm trying to understand how the compiler knows which cast to make for method returned type when he makes the erasure. In the book i'm learning from (Deital - Java How to Program), i think that something in the explanation is missing (maybe a typo). Is is written there: " In each case, the type of the cast for the return value is inferred from the types of the method arguments in the particular method call, because, according to the method declaration, the return type and the argument types match. As i understand the sentence, it says that the cast is according to the arguments that were send when the method was called. But if the methods doesn't get any argument. eg, if the method prototype is:

public static <T extends Animal> T funcA ()

Now 3 different methods call the function. One wants to get a Dog a returned type ( Dog d = funcA() ), the second one wants to get Cat ( Cat c = funcA() ) and the last one wants to get Animal ( Animal A = funcA() ). How does erasure decide which cast to make?

Answer 1

This doesn't actually have anything to do with erasure. The type is inferred from the call site : what type the caller is "actually expecting. Animal a = funcA() is equivalent to Animal a = MyClass.<Animal>funcA() , Dog d = funcA() is equivalent to Dog d = MyClass.<Dog>funcA() .

Whether this works at an implementation level does have something to do with erasure, and there isn't actually a valid implementation for funcA -- one that won't have compiler warnings, or equivalently, one that won't fail at runtime -- other than (something that boils down to) return null .

Answer 2

based on the target types in the following statements

• Dog d = funcA()

• Cat c = funcA()

• Animal A = funcA()

the compiler is using Type Inference ( https://docs.oracle.com/javase/tutorial/java/generics/genTypeInference.html ). If you look at the examples in the Target Types section you will see something similar to what you are asking.

Answer 3

There are 3 different issues at hand:

• Type erasure of the actual method

• Bridge methods when overriding inherited method

• Casting when calling the method

---

You example is:

public static <T extends Animal> T funcA ()

That method cannot have anything to do with bridge methods, because it is static.

Type erasure means that the compiler eliminates (erases) the generic type, so the code is compiled as-if you wrote:

public static Animal funcA ()

Because of that, when you then call the method, casting is added by the compiler:

Dog d = (Dog) funcA()

As you can see, the compiled code doesn't have generic types, it is all "magic" implemented by the compiler, to pretend that generics actually exist.

---

Now, if you actually were interested in bridge methods and how erasure works, then let's look at the example in the link you provided.

In that article, the method in the base class is declared as:

public class Node<T> {
    public void setData(T data)

Erasure compiles that as:

public class Node {
    public void setData(Object data)

In the subclass the method is declared as:

public class MyNode extends Node<Integer> {
    public void setData(Integer data)

Erasure compiles that as:

public class MyNode extends Node {
    public void setData(Integer data)

Now a bridge method is added by the compiler, because the JVM needs an overriding method in the subclass with an Object parameter type:

@Override
public void setData(Object data) {
    setData((Integer) data);
}

As you can see, the compiler once again added a cast. I hope this answers your question about how the compiler knows which cast to make, when it makes the erasure.

Answer 4

There is no cast in the generic code at all. In Java object references are binary unchanged when a cast expression is evaluated. Any reference type is always just object . Everything else are guarantees from the compiler. So there is just no need for a cast in the generic code.

In fact a cast generates only some code like

if (!(obj instanceof desiredtype))
    throw new ClassCastException();

However, Java allows to cast from untyped types to generic types. This can result in bad types returned by functions. It is up to the caller to deal with this situations. The three callers knows their individual, expected type. So they can check for unexpected results (ie cast) when needed.