Scala 2.10.0 Moving Away from Java 1.5

[vjovanov]

We'd like to announce that the 2.10.0 Scala release will likely no
longer be byte code compatible with Java 1.5.

The decision was made within the Scala Team due to following reasons:
- As of October 2009, Java 5 has completed its End of Life period (it
is no longer officially supported).
- Scala's concurrency libraries (Parallel Collections,
scala.concurrent, and Actors) are routinely limited due to the lack of
support for concurrency in Java 1.5.
- It greatly complicates the Scala build and test suite.
- Companies with large, slow moving, code base that are still running
on Java 5 will less likely move to Scala 2.10.0 in the near future.

On behalf of the Scala Team,
- Vojin

[Martin Kneissl]

What about compatibility with Android? 

A large fraction of the Android devices in the wild is using Android 2.2 or below (approx 30%). Would you please consider not breaking compatibility with those devices?

Regards,

Martin.

[Paul Phillips]

On Thu, Mar 22, 2012 at 12:38 PM, Martin Kneissl
<m5kn...@googlemail.com> wrote:
> A large fraction of the Android devices in the wild is using Android 2.2 or
> below (approx 30%). Would you please consider not breaking compatibility
> with those devices?

This is a perfect place for the community to get involved. We've
carried java 1.5 an awfully long time, and I've supported that, but
now it's time for the people who still require java 1.5 to carry the
ball.

[Josh Suereth]

Android 2.2 requires java 1.5 classfile format?  Can you compile on Java 1.6 with -target 1.5 for compatibility?   If so, that's a bit simpler to support.

One thing hurting us with remaining in 1.5 classfile format is the improved loading speed for 1.6.

[Paul Phillips]

On Thu, Mar 22, 2012 at 12:43 PM, Josh Suereth <joshua....@gmail.com> wrote:
> Android 2.2 requires java 1.5 classfile format?  Can you compile on Java 1.6
> with -target 1.5 for compatibility?   If so, that's a bit simpler to
> support.
>
> One thing hurting us with remaining in 1.5 classfile format is the improved
> loading speed for 1.6.

There's no reason we'll turn off the ability to generate 1.5 bytecode.
There's nothing holding us back from generating 1.6 bytecode except
the absence of implementation.

[Miguel Garcia]

On Thursday, March 22, 2012 8:47:03 PM UTC+1, Paul Phillips wrote:

 There's nothing holding us back from generating 1.6 bytecode except
the absence of implementation.

I'm giving the final touches to an ASM-based [1] implementation, that in addition to -target:jvm-1.5 will also support jvm-1.6 and jvm-1.7 (according to the ASM literature).

The first prototype should be available next week, for activation via a compiler flag for those willing to try it out.

Miguel
http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/

[1] http://asm.ow2.org/

[Simon Ochsenreither]

YAY! Great to hear! So what will be the new baseline? If we would target at least Java 7 we would have non-retarded filesystem functionality, no compatibility problems with Swing and wouldn't need to ship with ForkJoin.

[Simon Ochsenreither]

Sounds nice! Would definitely love to test it. Will be interesting to figure out if reflection for structural types can be eliminated completely in 7.

[Simon Ochsenreither]

Where do you see the problem? Android does not use the class file format at all. Although it will be interesting to figure out if dex can handle versions 51.0+.

[Nils Kilden-Pedersen]

Not sure if you're aware, but there's no way to tell what you are replying to.

[Simon Ochsenreither]

Where do you see the problem? Android does not use the class file format at all. Although it will be interesting to figure out if dex can handle versions 51.0+.

Ooops sorry. I wanted to reply to Martin.

[Martin Kneissl]

Where do you see the problem? Android does not use the class file format at all. Although it will be interesting to figure out if dex can handle versions 51.0+.

Ooops sorry. I wanted to reply to Martin.

I'm not sure how Android / dex deals with the newer class file format, I'll have to check.

For the library / runtime part I've already had to jump some hurdles. For example, I've been spending some time to integrate the concurrent backport into Akka 1.3 to get it running on Android 2.2. If the basic libraries started to massively use Java 6 concurrency features that cannot be emulated on Android, I'd have a big problem. Please try to isolate / modularize the areas that rely on these features.

Don't get me wrong. I'm glad that Scala moves forward. It shouldn't get stuck the way Java is.  I just wanted to remind the people targeting the massive multi-core server machine parks, that there are people like me on the other side of Scala's spectrum.

I guess it's time to start building with the 2.10 milestones, too, and see if or where things start to fall apart...

Regards,

Martin.

[Jean-Francois Im]

The J7 JVM for Mac is still an Oracle "Developer Preview." (ie. no
JRE, JDK only). It would be pretty annoying to have to install a VM
that doesn't ship with the OS.

Just like you though, I wish it would go away already and we all could
use the new Java 7 features. :)

[Seth Tisue]

On Thursday, March 22, 2012 1:54:12 PM UTC-4, vjovanov wrote:

We'd like to announce that the 2.10.0 Scala release will likely no
longer be byte code compatible with Java 1.5.

For 2.8 and 2.9, I made some noise in favor of Java 1.5 compatibility.

(The issue for us then on the NetLogo project was, some home and school users were still on Mac OS X 10.4 and 10.5. You can get Java 6 for 10.5, but the quality is low.)

So, I should say this now: yes, go ahead, I think it's time now.

-- 

Seth Tisue | Northwestern University | http://tisue.net

lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/

[Bob Jamison]

Sounds great.

When Martin first proposed this a couple of years ago, there were
some users (including me) who were concerned for some OS's like
AIX and RH Server and some server rooms that could not upgrade.
But this problem is now gone for the most part, I think. In fact,
imho, OpenJDK takes care of the problem in general.

This seems like a good idea. Let's use forkjoin without guilt. :)

Bob Jamison
(ishmal)