Hi Steven, Michel,
I've reproduced this issue. It's a strange one! I can't figure out the root cause of this, but I did find a few ways to avoid the problem.
* Somehow, it only seems to occur when run from SBT. Running the same test from IntelliJ does seem to work. Also, I've created a Maven pom to replace the SBT script, and then the error also doesn't occur. But you obviously shouldn't do that on a real project, just to make EqualsVerifier work.
* The problem occurs when EqualsVerifier creates an instance of an Instantiator (an internal EqualsVerifier class) for the Function0 (an interface) or the StringProperty (an abstract class). Currently, EqualsVerifier creates such an instance, even if it doesn't need it. I've created a GitHub issue[1] to refactor it so that the object is only instantiated when actually used. That way, you can add a prefab value for the offending type (i.e., the Function0 or the StringProperty), and the problem won't occur. I'll do that for the next release of EqualsVerifier, which I should be able to release soon.
* Building on that, I can add StringProperty and the other JavaFX properties to EqualsVerifier's internal list of prefab values. That way, you won't have to explicitly add those anymore. I've made an issue for that as well[2], which will also be in the next release. Unfortunately, I can't do it for Function0, because that's not a type that exists in the Java APIs.
* I've been experimenting with replacing CGLib with ByteBuddy, which seems like a good thing to do because CGLib hasn't been updated since before Java 8 came out. It turns out that that also solves the issue; no more Function0 prefab values necessary. Given that that has a much higher impact, it won't be in the next release, though. I've started working on a version 2.0 of EqualsVerifier, and that's where this will happen. Obviously I can't give a good time frame for that, though: it will be released when it's released :).
I will let you know when the next release is out.
I hope this helps.
Jan