20

Why is Scala binary incompatible between different releases?

linuxbuild
  • 15,170
  • 5
  • 55
  • 84
Mohamed Bana
  • 1,091
  • 2
  • 14
  • 24

6 Answers6

21

It has to do with the way traits are compiled, because traits are kind of like interfaces but they can contain implementation. This makes it so it is VERY easy to make changes that don't break source compatibility but break binary compatibility, because when you add a new method to a trait along with an implementation, you have to recompile everything that implements that trait so that they will pickup that implementation. There's probably other issues, too, but I think they're mostly along the same lines.

Erik Engbrecht
  • 3,144
  • 15
  • 23
  • 6
    This is only partially true. The JVM is actually *really* loose with linking. That's how JDBC 2.0 drivers are binary compatible with JDBC 3.0 drivers where the interfaces have *many* more methods. The same is true in Scala. If you add a method in a trait that is never called in a program, it's binary compatible. This is true for val/var as well IIRC. – jsuereth Dec 07 '11 at 20:30
  • 1
    @jsuereth Thanks for adding the clarification, although if I recall correctly there are still subtle ways this can bite you. For example, let say in v1 of a library you have a trait with a method that has implementation, and you mix the trait into a class in an app. Then in v2 of the lib you add a method with implementation to the trait, and call that method from the method common to v1 and v2. The app compiled against v1 will crash at runtime if you try to use it with v2, because v2 depends on the new method being mixed in by the compiler. So one must be very careful in updating libs. – Erik Engbrecht Dec 10 '11 at 21:41
  • 1
    Josh kindly wrong a more detailed explanation that deserves some link love: http://suereth.blogspot.com/2011/12/scala-fresh-is-alive.html – Erik Engbrecht Dec 11 '11 at 16:11
  • Write, but that issue is the same as using any Java library. E.g. Using JDBC 2.0 drivers in a system with JDBC 4.0 interface, while possible, can be dangerous. At runtime. Scala doesn't change the face of binary compatibility, but *we* the community tend to ignore it more. – jsuereth Dec 22 '11 at 20:41
9

Lack of JVM support for Scala-specific features, such as traits mentioned, and the fact that it is actively evolving.

Daniel C. Sobral
  • 284,820
  • 82
  • 479
  • 670
5

Here's background on this, straight from Odersky, if you want to understand the specific language issues that cause problems:

http://www.scala-lang.org/node/9346

It's worth reading in conjunction with this post from David Pollack if you are new to the issue and want to understand the impact this can have on applications:

http://lift.la/scalas-version-fragility-make-the-enterprise

toddsundsted
  • 5,727
  • 2
  • 19
  • 13
  • I think you also missed my response: http://suereth.blogspot.com/2011/12/scala-fresh-is-alive.html which clears up a lot of what has happened since Odersky's email. – jsuereth Dec 08 '11 at 14:36
3

I've implemented support for Scala in the japi-compliance-checker 1.6 and performed analysis of backward compatibility for all versions of Scala (both binary- and source-compatibility).

So now you can view breaking changes in details. The report is available here: http://abi-laboratory.pro/java/tracker/timeline/scala/

The report is updated every other day, so you can monitor changes in the recent versions of Scala.

enter image description here

linuxbuild
  • 15,170
  • 5
  • 55
  • 84
2

It's still relatively young and undergoing active development.

There are some changes in the new release that were anxiously awaited and that help with a lot of problems, but it wasn't possible to make them backward compatible.

Because Sun is kind of restrictive about updates, Java changes rather slowly, and usually tries to remain backward compatible to the bitter end. Sometimes this stands in the way of progress, but big companies love a stable language.

Scala, on the other hand, is in the hands of a small group of academics, and it's not (yet) widely used in the industry, so they have (or take) some more freedom with changes.

Carl Smotricz
  • 62,722
  • 17
  • 119
  • 161
0

Umm, no. Get your facts straight. There was no recompilation needed* when going from 2.7.2.3b1 -> 2.7.2.3b2, which was a real relief for me because of the large customer base we had with entrenched legacy code using 2.7.2.3b1 features.

*Caveat - unless you foolishly used code in scala.collection._ or scala.xml._

Mitch Blevins
  • 12,816
  • 3
  • 41
  • 32