== Why is this an issue?

When a type variable or a wildcard declares an upper bound that is ``++final++``, the parametrization is not generic at all because it accepts one and only one type at runtime: the one that is ``++final++``. Instead of using ``++Generics++``, it's simpler to directly use the concrete ``++final++`` class.


=== Noncompliant code example

[source,java]
----
public static <T extends String> T getMyString() { // Noncompliant; String is a "final" class and so can't be extended
 [...]
}
----


=== Compliant solution

[source,java]
----
public static String getMyString() { // Compliant
  [...]
}
----


ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

Replace this type parametrization by the 'final' type.


'''
== Comments And Links
(visible only on this page)

=== on 31 Oct 2018, 09:34:36 Nicolas Peru wrote:
Title of the rule is dodgy : there is no wildcard at all in this example. 

"upper bound of type variables" would be more correct.

endif::env-github,rspecator-view[]