Gradle Meets Kotlin

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.

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.

This entry was posted in Events. Bookmark the permalink.

14 Responses to Gradle Meets Kotlin

  1. Although I understand why,

    is not:

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

    • Hadi Hariri says:

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

    • Chris Earle says:

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

      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:

    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:

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

  3. 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:

      Jason,

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

      • 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:

          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:

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

  5. Pingback: Issue #206-IT资讯

  6. David Leppik says:

    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. Pingback: Diario di Grails (settimana 20 del 2016) | BME

Comments are closed.