Class name repeated in output of resolveType()

[migrator]

Test program:

import com.google.common.reflect.TypeToken;

public class Outer {

public abstract static class Inner<T extends Inner<T>> {
}

public void foo(Iterable<? extends Inner<?>> arg) {
}

public static void main(String[] args) throws Exception {
    System.out.println(
      TypeToken.of(Outer.class.getMethod("foo", Iterable.class)
      .getGenericParameterTypes()[0]));
}

}

Expected output:

java.lang.Iterable<? extends Outer$Inner<?>>

Actual output:

java.lang.Iterable<? extends Outer.Outer$Inner<?>>

relevance: 1

[migrator]

summary: Not Defined

Sorry forgot to include: Guava version 1.17.

status Not Defined creator: archie.c...@gmail.com created at: Jul 30, 2014

[migrator]

summary: Not Defined (No comment was entered for this change.)

status Not Defined creator: cpov...@google.com created at: Jul 30, 2014

[migrator]

summary: Not Defined

Any strong opinion between Outer.Inner vs. Outer$Inner?

The tricky part is when the outer class is parameterized.

innerClass.getName() would print: "O$I"

But one may prefer to see "O.I".

status Not Defined creator: be...@google.com created at: Jul 30, 2014

[migrator]

summary: Not Defined

Actually I reduced the test case to something so simple I think it obscured the real bug.

If you add "package pkg" at the top of the test case, then this will be the output:

java.lang.Iterable<? extends pkg.Outer.pkg.Outer$Inner<?>>

So it's not just a question of preference - "pkg.Outer.pkg.Outer" is clearly wrong.

Back to your question, seems like staying consistent with Class.getName() is good, but that means we lose the outer type parameter, and IMHO the latter is more important... i.e., TypeToken.toString() should reveal as much of its secret type information as possible because people are mainly using it to understand what the type really is.

status Not Defined creator: archie.c...@gmail.com created at: Jul 30, 2014

[migrator]

summary: Not Defined

Interestingly, JDK7's built-in ParameterizedType.toString() does the same thing.

Map.Entry<String, String>.toString() => "java.util.Map.java.util.Map$Entry<java.lang.String, java.lang.String>"

Do we want to make our types behave differently from builtin types?

status Not Defined creator: be...@google.com created at: Jul 31, 2014

[migrator]

summary: Not Defined

Well. Actually, when you call TypeToken.of(jvmType).toString(), it's really just calling jvmType.toString().

TypeToken isn't doing anything in the middle here.

status Not Defined creator: be...@google.com created at: Jul 31, 2014

[migrator]

summary: Not Defined

FWIW I filed a bug on bugs.sun.com (which, in my experience, is just a black hole fronted by a web site).

status Not Defined creator: archie.c...@gmail.com created at: Aug 2, 2014