Gradle Meets Kotlin

Posted on by Hadi Hariri

Back at JavaOne 2015, during a lunch break we started chatting with Hans Dockter, CEO of Gradle. A couple of days after the conference, a few of us were at the Gradle offices talking about what would be the beginning of the collaboration between JetBrains and Gradle; to bring first-class tooling and support for a static language to Gradle.

Today, at the Kotlin Night in San Francisco, Hans Dockter demoed the first milestone of writing a Gradle build script using Kotlin.

import org.gradle.api.plugins.*
import org.gradle.api.tasks.wrapper.*
import org.gradle.script.lang.kotlin.*

apply<ApplicationPlugin>()

configure<ApplicationPluginConvention> {
    mainClassName = "samples.HelloWorld"
}

repositories {
    jcenter()
}

dependencies {
    "testCompile"("junit:junit:4.12")
}

Gradle allows developers and build engineers to deal with complex build automation scripts. As complexity grows, having a language that is statically-typed can help detect potential misconfigurations at compile time, contributing in reducing runtime issues. Static typing also opens up the door to more sophisticated tooling. All this, combined with key characteristics of Kotlin that enable easy creation of DSL’s, can provide Gradle users benefits while maintaining the level of fluency they are accustomed to.

For the past 6 months, we’ve been working closely with the Gradle team, in particular with Chris Beams and Rodrigo de Oliveira in bringing Kotlin to Gradle. It has been a tremendously rewarding experience because it has also helped us see use-case scenarios for making scripting in Kotlin a first-class citizen.

We are very excited for what Gradle has in store and are happy to continue collaborating with them closely in bringing a great experience to Gradle users.

For more information and how to get the bits to start playing with this, make sure you read the blog post by the Gradle team for more details. In addition, if you are on the public Kotlin Slack, there’s a newly created #gradle channel for discussions.

Comments below can no longer be edited.

14 Responses to Gradle Meets Kotlin

  1. Nikolay Kolev says:

    May 18, 2016

    Although I understand why,

    mainClassName = "samples.HelloWorld"
    

    is not:

    mainClass = samples.HellowWorld.class
    

    or similar (sorry, I don’t know much of Kotlin) and is prone to typing error.

    • Hadi Hariri says:

      May 19, 2016

      I believe at that point, there’s no knowledge of samples.HellowWorld.class

    • Chris Earle says:

      May 19, 2016

      mainClassName is from the existing Gradle ApplicationPlugin, which is applied at the top. The equivalent existing Gradle script would be:

      apply plugin: "application"
      
      mainClassName = "samples.HelloWorld"
      
      repositories {
          jcenter()
      }
      
      dependencies {
          testCompile "junit:junit:4.12"
      }
      

      The key is that mainClassName is not actually used by the application plugin to do anything except write the name to the jar so that the jar can be used without supplying a class name (e.g., java -jar myjar.jar).

  2. Sergey Igushkin says:

    May 18, 2016

    Great news! It might be interesting to see which of Gradle and Kobalt (http://beust.com/kobalt/home/index.html) will make better use of Kotlin.

    • Rex Rexxar says:

      May 19, 2016

      Well, the significant upshot is that Gradle doesn’t involve that Beust person, so the environment is a bit better.

      • Juan Liska says:

        May 23, 2016

        He is very friendly and responsive, actually

  3. Jason Winnebeck says:

    May 18, 2016

    I’m surprised that Gradle team hasn’t explored using @CompileStatic/@TypeChecked, @DelegatesTo and @ClosureParameters to support auto-completion and compile-time checking. I’ve built similar DSLs with these to support auto-complete and checking in IntelliJ. How does the Kotlin-based solution compared to what you can do with modern Groovy?

    • Hadi Hariri says:

      May 19, 2016

      Jason,

      Unfortunately this is something that is best asked to Gradle, not us.

      • Jason Winnebeck says:

        May 20, 2016

        Well my question was about comparing a solution using static compilation of Groovy with Kotlin. But since posting I’ve learned there has been work on Groovy towards supporting static compilation of Gradle scripts, meaning Groovy’s support is not sufficient. So that is the answer to my question: while Groovy has static compilation mode it is not sufficient to address everything that Gradle can do, so Kotlin has better support for static DSLs like we see here and that makes it a compelling case for Gradle.

        • Cédric Champeau says:

          May 21, 2016

          while Groovy has static compilation mode it is not sufficient to address everything that Gradle can do

          That’s not the case. The experiment shows that it can do what we want. The problem we have now is IDE support (IDEA, Eclipse).

  4. Ivan says:

    May 19, 2016

    Good luck! This unfriendly to humanity build system needs some fresh air.

  5. Issue #206-IT资讯 says:

    May 23, 2016

    […] Gradle Meets Kotlin […]

  6. David Leppik says:

    May 23, 2016

    Awesome! I’m in the process of porting a 15-year-old Ant build to Gradle, and the most frustrating part is the lack of in-IDE documentation. As in: “Where is this coming from?” “What can I put there?” “How does this block really work?”

    Just having the imports in the build file is a real help.

  7. Diario di Grails (settimana 20 del 2016) | BME says:

    May 26, 2016

    […] l’ecosistema Groovy. È possibile trovare gli annunci da Gradle: Kotlin Meets Gradle e da Jetbrains: Gradle Meets Kotlin, così come i pensieri e le risposte in primis di Dan Woods, poi di Cédric Champeau e anche […]

Subscribe

Subscribe for updates