It's complicated. There actually IS JVM support for generics in surprising locations. Just not at method dispatch... sort of.

For example

    void <T extends Foo> bar(T f);

will, under the covers, create a function that looks like

    void bar(Foo f);

If you create a class

    class Foo implements Supplier<Bar> {
        Bar get() { return new Bar(); }
    }

The method signature for `Foo` does in fact return a `Bar` type and not some `Object` type even though `Supplier<Bar>` would imply that is erased. The same applies to if that generic was used within the method parameters.

That generic type information is, in fact, stored off at the class level and can be extracted through Java's reflection API.

This is how magic like

    json.parse("[1,2,3]", new TypeReference<List<Integer>>{});

is getting it's stuff done. It's creating a new anonymous class of "TypeReference<List<Integer>>" which the json library can then use to introspect and pull the generic information out and know that it should create a `List` of `Integer` rather than of `Long` or `Double` or a `Set`.

This makes generics more than just a syntactic construction in Java.

The JVM still doesn't know about generics. The explanation you provided is entirely at the compiler (javac) level, and the JVM is still oblivious to it. There is no special dispatch, or optimization. At best, you could say there is support in the Java standard library, but not in the JVM or hotspot or anything from running "java".

An easy way to verify: Are generics in Clojure, Scala, or JRuby the same as Java (the programming language)?

    class Foo implements Supplier<Bar> {
        Bar get() { return new Bar(); }
    }

Bar isn't a generic in Foo though (if we remove the implements-clause, that is very clear). It's only a generic in Supplier, so I don't see where the implied erasure quite comes from.

I didn't add it, but the `get` method comes is an override from the `Supplier`.

For example, if we did something like

    class Foo extends HashMap<Foo, Bar> {
      @Override
      Bar put(Foo f, Bar b) {
        super.put(f, b);
      }
    }

The `Map` signature for `put` is `Object put(Object, Object)` due to erasures. However, because you are extending and specifying the generics, the overriden method ends up reifying the type.

All this is to say that generics end up being a little more than just syntactic sugar.

If you consider this example:

    class Base<T> {
        T f() { return null; }
    }
    class A<T2> extends Base<T2> {
        @Override
        T2 f() { return null; }
    }
    class B extends Base<Integer> {
        @Override
        Integer f() { return null; }
    }
    class C {
        Integer f() { return null; }
    }

Base has a parameter T which is erased in Base.

A has a parameter T2 which is erased in A.

B because B is not a generic class and nothing is erased from B.

Base has the same shape as A; B has the same shape as C.

The example you provide has little to do with generics, but how inheritance works.

In particular if you override a method in a derived class, you're allowed to return an instance of a more specific class (in your example, Bar is an Object so it is fine). At runtime, your example is equivalent to something like

    interface Supplier {
        Object get();
    }

    class Foo extends Supplier {
        Bar get() { return new Bar(); }
    }

For most purposes, but there's a little in reflection and so forth. For example:

https://docs.oracle.com/en/java/javase/17/docs/api/java.base...()

Edit: sibling comment by cogman makes the case more thoroughly.

Edit: also HN mangles the link to Class.getTypeParameters()

Per https://news.ycombinator.com/formatdoc, put it in angle brackets. Maybe this works? <https://docs.oracle.com/en/java/javase/17/docs/api/java.base...>