2.9.0 bytecode backward compatibility with 2.8.1

Hi all,
I try to run a project with many 2.8.1 dependencies under 2.9.0 and this is what I see:

java.lang.NoClassDefFoundError: scala/runtime/AbstractFunction0$mcL$sp
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(Unknown Source)
    at java.security.SecureClassLoader.defineClass(Unknown Source)
    at java.net.URLClassLoader.defineClass(Unknown Source)
    at java.net.URLClassLoader.access$000(Unknown Source)
    at java.net.URLClassLoader$1.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClassInternal(Unknown Source)
    at net.liftweb.http.LiftSession.<init>(LiftSession.scala:572)
    at code.snippet.HelloWorldTestSpecs$.<init>(HelloWorldTest.scala:21)
    at code.snippet.HelloWorldTestSpecs$.<clinit>(HelloWorldTest.scala)
    at code.snippet.HelloWorldTestSpecsAsTest.<init>(HelloWorldTest.scala:17)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
    at java.lang.reflect.Constructor.newInstance(Unknown Source)
    at java.lang.Class.newInstance0(Unknown Source)
    at java.lang.Class.newInstance(Unknown Source)
    at org.specs.runner.JUnitSuiteRunner.testSuite(JUnitSuiteRunner.scala:37)
    at org.specs.runner.JUnitSuiteRunner.getDescription(JUnitSuiteRunner.scala:57)
    at org.junit.runner.Runner.testCount(Runner.java:38)
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.countTestCases(JUnit4TestClassReference.java:30)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.countTests(RemoteTestRunner.java:487)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:455)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

As far as I understand it clearly indicates that there is no bytecode backward compatibility between 2.8.1 and 2.9.0
I did not have any issues with bytecode backward compatibility between 2.8.0 and 2.8.1

Does it mean that:
1) there is no commitment to maintain bytecode backward compatibility
2) the commitment has been dropped (because it is not possible)
3) the commitment is only present for bug fixes (last digit change)
4) anything else ?

Regards,
Andrey

On Tue, May 24, 2011 at 11:02 AM, Brian Smith wrote:
> This thread's worth a read:
> http://www.scala-lang.org/node/3755

A more recent and more informative thread is:

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

You can find the answer to your questions in that thread, but my
interpretation follows for some of them.

>> 1) there is no commitment to maintain bytecode backward compatibility

It's being worked on, but we're not there yet.

>> 3) the commitment is only present for bug fixes (last digit change)

That is how things stand at the moment.

>> 4) anything else ?

You're recommended to recompile your projects for 2.9.0.

Best,
Ismael

On Tue, May 24, 2011 at 2:55 PM, Andrey Somov wrote:
> Thank you. I got a very clear answer.
>
> P.S. now it is clear that the bytecode backward compatibility will always be
> an illusion. Even for bug fixes only.

Where did you draw that conclusion from?

> It is very sad to have many bytecode versions of the same library compiled
> for different Scala versions.
>

On Tue, May 24, 2011 at 10:31 PM, iulian dragos
wrote:
> On Tue, May 24, 2011 at 2:55 PM, Andrey Somov wrote:
>> P.S. now it is clear that the bytecode backward compatibility will always be
>> an illusion. Even for bug fixes only.
>
> Where did you draw that conclusion from?

I was wondering the same thing. :)

Best,
Ismael

On 05/24/2011 05:55 AM, Andrey Somov wrote:
> Thank you. I got a very clear answer.
>
> P.S. now it is clear that the bytecode backward compatibility will
> always be an illusion. Even for bug fixes only.
> It is very sad to have many bytecode versions of the same library
> compiled for different Scala versions.

Andrey,

It is very understandable that you should feel frustrated since even
though the Scala developers are working very hard on the problem of
preserving bytecode compatibility across releases the end goal still
seems out of sight. Part of the problem is that unlike projects with
larger communities, they simply don't have the manpower to maintain
multiple release series --- unlike, say, Python --- so that older series
can be continue to be updated with bug fixes while newer series press
forward with new compatibility-breaking features. Nonetheless, it seems
to me from reading the linked threads that the scala developers are
taking the importance of one day maintaining fully binary compatibility
across releases very seriously, and even though they might not be there
yet I think that there is hope that they will figure out a way to make
it work without sacrificing the flexibility needed to keep improving the
language.

Until then, there is no reason why you can't just keep using the old
2.8.1 release of Scala until you have a compelling need to upgrade;
that is certainly what I've been doing in my own projects when I haven't
felt like figuring out what changes I need to make to migrate to the
newer version. Furthermore, it looks like they have been working extra
hard to preserve source compatibility, so it isn't clear to me why it is
such a big deal for you to just recompile all of your sources against
the new release (though of course you might have good reason why this
would be a problem that you haven't mentioned!)

Cheers,
Greg

On Wed, May 25, 2011 at 12:00 PM, Andrey Somov
wrote:
> Nevertheless there is no progress. At least, I do not see any progress.

There is a lot of progress. All of Scala 2.8.x releases were binary
compatible. That was not true for 2.7.x. A prototype of the Migration
Manager has been developed and @bridge annotation support was
introduced in the compiler.

> 4) In Scala to say 'library-1.0' has no meaning. It must be
> 'library_2_7_6-1.0', 'library_2_7_7-1.0', 'library_2_8_0-1.0',
> 'library_2_8_1-1.0', 'library_2_9_0_RC1-1.0', 'library_2_9_0_RC3-1.0',
> 'library_2_9_0-1.0'.
> If you multiply it by the releases of the library itself you can see how
> easy it is to maintain a library.
> You can look here "http://scala-tools.org/repo-releases/net/databinder/" to
> understand what I am talking about.

Actually SBT makes this very easy. And it is why the important
projects had binaries for 2.9.0 very soon after 2.9.0 was released.

> 5) When you take the latest Scala plugin for Eclipse it forces you to use
> 2.9.0. That is why the error happens. The project is still using 2.8.1.

This is more complicated. The reason for that is that a lot of work
went into the presentation compiler to make it more suited for IDE
usage. Still, there has been a discussion about supporting multiple
compiler versions in the Scala plugin for Eclipse and I would not be
surprised if that happened by the time 2.10 is with us.

Progress is being made. As usual, not fast enough for users. :)

Best,
Ismael