For example, it doesn’t know how to box/unbox our Value Classes, or how to bridge a void-returning method handle to the generic return type of FunctionN::apply by using BoxedUnit. Are there any semantic differences between what Scala has, and what's arrived with Java 8 that you think will cause problems when adopting JDK 8 as a backend? Jason: There are a few corner cases where the semantics of the JDK8 LambdaMetaFactory doesn’t work out of the box for us. InfoQ: Scala has had equivalents of basically the Java 8 capabilities for some time now. The whole effort by its nature crosscuts the whole company: Akka & Play have great Java 8 APIs and we will keep refining them, the Scala IDE and sbt already support Java 8, as does all our other tooling. Several Typesafe engineers are working on Scala’s Java 8 support: specifically, Jason Zaugg is working on Java 8-style lambdas, and Lukas Rytz is continuing the work that Miguel Garcia started on the new ASM-based back-end and optimizer. As always, a significant part of the work will be done by the community. How big a team do you think you'll need to get it done? Adriaan: It’s hard to put a number on the head count of “the Scala team”. InfoQ: From the initial blog post it looks like this is a fairly big change that touches a lot of Scala's subsystems. The 2.12 roadmap has some more details on how we intend to execute this strategy. We want to make it dead simple for open source authors to cross-compile to both versions, which is an important part of making 2.11 a viable target for a longer period of time. To this end, we plan to limit the divergence between 2.11 and 2.12, both in the language and in the library. Rapid adoption of Scala 2.12 is contingent on the availability of the core libraries, testing frameworks, IDE support and other tooling. That said, we realize not everyone will be able to upgrade to Java 8 immediately. Everything about 2.12 is planned around facilitating the upgrade, and we are counting on the community to do so eagerly. As you’d expect with a platform change, the social side is a very important factor. These are the highlights of the technical side of the challenge. Similarly, the 2.11 type checker supports synthesizing Single Abstract Method classes from Scala function literals (when running under -Xexperimental). By moving to Java 8, we no longer have to generate this anonymous class at compile time, but instead use the LambdaMetaFactory at run time. A function’s body is lifted into a private method of the enclosing class, and the anonymous class that’s instantiated to represent the function at run-time consists of a method that simply invokes the lifted method. For example, Scala 2.11 already has an experimental feature which emulates Java 8-style functions as much as possible on Java 6. InfoQ: What do you think the biggest challenges are likely to be when making the change? Adriaan: Moving to Java 8 is a natural evolution for us. Native support for lambdas makes the Java 8 VM an even better host for Scala. InfoQ: What's the biggest driver behind making the change? Adriaan: Targeting the Java platform has been instrumental to Scala’s success and rapid adoption. We’re keen to evolve with the platform to enjoy the improvements made to it and its eco-system. InfoQ caught up with Adriaan Moors (Scala tech lead at Typesafe) and Jason Zaugg (Typesafe engineer) to hear more about this change and how Scala will be making use of Java 8's lambdas implementation. As announced in the recent Scala roadmap, the Scala language will only run on Java 8 and later from Scala version 2.12 and onwards.
0 Comments
Leave a Reply. |