Scala Meeting Notes: July 31 2012

[Josh Suereth]

This summary is intended for Scala contributors and maintainers, and assumes a certain familiarity with Scala's internals.

It is for your information only, provided “AS IS” with no warranties and it confers no lefts (or rights).

Scala Meeting 2012/07/31

Updates

• serializing closures, nice progress
• IDE worksheet imporvements
• optimizer: bugfixes
• investigating parallelizing optimizer.
• work on tree-based backend
• anyref specialization under a flag
• coursera work
• type debugger (merging with trunk, hit some bugs)
• build infrastructure fixes
• profiling
• community builds

M6

- staged for over a week, things look good
- release notes look good
- 22 libraries available against M6

Questions for Final

• How / where to have scaladoc for akka-actors?
• Should we have an über-scaladoc (swing, actors, actors-migration, …)?
• In future, scaladoc might be able to link to scaladocs of other libraries
• This will become more important when we pull out swing (others) to separate repositories

Future of scala-swing

• Current consensus (not set in stone)

• After 2.10.0 release move into its own github project
• Release JDK 7 variant shortly after
• Create two jenkins builds JDK6 + JDK7 that build scala on those JDKs.
• 2.11 will still target JDK7

[Daniel Sobral]

On Tue, Jul 31, 2012 at 12:30 PM, Josh Suereth <joshua....@gmail.com> wrote:
> Future of scala-swing
>
> Current consensus (not set in stone)
>
> After 2.10.0 release move into its own github project
> Release JDK 7 variant shortly after
> Create two jenkins builds JDK6 + JDK7 that build scala on those JDKs.
> 2.11 will still target JDK7

Was that last one supposed to be "still target JDK*6*"?

--
Daniel C. Sobral

I travel to the future all the time.

[Josh Suereth]

no.  2.11 is moving to JDK 7.   nothing about having scala-swing with JDK6 + JDK7 branches will change the 2.11 target.   We're only going to try to support JDK7 swing on the 2.10.x series.

[Ismael Juma]

On Tue, Jul 31, 2012 at 4:30 PM, Josh Suereth <joshua....@gmail.com> wrote:

• 2.11 will still target JDK7

Nice.

Best,

Ismael

[Alex Cruise]

On Tue, Jul 31, 2012 at 10:05 AM, Josh Suereth <joshua....@gmail.com> wrote:
> no. 2.11 is moving to JDK 7. nothing about having scala-swing with JDK6 +
> JDK7 branches will change the 2.11 target. We're only going to try to
> support JDK7 swing on the 2.10.x series.

I don't particularly care about Swing, I just want to make sure...
We'll still be able to target JDK6 in Scala 2.11, right? :)

-0xe1a

[Ismael Juma]

On Tue, Jul 31, 2012 at 6:21 PM, Alex Cruise <al...@cluonflux.com> wrote:

I don't particularly care about Swing, I just want to make sure...

We'll still be able to target JDK6 in Scala 2.11, right? :)

Oh, I may have misunderstood that statement then.

Best,

Ismael

[Josh Suereth]

