No warning reported for pattern matching evolution that can result in MatchError

[Sciss]

I have a change from

trait DialogSource[+A] { def show(): A }

implicit final class OptionPane(val source: (javax.swing.JOptionPane, String))
  extends DialogSource[Any] {
  def show(): Any = {
    val (pane, title) = source
    val jdlg = pane.createDialog(title)
    jdlg.setVisible(true)
    pane.getValue
  }
}

to

trait MyPane[A] {
  def peer: javax.swing.JOptionPane
  def result: A
}

implicit final class OptionPane[A](val source: (MyPane[A], String))
  extends DialogSource[A] {
  def show(): A = {
    val (pane, title) = source
    val jdlg  = pane.peer.createDialog(title)
    jdlg.setVisible(true)
    pane.result
  }
}

This is not recognised as a binary incompatibility. Obviously code compiled against the first version will produce a MatchError when run against the second version, because the tuple extraction doesn't work any more.

Also a type constructor parameter was added. I'm surprised this doesn't result in a warning, too.

[jsuereth]

That's a good one. At runtime, the signature of OptionPane doesn't actually change, only the encoded type parameters. Great catch!

[dotta]

Indeed, great catch!

The issue here is that MiMa currently only considers binary incompatibilities as defined in http://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html, i.e., MiMa only reports incompatibilities that can lead to a LinkageError. Clearly, the Java definition is not good enough in this case.

Also a type constructor parameter was added. I'm surprised this doesn't result in a warning, too.

The type constructor A is erased to Any, hence the signature of OptionPane was not affected by the change. Implying that the evolution of OptionPane is indeed binary compatible (you can read here for more details about this point).