Gradle, Groovy, Kotlin. FTW?

15 June 2016


You’ve probably heard about "Kotlin-based approach to writing Gradle build scripts". A lot of noise was produced based on this announcement and Cédric Champeau tried to explain the real state of Groovy, Gradle and their future relationship.

Just to avoid different speculation about "Gradle is written in Groovy" and now "it will be re-written in Kotlin" here are some numbers:

  • Let’s check the Gradle repo language statistic provided by GitHub

gradle github
  • Gradle root folder has several very important sub-folders:

    • buildSrc - It’s related to Gradle build process

    • config - nothing interesting: condenarc and checkstyle configs

    • design-docs - markdown documentation

    • gradle - Gradle scripts

    • subprojects - Gradle sources. It’s our goal to analyze this folder and understand the language statistics

  • subprojects contains several interesting sub-folders:

    • src/main - actual "gradle" source code

    • src/test, src/integTest and src/testFixtures test source code.

  • Now, count the language stats by cloc tool:

    • src/main:

$ cloc-1.66.exe  --match-d="src/main/" --found=oicloc2.log .
    6052 text files.
Wrote oicloc2.log
    5975 unique files.
    1881 files ignored. v 1.66  T=19.50 s (298.2 files/s, 23192.5 lines/s)
Language                     files          blank        comment           code
Java                          5466          56689         128109         238097
Groovy                         278           3100           5179          14336
JavaScript                       3            160            272           4528
XML                             15              8              0            669
CSS                              6             64             38            354
XSLT                             1             24             31            140
C++                              7              7              0             51
C                                6             22             22             50
Scala                           15             12             39             50
C/C++ Header                     6              9              4             33
HTML                             3              9             17             24
Objective C++                    2              7              0             18
Assembly                         2              1              0             17
JSP                              3              0              0             14
IDL                              1              2              0             14
Objective C                      1              3              0              7
SUM:                          5815          60117         133711         258402

Based on this raw analysis we have 93% Java files and 4.7% Groovy files.

  • Let’s add test ( src/test, src/integTest and src/testFixtures) folders to our statistics:

$ cloc-1.66.exe  --match-d="src/(test|integTest|testFixtures)/" --found=oicloc3.log .
    3867 text files.
Wrote oicloc3.log
    3775 unique files.
    2657 files ignored. v 1.66  T=15.24 s (243.1 files/s, 29213.4 lines/s)
Language                     files          blank        comment           code
Groovy                        3043          65654          47398         291716
Java                           536           5830           7278          23568
XML                             57             19             36           1845
Maven                           22             57             20            571
HTML                            10             18             10            430
Scala                           24             48            122            162
JavaScript                       5             14             13            105
CSS                              1             19              0             91
DTD                              1             54            164             33
XSLT                             2              6              0             20
CoffeeScript                     1              7              8             13
YAML                             1              0              0              7
JSP                              1              0              0              6
SQL                              1              2              1              2
C                                1              0              0              1
SUM:                          3706          71728          55050         318570

As You can see we have 14.5% Java files and 82% Groovy files.


Gradle is Java-based project and it uses Groovy for testing and as a DSL implementation tool, nothing more. The noise around "Groovy vs Kotlin" for DSL implementation inside Gradle sounds strange. Gradle Inc. has just made pragmatic decision. That’s it.

Java Day - Kiev, 2015 - Report

08 November 2015


November 6-7, 2015 I visited Java Day Kyiv conference. This report is for myself just to keep track talks I've attended.

Day 1

Day 2


How to run Netflix Eureka via Webapp Runner?

20 October 2015


Some time ago I had to run Netflix Eureka server (to be more specific itwas version 1.1.151) not using Spring Boot.

There were several ways:

I decided to go with Webapp Runner.

So, here is the list of steps:

  1. Download eureka-server war from maven central (e.g. Also, we can clone the Netflix Eureka github repo and perform build locally. But, our intent is just get ready to use war file as quick as possible.
  2. Rename eureka-server-1.1.151.war to eureka-server.war.
  3. Download webapp-runnner jar from maven central (e.g.
  4. I assume that eureka-server.war and webapp-runner- are located in the same directory. Now we can simply run the eureka-server on port 4000 via runme.bat file:
$ cat runme.bat
java -jar webapp-runner- eureka.war --path /eureka --port 4000

Local directory should have the next files/folders:

$ dir /b

The server is up and running: check Eureka UI http://localhost:4000/eureka/ or registered apps http://localhost:4000/eureka/v2/apps/ XML output.


Distribute application as Native Single binary

25 September 2015


Some time ago I had a pleasure to implement Ruby-based tool which theoretically must be easy to install and have no or limited dependencies.
I've picked JRuby and packed/distribute the application as a jar. I.e. JRE was the single dependency I had. In general it was very nice distribution model despite the fact that non-Java users must install JRE (Java SE Runtime Environment) to run the application.

All other approaches like Ruby, Python, Perl, etc. were not acceptable as they requires additional user's efforts for tool installation and/or package distribution.

The idea was/is to have single native binary for all major platforms which requires no dependencies. Simply copy and run.

Now, the question: did I have other alternatives to implement this tool? Could it be implemented as native static binary? - Answer - YES. But, at that time there were only two mature solutions (acceptable for me): C and C++. And neither of them were very good for tool implementation and prototyping at the same time. Also, as far as I know, it's not a simple task to implement really cross-platform app, at least for Windows/Linux/OSX in C/C++. It adds additional maintenance efforts which I tried to avoid.

Looking now at this task I can say that this king of application is nice to implement in Go. Go has everything I need for really cross-platform application development and single static binary output which is awesome for tools/utilities writers.

I decided to look around and understand which other popular languages support compilation/packaging to native (semi-)single static binary. The term "semi-single" static binary will be explained later.


Quick googling give us the next languages:

Haskell, OCaml and Lisp are not widely used. And these langs should be picked carefully due to language specific learning curve.

D language is not young and has small community. But it's much simpler and clean compared to C++, IMHO.

Rust is the new hype along with Go. I guess it will be good alternative to C/C++. Also, the language is much more powerful compared to Go, it might be additional selling point.

Dynamic Languages

There is no direct compilation from interpret/dynamic language to native static binary. But, it's possible to pack application with language runtime into "archive"/executable to behave like static native binary.

Based on the list above, Python has many alternatives to accomplish single distribution artifact task. I.e. it's better to pick Python than other alternatives. Also, it looks like Ruby has limited and poor choices, i.e. it's not suitable for this kind of task.


IMHO, Go has the most appealing tool chain for accomplish this task.

Older posts are available in the archive.