MiMa complains about loss of a synthetic method, even though I put the original line back in place

67 Views Asked by At

I'm trying to understand the following message from Migration Manager:

Found 1 binary incompatibilities
================================
 * synthetic method
   de$sciss$lucre$synth$impl$NodeGraphImpl$$ugenGraphs()scala.concurrent.stm.Ref
   in class de.sciss.lucre.synth.impl.NodeGraphImpl does not have a
   correspondent in new version

The class NodeGraphImpl is a final class, and ugenGraphs was a private val. What I did is remove the following:

private val ugenGraphs = Ref(Map.empty[GraphEquality, SynthDef])

I understand that private is not private[this], so theoretically an incompatibility could arise of the removal. Ok.

I try and keep that value in there. The error still does not go away. My theory is that the compiler might remove the method because it is never invoked? I try to create a dummy access to that value, e.g.

def foo(): Unit = ugenGraphs.apply()

Still the error doesn't go away. I also changed the version of my snapshot to make sure it's not a caching problem of MiMa. So why does it insist on the missing of that synthetic method?

Here is the original code.

Hypothesis: The method MiMa complains about was generated because of the closure argument to getOrElse from where ugenGraphs is accessed. If that is the case, is it still safe to consider the new version binary compatible?

1

There are 1 best solutions below

0
On BEST ANSWER

Adding the original getSynthDef method renamed to geSynthDefOLD makes MiMa happy again, so indeed the synthetic method must have been generated as a consequence of the body to getSynthDef.