Subscribe with Email

Comment

This issue includes several Gradle 5.0 links.

First things first. I like Gradle a lot. I use it every day and I benefit from the technology a lot.

But let me speculate on Gradle's future.

Income: Gradle raised 4.2 M on December 2015. Apart from the money raised, we can assume they have a good contract with Google to provide collaboration with Android studio and some lucrative Gradle enterprise contracts with companies such as LinkedIn or Netflix.

Expenses: According to Linked In has 53 employees. It has several open positions in there website. Those engineer salaries are not cheap.

Future: Are they breaking even? I hope I am wrong but I don't think so. Thus, I think we should hear during 2019, either bad news or news about a new round being raised or an acquisition.

Acquisition. Who can acquire Gradle Inc? Microsoft, Google, Jet Brains? I assume Kotlin DSL brings them even closer to Jet Brains. A company, which I guess, is already close to them due to the Android Studio collaboration. Gradle + JetBrains (IntelliJ+IDEA) + Kotlin could create a development experience close to Apple with Xcode + Swift.

Let us see what is the future of Gradle in 2019. I wish them the best success to all of the employees and the company. But let me express several wishes:

Do i wish Gradle had committed to Groovy's development instead of moving to a Kotlin DSL? Yes, of course. Specially, if you have on your payroll Groovy's top contributors.

Do I wish Gradle allowed any of their employees to contribute to Groovy's development now? Yes, i think that could be thoughtful from a company which, one may argue, was built on the shoulders of Groovy. Officially, they don't plan to deprecate their Groovy's DSL. Thus, it is not too late to allow someone to give back to Groovy's codebase.

A wish for 2019, please Gradle, Inc. do not hire Paul King or Daniel Sun and pull them out of Groovy's development. I think you pulled enough talent out of Groovy's ecosystem already.

This is an awesome collection of blog post about building a DSL (Domain Specific Language) with Groovy by @musketyr. I have linked to DSL related content in the past. This is probably the best DSL link, i posted since I started this newsletter 3 years ago.

Micronaut

Normally, I refrain to linking my own content. At least I try to. I recently wrote two articles about Micronaut in InfoQ. I hope you don’t mind.

During this tutorial you will create three microservices with different languages: Java, Kotlin and Groovy. You will also learn how easy it is to consume other microservices with Micronaut HTTP Client and how to create functional tests that run fast.

In this second tutorial article we are going to add several features to our app: distributed tracing, security via JWT and a serverless function. Moreover, we will discuss the user input validation capabilities offered by Micronaut.

Q: Could future version of Gradle gain similar benefits with Groovy @CompileStatic

A: Yes, this is actually a result of the plugins themselves. It can help a little bit but there is much dynamism in all the contracts all the way down that we cannot make it a consistent experience. Kotlin makes that. It enforces static typing.you can gain, have a similar experience with Groovy. We really tried and you know, introducing a whole new DSL is a lot of work and we have done it if we did not think it was absolutely necessary and worth it.

A: No. I mean the Kotlin DSL performance characteristics are very similar to Groovy’s. Kotlin DSL build scripts can be cached in the build cache which makes subsequents uses faster than Groovy but only marginally so. The first compile, the groovy compiler takes a little bit longer with that static typing than Groovy does so the first executions will be a bit slower and subsequents executions will be faster. You know, it depends on the app a bit. There are usually other performance benefits that you can get in other ways than converting to Kotlin DSL. I would make sure that incremental build, build caching, incremental compilation before you consider the Kotlin DSL for performance reasons.