As far as I understand, both Scala and Clojure have been designed as new languages that
- depend on the JVM, and
- easily integrate with Java code, in the sense that they allow to use Java classes inside Scala and Clojure code.
Starting with Java 8 (and maybe even more strongly with subsequent versions of Java), there will be changes in the semantics of the Java language.
I wanted to ask how these changes will impact the interoperability between Java and Scala / Clojure and what the consequences will be. For example, since lambdas in Java 8 are not objects (see e.g. here), Scala and Clojure might have to deal with Java values that are not objects. Would this be a problem?
I can think of the following scenarios:
- The Scala or Clojure language will be extended to adapt to the new Java semantics (to handle the new non-object values) and support interoperability with Java.
- The Scala or Clojure language will not be extended. This would only be possible if the new Java features like function values can be mapped to existing concepts. E.g., in Scala even a function is an object, so I guess Java functions would again be wrapped into some kind of objects when they become visible to Scala.
- The Scala or Clojure language will continue to support interoperability up to Java 6 or 7, without following latest Java’s development. This would require that older versions of Java be still supported (at least by OpenJDK or another project), so that these languages can be based on a more conservative / stable branch of Java.
Summarizing: can we expect that the future development of Java will have an impact on languages like Scala and Clojure to maintain interoperability with Java? Is there some (link to) ongoing discussion on this topic already?
Note
I can imagine that Scala, Clojure, and other JVM-based languages won’t have any major problems updating their implementation to newer versions of the JVM (and that new JVM features will make this implementation even easier). My question focuses on features of Java as a language and whether / how other JVM-language will be able to “see” / use these new features, not on whether JVM-based languages will run on the latest JVM’s.
11
Actually Java 8 doesn’t introduce much that will be detrimental to other JVM languages that interop with Java. The work done on Lambdas helped fix a number of small issues around invokedynamic, MethodHandles , MethodReferences etc – but apart from that it’s carry on as normal. That said, there’s a whole new bunch of APIs that the other JVM languages could potentially call into now. Which ones they’ll use by default or not is up to them.
The largest change impacting interop actually came in with Java 7 – with the invokedynamic bytecode that allows dynamic/late binding calls within the JVM – something that was initially designed for the other languages on the JVM. It’s since been very usefully adapted for Lamdbas, so as of Java 8, Java will actually start emitting these bytecodes.
Some languages (JRuby for example) are already heavily using invokedynamic, whilst others (Scala, Groovy et al) are still investigating its use or are in the early stages of patching it in. In theory it makes their dynamic calls almost as performant as existing Java invokestatic calls, as opposed to the myriad of slower workarounds they were forced to use in the past.
Java 9 will bring more challenges for JVM languages with project Jigsaw coming into the platform which will be the beginning of the end for traditionally class loading and classpaths for the JVM. The JVM language folks are pretty aware of this and I expect some sensible collaboration to take place.
13
Scala’s about to be left behind when Java adds lambdas because Java lambdas get assigned a type according to the context they’re used in, whereas Scala lambdas get assigned a type based on their arities, parameter types and return types, so e.g.,
executor.execute(() -> { System.out.println("hello world"); });
from Java 8 can be written in Scala as:
executor execute new Runnable {
override def run() { println("hello world") }
}
unless you use/write some wrappers converting Scala’s () => Unit to Runnable.
7