JCrete2013:Polyglot JVM; Scala, Clojure, Groovy; Kotlin
| Polyglot JVM; Scala, Clojure, Groovy; Kotlin | |||
|---|---|---|---|
| Convenor: Andres Almiray; Marcus Schulte; Dmitry Jemerov | |||
Participants:
| |||
Summary:
There were two main driving topics for this session: how to make two different JVM languages working together within the same application; Kotlin's philosophy and insights into its current design. Questions came up regarding compilation of multiple JVM languages within a single project. It's fairly simple to get around the problem if the project consists of multiple modules for which a single language is used in just one module. Compiling them in the right order should be a guarantee of the build tool of choice. However, mixing languages within a single module may prove to be troublesome, particularly when different sources have dependencies on one another. So far, Groovy, Scala, Kotlin and Ceylon provide a compiling mode known as "joint compiler" that allows them to compile Java sources along with their own sources; however this feature cannot be used to mix the other languages together, say for example compile both Scala and Kotlin together. One alternative at the moment is use Java as an IDL between these languages, making sure these IDL is compiled first then the others in any order. The idea of a compiler JSR came up, so that there should be a compiler API that alternative JVM language team members may choose to implement in order to guarantee a multi joint compiler scenario. Tooling support for the main alternate JVM languages came up where the consensus is that IDE support for Java is unmatched so far. Groovy may be the best supported after Java, with Kotlin and Scala closing in behind. For debugging purposes the standar Java debugger should be enough however developers must be aware that these alternate languages may provided longer stacktraces or other byte code artifacts that will make navigating through the code a bit more difficult. Could JDK8 be considered a new language? If looking at Project Coin, Lambdas, multi-catch, ARM blocks then the answer is leaning towards "YES". Kotlin has proved to have a very pragmatic implementation as the team has faced concrete problems and uses cases and acted accordingly, as opposed to the apparent behavior of the Scala community where problem solving looks to be more academic and generalized. Kotlin is capable of inspecting Java code paths to figure out which arguments may be null so thatwhen called from Kotlin the code would have the right restrictions applied. Kotlin also does not provide its own collection API separate of Java's but rather enriches Java's. | |||
| Recommendations:
No recommendations provided. | |||
some raw notes:
Write about PolyglotJvm here.
Andres Stay on the server but more dynamicity. very close to Java readability closure runtime-metaprogramming
Uberto: Used Groovy, hard to get into „idiomatic Groovy“
Michael: Why do we do polyglot? Scala’s parser library fighting with compiler speed people issues: getting developers to write idiomatic code
Is closeness to Java a good thing?
Kotlin (Dmitry) more expressive. difference to Ceylon: compatibility with Java. Collections are the standard Java ones with clean „interfaces“
Dmitry
- Ceylon forks the java-compiler and re-uses backend.
Ignasi: good for testing / „playground areas“
Chris R.: class compatibility is key.
How close should interoperability be?
- compiler-phase plugins
- circular references between an arbitrary number of languages?
- modularization
Microservices or monolithic integration? only on green-field. Juergen: also brown-field.
IDEs.
- Umberto: light-table for clojure / javascript
- Andres: Idea
- debugging is harder