The plan (which is not set in stone) is not to target JDK6 for 2.11 but JDK 7 100%.  JDK6 will be end of life on Nov 2012 (see http://www.oracle.com/technetwork/java/eol-135779.html).    Scala 2.11 will not release before then.

- Josh

[Grzegorz Kossakowski]

On 31 July 2012 19:24, Josh Suereth <joshua....@gmail.com> wrote:

The plan (which is not set in stone) is not to target JDK6 for 2.11 but JDK 7 100%.  JDK6 will be end of life on Nov 2012 (see http://www.oracle.com/technetwork/java/eol-135779.html).    Scala 2.11 will not release before then.

And the reason for that is that we want to make 2.11 focused on performance. One of the things we want to address is large number of classes we need to compile coming from lambdas. We would like to compile them into MethodHandles the way Java8 is planning to do.

Still, those are early ideas not set in stone.

--
Grzegorz Kossakowski

[Alex Cruise]

On Tue, Jul 31, 2012 at 10:24 AM, Josh Suereth <joshua....@gmail.com> wrote:
> The plan (which is not set in stone) is not to target JDK6 for 2.11 but JDK
> 7 100%. JDK6 will be end of life on Nov 2012 (see
> http://www.oracle.com/technetwork/java/eol-135779.html). Scala 2.11 will
> not release before then.

OK, this could be a problem for us, and probably a lot of other people
who aren't on -internals or are timid.

FWIW, I already have to *compile* under JDK7, for reasons related, but
tangential to, Scala, but I really value the ability to *run* on a
customer's existing JDK6.

If it's judged too costly for the Typesafe/EPFL team to maintain JDK6
compatibility, maybe the community can fork&exec...

-0xe1a

[Grzegorz Kossakowski]

We'll be maintain 2.10 for quite a while. People that care about legacy platforms (JDK6 soon will become one) should stick to older version of Scala.

--
Grzegorz Kossakowski

[Josh Suereth]

If the changes suggested for 2.11 (method handles) are made, I'm not sure how you'd even fork that for JDK 6.

Again, nothing is set in stone, these are tentative plans.  THE MAIN REASON we publish these notes is so you can give us feedback, so please do!

- Josh

[Lieven Lemiengre]

On Tue, Jul 31, 2012 at 7:31 PM, Josh Suereth <joshua....@gmail.com> wrote:

If the changes suggested for 2.11 (method handles) are made, I'm not sure how you'd even fork that for JDK 6.

You probably know about this but using the jsr-292 backport (maintained by Remi Forax) you can run classes that use methodhandles & indy on a java 6/5 vm.

[Ismael Juma]

On Tue, Jul 31, 2012 at 6:27 PM, Grzegorz Kossakowski <grzegorz.k...@gmail.com> wrote:

And the reason for that is that we want to make 2.11 focused on performance. One of the things we want to address is large number of classes we need to compile coming from lambdas. We would like to compile them into MethodHandles the way Java8 is planning to do.

Awesome!

Best,

Ismael

[Simon Ochsenreither]

Hi Grzegorz,

We would like to compile them into MethodHandles the way Java8 is planning to do.

Won't this require targeting Java 8? Or do you plan to emit Java-7-compatible bytecode which will enjoy the performance benefits only on 8?
Or is Oracle keeping Java 7's InDy/MHs in lockstep with their plans for 8?

Bye,

Simon

[Paul Phillips]

On Tue, Jul 31, 2012 at 10:28 AM, Alex Cruise <al...@cluonflux.com> wrote:

If it's judged too costly for the Typesafe/EPFL team to maintain JDK6
compatibility, maybe the community can fork&exec...

I have no doubt that Typesafe can be persuaded to support jdk6 beyond 2.11.  The open source project should be free to keep moving the ball at least as rapidly as Oracle does.

[Alex Cruise]

On Tue, Jul 31, 2012 at 11:46 AM, Paul Phillips <pa...@improving.org> wrote:
> I have no doubt that Typesafe can be persuaded to support jdk6 beyond 2.11.
> The open source project should be free to keep moving the ball at least as
> rapidly as Oracle does.

Yeah, I was thinking of that... A JDK6 (or even 5?) backport that
still provides new language features and library improvements might be
the first thing that makes Typesafe Subscription really worthwhile for
a lot of people.

"Unfortunately" (for Typesafe), community support is already good,
fast and free. :)

-0xe1a

[Martijn Verburg]

Hi all,

On Tuesday, 31 July 2012 19:52:21 UTC+1, Alex Cruise wrote:

On Tue, Jul 31, 2012 at 11:46 AM, Paul Phillips <> wrote:
> I have no doubt that Typesafe can be persuaded to support jdk6 beyond 2.11.
> The open source project should be free to keep moving the ball at least as
> rapidly as Oracle does.

Yeah, I was thinking of that... A JDK6 (or even 5?) backport that
still provides new language features and library improvements might be
the first thing that makes Typesafe Subscription really worthwhile for
a lot of people.

"Unfortunately" (for Typesafe), community support is already good,
fast and free. :)

-0xe1a

So for us (and I suspect a number of others who are now using Scala in a commercial setting), Java 6 is still going to be an important target platform for a long time to come. I strongly suspect Oracle will extend the EOL period beyond Nov 2012, and even if they don't many enterprises will still stick to Java 6 for some time. I appreciate we could use Remi's lib for backwards compatibility, but if there is a way that future versions of Scala can degrade gracefully (e.g. Their supported VM) then that would certainly allow us to continue with Scala going forwards.

Cheers,

Martijn

[Kevin Wright]

JDK 7 has a few useful tricks (most notably NIO.2, the improved classloading, and JavaFX integration), but nothing that looks to justify a wholesale migration.

A Java-7-only scala-io implementation could easily be made available separately, the same goes for scala FX, so that only leaves the classloading - I see no issue here in simply offering an alternative jar compiled against Java 7 if there's enough demand.

JDK 8 will be an entirely different kettle of fish though.  The potential for increasing performance and interop with lambdas and defender methods is not to be sniffed at!

It wouldn't surprise me if Scala began offering separate java 7/8 distributions when the time comes, in much the same way that people did with the introduction of generics.  I'm just hoping that Jigsaw won't prompt another similar shake-up in Java 9, it would have been nice if all the *big* changes could have happened at the same time...

--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

vibe / skype: kev.lee.wright

steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Ismael Juma]

On Wed, Aug 1, 2012 at 9:48 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

JDK 7 has a few useful tricks (most notably NIO.2, the improved classloading, and JavaFX integration), but nothing that looks to justify a wholesale migration.

You missed the most important one for this discussion: method handles and invokedynamic. It is not yet clear if API changes in method handles will be needed to support Java 8 lambdas or simply underlying performance improvements. If there are API changes needed, then Java 7 may not be enough. If Oracle can improve the performance while maintaining the API, then Scala could simply require Java 7 as HotSpot improvements are shared between multiple Java versions.

Best,

Ismael

[Hanns Holger Rutz]

https://blogs.oracle.com/henrik/entry/java_6_eol_h_h

>
> Cheers,
> Martijn