2.8.0/2.8.1 Binary incompatibility of RichInt#until(Int)

Hello Jason,

The name "2.8.1-SNAPSHOT" is a misnomer; right now it reflects the content
of trunk, but not everything that is in there will end up in the actual 2.8.1.

You should check instead the content of the "2.8.x" branch in SVN, which is
currently very close to what the 2.8.1 release will be.

That is a recurring source of confusion: the version number in trunk is not
necessarily related to any specific upcoming release. We will probably
rename the version number in trunk shortly, in order to avoid this issue in
the future.

At this time we just need to get some feedback from the scala-tools.org
people, as the version number that we set in trunk ends up visible in the
nightly executable, and is currently related to the name used in the Maven
repository.

We could set up the version number in trunk to "9.9.9", or "trunk", and
push it to Maven with the name "trunk-SNAPSHOT", or "SNAPSHOT", or
"devel-SNAPSHOT" for instance, or "9.9.9-SNAPSHOT", as they prefer.

I am copying this message to the scala-tools admins in order to get their
opinion on the matter.

Toni

Jason Zaugg wrote:
> 2.8.0
>
> class RichInt {
> def until(end: Int): Range = Range(start, end)
> }
>
> E:\code\scratch\binary-compat>javap -classpath
> \tools\scala-2.8.0.final\lib\scala-library.jar scala.runtime.RichInt
> Compiled from "RichInt.scala"
> public final class scala.runtime.RichInt extends java.lang.Object
> implements scala.Proxy,scala.math.Ordered,scala.ScalaObject{
> public scala.collection.immutable.Range$ByOne until(int);
>
> 2.8.1-SNAPSHOT
>
> http://lampsvn.epfl.ch/trac/scala/changeset/22812/scala/trunk/src/librar...
>
> class RichInt {
> def until(end: Int): Range with Range.ByOne = Range(start, end)
> }
>
> E:\code\scratch\binary-compat>javap -classpath
> \tools\scala-2.8.1.r22935-b20100906020123\lib\scala-library.jar
> scala.runtime.RichInt
> Compiled from "RichInt.scala"
> public final class scala.runtime.RichInt extends java.lang.Object
> implements scala.Proxy,scala.math.Ordered,scala.ScalaObject{
> public scala.collection.immutable.Range until(int);
>
> -jason
>

To clarify, I tested with scala-2.8.1.r22935-b20100906020123,
downloaded from the nightly build page, not with a version from
scala-tools. The 2.8.x branch included the change to RichInt, merged
in r22601 [1]: Sorry about the confusion.

I'm sure there will be other problems like this. Automated
verification via bytecode analysis is really needed to make any claims
about binary compatibility.

That said, binary compatibility isn't actually that important to me --
I was just trying the 2.8.1 compiler on my code to see if a bug with
optimize + specialization was fixed. (It was!)

[1] http://lampsvn.epfl.ch/trac/scala/changeset/22061/scala/branches/2.8.x/s...

-jason

On Tue, Sep 7, 2010 at 10:44 AM, Antonio Cunei wrote:
> Hello Jason,
>
> The name "2.8.1-SNAPSHOT" is a misnomer; right now it reflects the content
> of trunk, but not everything that is in there will end up in the actual
> 2.8.1.
>
> You should check instead the content of the "2.8.x" branch in SVN, which is
>  currently very close to what the 2.8.1 release will be.

On Tue, Sep 7, 2010 at 12:44 PM, Jason Zaugg wrote:
> That said, binary compatibility isn't actually that important to me --
> I was just trying the 2.8.1 compiler on my code to see if a bug with
> optimize + specialization was fixed. (It was!)

Out of curiosity, what bug is this?

Best,
Ismael

The error message and relevant classes are here:
http://gist.github.com/568296. The classes are in separate modules and
separately compiled.

I didn't reproduce in a standalone test case, nor did I attribute the
successful compilation in 2.8.x to a particular commit or ticket.

-jason

On Tue, Sep 7, 2010 at 2:22 PM, Ismael Juma wrote:
> Out of curiosity, what bug is this?

Hi Jason,

On Tue, Sep 7, 2010 at 2:10 PM, Jason Zaugg wrote:
> The error message and relevant classes are here:
> http://gist.github.com/568296. The classes are in separate modules and
> separately compiled.

Thanks for taking the time to describe the issue and good that it's
fixed in 2.8.1.

> I didn't reproduce in a standalone test case, nor did I attribute the
> successful compilation in 2.8.x to a particular commit or ticket.

I see, I thought there was a ticket already. I certainly didn't want
to give you extra work to describe the problem. :)

Best,
Ismael