Clarify IncompatibleSignatureProblem message

core/src/main/scala/com/typesafe/tools/mima/core/Problems.scala

@@ -41,7 +41,7 @@ sealed abstract class Problem extends ProblemRef {
     case ReversedMissingMethodProblem(ref)                => s"${ref.memberString} is present only in $affectedVersion version"
     case FinalMethodProblem(ref)                          => s"${ref.methodString} is declared final in $affectedVersion version"
     case IncompatibleResultTypeProblem(ref, newmeth)      => s"${ref.methodString} has a different result type in $affectedVersion version, where it is ${newmeth.tpe.resultType} rather than ${ref.tpe.resultType}"
-    case IncompatibleSignatureProblem(ref, newmeth)       => s"${ref.methodString} has a different signature in $affectedVersion version, where it is ${orMIA(newmeth.signature)} rather than ${orMIA(ref.signature)}"
+    case IncompatibleSignatureProblem(ref, newmeth)       => s"${ref.methodString} has a different signature in $affectedVersion version, where it is ${orMIA(newmeth.signature)} rather than ${orMIA(ref.signature)}. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out"
     case DirectAbstractMethodProblem(ref)                 => s"${ref.methodString} does not have a correspondent in $affectedVersion version"
     case ReversedAbstractMethodProblem(ref)               => s"in $affectedVersion version there is ${ref.methodString}, which does not have a correspondent"
     case UpdateForwarderBodyProblem(ref)                  => s"in $affectedVersion version, classes mixing ${ref.owner.fullName} needs to update body of ${ref.shortMethodString}"

functional-tests/src/test/class-constructor-generics-nok/problems.txt

@@ -1,3 +1,3 @@
-method source()scala.Tuple2 in class OptionPane has a different signature in new version, where it is ()Lscala/Tuple2<LMyPane<TA;>;Ljava/lang/String;>; rather than ()Lscala/Tuple2<Ljavax/swing/JOptionPane;Ljava/lang/String;>;
-method show()java.lang.Object in class OptionPane has a different signature in new version, where it is ()TA; rather than <missing>
-method this(scala.Tuple2)Unit in class OptionPane has a different signature in new version, where it is (Lscala/Tuple2<LMyPane<TA;>;Ljava/lang/String;>;)V rather than (Lscala/Tuple2<Ljavax/swing/JOptionPane;Ljava/lang/String;>;)V
+method source()scala.Tuple2 in class OptionPane has a different signature in new version, where it is ()Lscala/Tuple2<LMyPane<TA;>;Ljava/lang/String;>; rather than ()Lscala/Tuple2<Ljavax/swing/JOptionPane;Ljava/lang/String;>;. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out
+method show()java.lang.Object in class OptionPane has a different signature in new version, where it is ()TA; rather than <missing>. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out
+method this(scala.Tuple2)Unit in class OptionPane has a different signature in new version, where it is (Lscala/Tuple2<LMyPane<TA;>;Ljava/lang/String;>;)V rather than (Lscala/Tuple2<Ljavax/swing/JOptionPane;Ljava/lang/String;>;)V. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out

functional-tests/src/test/class-method-generics-nok/problems.txt

@@ -1,12 +1,12 @@
-method genericWithChangingName()scala.Option in class A has a different signature in new version, where it is <T:Ljava/lang/Object;>()Lscala/Option<TT;>; rather than <U:Ljava/lang/Object;>()Lscala/Option<TU;>;
-method backwardsCompatibleNarrowing()scala.Option in class A has a different signature in new version, where it is ()Lscala/Option<Ljava/lang/String;>; rather than ()Lscala/Option<Ljava/lang/Object;>;
+method genericWithChangingName()scala.Option in class A has a different signature in new version, where it is <T:Ljava/lang/Object;>()Lscala/Option<TT;>; rather than <U:Ljava/lang/Object;>()Lscala/Option<TU;>;. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out
+method backwardsCompatibleNarrowing()scala.Option in class A has a different signature in new version, where it is ()Lscala/Option<Ljava/lang/String;>; rather than ()Lscala/Option<Ljava/lang/Object;>;. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out
 #
-method cov1()java.lang.Object in class Api has a different signature in new version, where it is <A:Ljava/lang/Object;>()TA; rather than <missing>
-method cov2()java.lang.Object in class Api has a different signature in new version, where it is <missing> rather than <T:Ljava/lang/Object;>()TT;
-method con1(java.lang.Object)Unit in class Api has a different signature in new version, where it is <A:Ljava/lang/Object;>(TA;)V rather than <missing>
-method con2(java.lang.Object)Unit in class Api has a different signature in new version, where it is <missing> rather than <T:Ljava/lang/Object;>(TT;)V
+method cov1()java.lang.Object in class Api has a different signature in new version, where it is <A:Ljava/lang/Object;>()TA; rather than <missing>. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out
+method cov2()java.lang.Object in class Api has a different signature in new version, where it is <missing> rather than <T:Ljava/lang/Object;>()TT;. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out
+method con1(java.lang.Object)Unit in class Api has a different signature in new version, where it is <A:Ljava/lang/Object;>(TA;)V rather than <missing>. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out
+method con2(java.lang.Object)Unit in class Api has a different signature in new version, where it is <missing> rather than <T:Ljava/lang/Object;>(TT;)V. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out
 #
-abstract method cov1()java.lang.Object in class Abi has a different signature in new version, where it is <A:Ljava/lang/Object;>()TA; rather than <missing>
-abstract method cov2()java.lang.Object in class Abi has a different signature in new version, where it is <missing> rather than <T:Ljava/lang/Object;>()TT;
-abstract method con1(java.lang.Object)Unit in class Abi has a different signature in new version, where it is <A:Ljava/lang/Object;>(TA;)V rather than <missing>
-abstract method con2(java.lang.Object)Unit in class Abi has a different signature in new version, where it is <missing> rather than <T:Ljava/lang/Object;>(TT;)V
+abstract method cov1()java.lang.Object in class Abi has a different signature in new version, where it is <A:Ljava/lang/Object;>()TA; rather than <missing>. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out
+abstract method cov2()java.lang.Object in class Abi has a different signature in new version, where it is <missing> rather than <T:Ljava/lang/Object;>()TT;. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out
+abstract method con1(java.lang.Object)Unit in class Abi has a different signature in new version, where it is <A:Ljava/lang/Object;>(TA;)V rather than <missing>. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out
+abstract method con2(java.lang.Object)Unit in class Abi has a different signature in new version, where it is <missing> rather than <T:Ljava/lang/Object;>(TT;)V. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out

functional-tests/src/test/tuple-parametric-type-change-nok/problems.txt

@@ -1 +1 @@
-method foo()scala.Tuple2 in class A has a different signature in new version, where it is ()Lscala/Tuple2<Ljava/lang/Object;Ljava/lang/String;>; rather than ()Lscala/Tuple2<Ljava/lang/String;Ljava/lang/Object;>;
+method foo()scala.Tuple2 in class A has a different signature in new version, where it is ()Lscala/Tuple2<Ljava/lang/Object;Ljava/lang/String;>; rather than ()Lscala/Tuple2<Ljava/lang/String;Ljava/lang/Object;>;. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out

functional-tests/src/test/value-class-generic-replacement-nok/problems.txt

@@ -1 +1 @@
-method boxedStringy()scala.Option in class Bar has a different signature in new version, where it is ()Lscala/Option<LFoo;>; rather than ()Lscala/Option<Ljava/lang/String;>;
+method boxedStringy()scala.Option in class Bar has a different signature in new version, where it is ()Lscala/Option<LFoo;>; rather than ()Lscala/Option<Ljava/lang/String;>;. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out