2023-05-03 11:06:20 +02:00
== Why is this an issue?
2022-05-11 10:08:57 +02:00
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.
2021-04-28 16:49:39 +02:00
2021-04-28 18:08:03 +02:00
2023-05-03 11:06:20 +02:00
=== Noncompliant code example
2021-04-28 16:49:39 +02:00
2022-02-04 17:28:24 +01:00
[source,java]
2021-04-28 16:49:39 +02:00
----
public static <T extends String> T getMyString() { // Noncompliant; String is a "final" class and so can't be extended
[...]
}
----
2021-04-28 18:08:03 +02:00
2023-05-03 11:06:20 +02:00
=== Compliant solution
2021-04-28 16:49:39 +02:00
2022-02-04 17:28:24 +01:00
[source,java]
2021-04-28 16:49:39 +02:00
----
public static String getMyString() { // Compliant
[...]
}
----
2021-04-28 18:08:03 +02:00
2021-06-02 20:44:38 +02:00
2021-06-03 09:05:38 +02:00
ifdef::env-github,rspecator-view[]
2021-09-20 15:38:42 +02:00
'''
== Implementation Specification
(visible only on this page)
2023-05-25 14:18:12 +02:00
=== Message
Replace this type parametrization by the 'final' type.
2021-09-20 15:38:42 +02:00
2021-06-08 15:52:13 +02:00
'''
2021-06-02 20:44:38 +02:00
== Comments And Links
(visible only on this page)
2023-05-25 14:18:12 +02:00
=== 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.
2021-06-03 09:05:38 +02:00
endif::env-github,rspecator-view[]