# Groovy Apache Groovy is a flexible, extensible Java-like programming language for the JVM with Java interoperability and support for scripting and domain-specific languages. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Java News Roundup: New OpenJDK JEPs, CDI 5.0, Spring, Open Liberty, RefactorFirst, ADK for Kotlin DevFeed: [Java News Roundup: New OpenJDK JEPs, CDI 5.0, Spring, Open Liberty, RefactorFirst, ADK for Kotlin]() Original publisher: [Read original article]() Author: Michael Redlich Published: 2026-09-14T20:15:00Z Content type: news Language: en Sources: [InfoQ]() Topics: [Java](), [Concurrency](), [JDK 27](), [releases](), [Jakarta EE](), [Gradle](), [Groovy]() Tags: [2026](), [architecture-design](), [concurrency](), [development](), [gradle](), [groovy](), [jakarta-ee](), [java](), [java-news-roundup-sep07-2026](), [jdk-27](), [jdk-28](), [kotlin](), [micronaut](), [news](), [open-jdk](), [open-liberty](), [refactorfirst](), [releases](), [spring-framework](), [tornadovm]() ### AI overview A Java news roundup for September 7, 2026, covers new OpenJDK proposals for ahead-of-time compilation and structured concurrency, Jakarta CDI 5.0 and ADK for Kotlin 1.0, Open Liberty, TornadoVM, RefactorFirst, Micronaut, Groovy 6.0, and Gradle 9.8. It also reports current JDK 27 and JDK 28 early-access builds and describes improvements in TornadoVM 6.1.0. ### Source excerpt This week's Java roundup for September 7th, 2026, features news highlighting: new JEPs for ahead-of-time compilation and structured concurrency; GA releases of Jakarta CDI 5.0 and ADK for Kotlin 1.0; the September 2026 edition of Open Liberty; point releases of TornadoVM and RefactorFirst; a maintenance release of Micronaut; and first releases candidates of Groovy 6.0 and Gradle 9.8. By Michael Redlich ## Three Gradle Talks from KotlinConf 2026 (and What to Steal from Each) DevFeed: [Three Gradle Talks from KotlinConf 2026 (and What to Steal from Each)]() Original publisher: [Read original article]() Author: Laura Kassovic Published: 2026-07-28T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Kotlin](), [Groovy](), [ide](), [Scripting](), [Refactoring]() Tags: [2026](), [best-practices](), [build](), [build-tool](), [conference](), [developer](), [dsl](), [event](), [gradle](), [groovy](), [ide](), [kotlin](), [kotlinconf](), [refactoring](), [script](), [scripting](), [talk](), [talks]() ### AI overview The article reviews three Gradle talks from KotlinConf 2026. It explains the progression from Groovy build scripts to the Kotlin DSL and early Declarative Gradle, emphasizing the problems each approach addresses. It also introduces Gradle best practices for organizing and optimizing builds. ### Source excerpt Every year I tell myself I'll watch every conference talk I missed. Every year I get through maybe three before a build breaks and I get pulled back into real life. KotlinConf is the one event where I actually follow through, partly because the talks are short and dense, and partly because a good chunk of my coworkers and friends are on stage. This year in Munich, three of them talked about Gradle: Paul Merlin on the history of our DSLs, Stefan Wolf on best practices, and Marcin Mycek on Declarative Gradle for Kotlin. I watched all three so you can decide which ones are worth your fifteen minutes. A Tale of the Gradle DSLs -- Paul Merlin Paul has been inside Gradle's DSL machinery for years, which makes him exactly the right person to tell this story and exactly the wrong person to pretend the early days were clean. The talk traces how build logic went from Groovy, to the Kotlin DSL, to Declarative Gradle. The useful part isn't the timeline. It's that each of those was solving a real problem the previous one couldn't. Groovy gave us a flexible, dynamic scripting language, which was great right up until you wanted your IDE to tell you what was valid. The Kotlin DSL brought static typing, real autocompletion, and refactoring that doesn't rely on hope. That's why the Kotlin DSL is now the default for new Gradle builds. Declarative Gradle is the next swing: describe what your build is rather than script how it runs. The honest through-line is that none of these fully replaces the last one. Kotlin DSL is where most people should be today. Groovy still runs an enormous amount of the world's build logic and isn't going anywhere fast. Declarative Gradle is early but points at where things are headed. Real talk: if your build scripts are still Groovy and still working, you don't have to panic-migrate this weekend. But if you're starting something new, reach for the Kotlin DSL and let the IDE carry some of the weight. 📺 Watch the talk 10 Gradle Best Practices Every Kotlin Deve ## Best Jenkins Alternatives in 2026 DevFeed: [Best Jenkins Alternatives in 2026]() Original publisher: [Read original article]() Author: Pete Miloravac Published: 2026-07-24T09:56:00Z Content type: article Language: en Sources: [Semaphore Engineering]() Topics: [CI/CD](), [Jenkins](), [Groovy](), [GitHub Actions](), [GitLab](), [Vulnerabilities](), [DevOps](), [Open Source]() Tags: [ci-cd](), [circleci](), [compare](), [devsecops](), [github-actions](), [gitlab](), [groovy](), [jenkins](), [open-source](), [security](), [security-vulnerabilities](), [self-hosted]() ### AI overview A 2026 guide compares Jenkins alternatives and explains why teams migrate away from Jenkins, citing maintenance overhead, plugin conflicts, Groovy pipeline complexity, and security-patch concerns. It highlights Semaphore, GitHub Actions, GitLab CI/CD, and CircleCI for different use cases. ### Source excerpt Jenkins earned its place as the default CI server of the 2010s: it was free, endlessly extensible, and available before any serious managed CI/CD competitor existed. More than a decade later, that same flexibility has become the thing teams complain about most -- plugin sprawl, Groovy pipeline scripts nobody wants to maintain, and infrastructure that [...] The post Best Jenkins Alternatives in 2026 appeared first on Semaphore. ## Jenkins Series DevFeed: [Jenkins Series]() Original publisher: [Read original article]() Author: baeldung Published: 2026-04-03T12:36:55Z Content type: tutorial Language: en Sources: [Baeldung - Ops]() Topics: [Jenkins](), [Automation](), [CI/CD](), [Groovy](), [Scripting](), [Server](), [Open Source]() Tags: [administration](), [automation](), [ci-cd](), [docker](), [jenkins](), [jenkins-series](), [open-source](), [scripting](), [series](), [server]() ### AI overview A tutorial series covering Jenkins pipelines, job management, administration, Groovy scripting, parameterized and parallel builds, and server maintenance across the CI/CD lifecycle. ### Source excerpt This tutorial provides an overview of Jenkins pipelines, job management, and administration. Related Stories Git Series Troubleshoot Docker Daemon Connection Issues in Jenkins Troubleshooting Jenkins 403 No Valid Crumb in Request Error ## First look at Declarative Gradle DevFeed: [First look at Declarative Gradle]() Original publisher: [Read original article]() Author: Sterling Greene Published: 2024-07-24T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [configuration](), [developer tooling](), [Groovy](), [Kotlin]() Tags: [beginners](), [blog-post](), [community](), [configuration](), [developer-tooling](), [dsl](), [eap](), [experimental](), [gradle](), [groovy](), [improvements](), [kotlin](), [preview]() ### AI overview This article introduces the first early access preview of Declarative Gradle, an experimental project aimed at providing a clearer, developer-first declarative build language for Gradle. It describes the Declarative Configuration Language, its relationship to Kotlin syntax, the .gradle.dcl file format, and the restrictions that exclude imperative constructs such as loops, conditionals, and functions. The preview is intended for feedback and is not ready for production use. ### Source excerpt Introduction In our update in November 2023, we announced a new experimental project called Declarative Gradle. That post introduced our ideas for a developer-first software definition and how we planned to fulfill our vision for a declarative build language for Gradle. Since then, we've been working hard to create the first early access preview (EAP) of Declarative Gradle. This blog post provides an update on the project's progress and outlines how you can try it out, provide feedback, and influence our next steps. What is Declarative Gradle? Part of our vision for Gradle Build Tool is to deliver an elegant and extensible declarative build language that allows developers to describe any kind of software in a clear and understandable way. Gradle's build language is already extensible in the most fundamental ways, which results in a high degree of flexibility, but it's not always fully declarative, clear, and understandable. We believe that Declarative Gradle will offer a fundamental advancement in the Gradle user experience for software developers thanks to a developer-first software definition, a declarative DSL, and improvements in developer tooling made possible by these. Note that Declarative Gradle is still in an experimental stage and is not ready for production use. We are providing an early access preview to gather initial feedback from the community. Declarative Configuration Language Gradle's existing Kotlin and Groovy DSLs give users access to a full programming language and ecosystem. This makes build scripts very powerful, but it can also make it harder for beginners to understand them and for vendors to provide tooling on top of Gradle. With Declarative Gradle, we're introducing a new configuration language. In addition to .gradle and .gradle.kts build files, Gradle will also recognize .gradle.dcl, where DCL stands for "Declarative Configuration Language". This language falls into the family of declarative configuration languages, meaning it is non-pro ## Amper: a new way to configure Gradle projects? DevFeed: [Amper: a new way to configure Gradle projects?]() Original publisher: [Read original article]() Author: Gustavo Fão Valvassori Published: 2023-12-08T12:05:34Z Content type: tutorial Language: en Sources: [Touchlab]() Topics: [Gradle](), [Kotlin Multiplatform](), [configuration](), [YAML](), [IntelliJ IDEA](), [Groovy](), [Kotlin]() Tags: [build-system](), [coding](), [community](), [configuration](), [declarative](), [development](), [engineering](), [experimental](), [gradle](), [ide](), [inclusive](), [intellij-idea](), [kotlin-multiplatform](), [software](), [yaml]() ### AI overview The article introduces Amper, an experimental Gradle plugin for configuring Kotlin Multiplatform projects with YAML instead of Groovy or Kotlin configuration code. It explains the declarative approach, required IDE or plugin setup, module.yaml configuration, and changes to project structure. ### Source excerpt Earlier this month, Kotlin Multiplatform went stable. And just a couple of weeks later, they announced a new tool to help with one of the biggest issues we have, configuration. Currently, KMP projects use Gradle as a Build System, and we must agree that it's a great tool. But the complexity around it for new users is a big issue. Amper is a tool to help you configure your projects using a markup language. The main goal is to replace the Groovy/Kotlin programming language with something that can enforce a declarative approach. With a declarative paradigm, you can only declare what needs to be done without implementing it. If you already have experience with Maven, it may be familiar to you. Please note that the tool is in the early stages of development, and its goal is to validate the idea before putting more effort into it. With that in mind, be aware that syntax, language, and other things may change in the future, and it's a very experimental tool. How does it work? According to the docs, Amper is implemented as a Gradle plugin and uses YAML for its project configuration format. In other words, it's still a Gradle environment, but it will use an additional YAML file to configure the project. To be able to use it, you need one of the following environments: Use one of the following IDEs: IntelliJ IDEA 2023.3 or newer and the Amper Plugin; or Fleet 1.26 or newer; Use the Amper build plugin to enable it: In your settings.gradle.kts, add this plugin: id("org.jetbrains.amper.settings.plugin").version("0.1.1") When you open a project with the Amper Plugin in the IDE, it will look for the module.yaml file. This file will contain the configuration for the module (library or application), dependencies, and other project configurations (like the Java version). Also worth noting that it also changes the project architecture. Instead of having a directory for your source set artifacts, you will have multiple src directories. In other words, your commonMain/src/kotlin will be ## Evolution of translations management for Android at Revolut DevFeed: [Evolution of translations management for Android at Revolut]() Original publisher: [Read original article]() Author: Yaroslav T Published: 2023-12-05T17:28:51Z Content type: article Language: en Sources: [Revolut Engineering]() Topics: [Android](), [Development](), [migration](), [Script](), [Gradle](), [Groovy]() Tags: [android](), [development](), [evolution](), [gradle](), [gradle-plugin](), [groovy](), [kotlin](), [management](), [migration](), [translation]() ### AI overview An engineering retrospective on how Revolut evolved Android translation management across multiple apps, modules, and languages. It describes using Lokalise, moving translation downloads from app startup to scripts, and migrating the script from Python to Groovy through a Gradle task. ### Source excerpt Here's everything you need to know about how translations have evolved at Revolut. We currently have 6 apps, with 330 modules containing strings.xml files. And don't forget, we need to support 33 languages. To make the translation process smooth, we use the API of Lokalise. When one of our engineers adds a new string on the platform, it's translated into all languages within 1 hour. After that, we need to download and place the translations into the correct module. Now, from an engineering perspective, here comes the most interesting part! Initial implementation In 2017, we began our expansion, and the first supported languages were French and Polish. We quickly reached a stage where fast translation became an integral part of the feature release process. Using our partner, Lokalise.com, we started implementing translations for a single app (only Revolut retail app existed at the time). We added Lokalise library to our project and used keys from it via a Singleton pattern: https://medium.com/media/b55574683f8ebc328b4049d46f1114bf/href Library downloads translations from the server once the user opens the app. This approach was fast to implement, but had 2 limitations: API has user limit, which is critical for the fast-growing application Download translations on app launch degrades the performance First script To answer both of these problems, we created a simple local script that downloads strings and puts them into the resources' folder. Before releasing a new version of the app, one of the engineers has to call this script and merge translated files into the release branch. https://medium.com/media/78c6e72e4148de66b8d461b467b0df55/hrefSimplifying developers' life Later on, one of our engineers introduced an additional script to upload keys to Lokalise. The goal was to let engineers create new keys in strings.xml during the development process, automatically upload them to the provider, translate them, and then download them back. However, we soon discovered that ## build.gradle.kts conversion for Android Studio Empty Activity DevFeed: [build.gradle.kts conversion for Android Studio Empty Activity]() Original publisher: [Read original article]() Author: blundell Published: 2023-07-05T09:45:18Z Content type: tutorial Language: en Sources: [Blundell]() Topics: [Android Studio](), [Gradle](), [Groovy](), [Kotlin](), [configuration](), [ide]() Tags: [android](), [android-studio](), [androiddev](), [blog](), [build](), [configuration](), [explainer](), [gradle](), [groovy](), [intermediate](), [kotlin](), [reference](), [reference-android-androiddev-gradle-groovy-kotlin](), [update]() ### AI overview A quick tutorial converts the default Groovy build.gradle files from Android Studio's Empty Activity template into Kotlin DSL build.gradle.kts files. It also points to Google's and Gradle's guidance on converting build configuration scripts and notes that Kotlin DSL was announced as the new default. ### Source excerpt Quick blog posting showing you the build.gradle.kts version of the default build.gradle file from the "empty activity" Android Studio template. This post will go stale fast, get it whilst its hot. 🙂 The original templates come from the New Project, other templates are explained here: https://developer.android.com/studio/projects/templates Google has an explainer of converting build configuration scripts [...] The post build.gradle.kts conversion for Android Studio Empty Activity first appeared on Blundell. ## How Gradle Works Part 3 - Build Script DevFeed: [How Gradle Works Part 3 - Build Script]() Original publisher: [Read original article]() Author: Bo Zhang Published: 2023-03-10T02:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Groovy](), [Kotlin](), [Programming](), [Programming language]() Tags: [build](), [domain-specific-language](), [gradle](), [groovy](), [kotlin](), [script]() ### AI overview The third article in the How Gradle Works series explains what happens during Gradle build script execution. It describes the Kotlin and Groovy DSLs, including lambda and closure syntax, omitted parentheses, trailing function arguments, chained method invocation, and receiver or delegate objects mapped to Gradle API methods. ### Source excerpt Previously on How Gradle Works: How Gradle Part 1 - Startup How Gradle Part 2 - Inside The Daemon This is the third blog of the series How Gradle Works. In this blog we'll explain what happens during build script execution. Kotlin & Groovy DSL If you are a Java developer, when you open any Gradle build script (for example build.gradle.kts or build.gradle), the first thing that might confuse you is the special syntax of curly braces: // Kotlin DSL: plugins { id("some.plugin") version "0.0.1" } // or Groovy DSL: plugins { id "some.plugin" version "0.0.1" } What's this? What happens when Gradle executes these kinds of scripts? The short answer is: they are DSLs (Domain Specific Language) on top of the Kotlin programming language for .gradle.kts files, or on top of the Groovy programming language for .gradle files. These DSLs have some implicit rules, making them appear very confusing. Implicit Rule 1: Lambda/Closure First of all, { ... } is a special object in both Groovy and Kotlin. This object is called a lambda in Kotlin, or a closure in Groovy. They're similar to function objects in other programming language, like Java's lambda, or JavaScript's function object. You can think of plugins { ... } as a method invocation in which a Kotlin lambda object or Groovy closure object is passed as the argument, because both Groovy and Kotlin allow you to omit parentheses: plugins(function() { ... }) Also, there is one noteworthy DSL: in Kotlin/Groovy, if the last parameter of a function is a lambda/closure, it's allowed to be put outside of parentheses. For example, the following code snippet: tasks.register("myTask") { ... doLast { ... } } is equivalent to: tasks.register("myTask", function() { ... doLast(function() { ... }) }) The code inside the function may be executed immediately or later, depending on the implementation of the specific method. Implicit Rule 2: Chained Method Invocation In the plugins { } example above, the Kotlin version: id("some.plugin") version "0.0.1 ## The Problem with Gradle DevFeed: [The Problem with Gradle]() Original publisher: [Read original article]() Author: Bruce Eckel Published: 2021-01-02T00:00:00Z Content type: opinion Language: en Sources: [Bruce Eckel - Computing Thoughts]() Topics: [Gradle](), [make](), [Groovy](), [Kotlin](), [Programming]() Tags: [article](), [gradle](), [groovy](), [kotlin](), [make](), [programming]() ### AI overview The author explains why Gradle has been difficult to understand after using simpler, dedicated build tools such as make and Ant. They describe Gradle's configuration and mental-model challenges, including the transition from Groovy to Kotlin, and their reliance on others to manage Gradle build files. ### Source excerpt Or: How to Remain Sane when Approaching Gradle (with apologies to Hans Dockter). (James Ward and I go into more detail about this article in the Happy Path Programming Podcast). I started using make in the 80's. When I wrote Thinking in C++, I created a tool I called makebuilder which analyzed the examples extracted from the book and generated an appropriate makefile. make is a dedicated tool that only cares about dependencies and actions, so it is reasonably approachable. ## What's new in Gradle 6.0 DevFeed: [What's new in Gradle 6.0]() Original publisher: [Read original article]() Author: Eric Wendelin Published: 2019-11-26T05:00:00Z Content type: release Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Dependency management](), [toolchain](), [Groovy](), [Java](), [Scala]() Tags: [dependencies](), [dependency-management](), [gradle](), [groovy](), [java](), [new-features](), [scala](), [toolchain](), [webinar]() ### AI overview A webcast presents the main changes in Gradle 6.0, including a new metadata format for describing software components and improvements to dependency management, Java, Groovy, Scala toolchains, and plugin authoring. ### Source excerpt Gradle 6.0 is the culmination of several years of innovative improvements in Dependency Management. Embracing the idea that there is more to software composition and reuse than just putting a set of jar files on the classpath, Gradle now offers a new metadata format to richly define software components that are often made up of multiple files, different variants and specific constraints on their dependencies. In particular, in this webcast Developer Advocate Jenn Strater and Gradle Engineer Jendrik Johannes discuss: What's New in Dependency Management Java, Groovy, and Scala toolchain improvements New features for plugin authors You can access the slides of the webinar here. If you want to try things out, feel free to use the demo project that we used during the webinar. Thanks to everyone that attended the webinar and thanks for your questions! ## Runtime Debugging with Groovy Console DevFeed: [Runtime Debugging with Groovy Console]() Original publisher: [Read original article]() Author: Steve Hannah Published: 2019-11-04T00:00:00Z Content type: tutorial Language: en Sources: [CodeName One]() Topics: [Groovy](), [debugging](), [Tool](), [simulator](), [ui]() Tags: [code](), [debugging](), [dialog](), [groovy](), [programming-language](), [simulator](), [tool](), [ui]() ### AI overview The article introduces a Groovy Console in the Codename One simulator for running code snippets in an app's runtime environment. It demonstrates inspecting the current form, displaying dialogs, and using ComponentSelector to inspect component properties and state. ### Source excerpt We recently added a new tool to the Codename One simulator that will allow you to run arbitrary code snippets in your app's runtime environment. You can access it from "File" > "Groovy Console", while your app is running in the simulator. This will open the following dialog that will allow you to execute arbitrary Groovy code: As you may suspect, you should use the Groovy programming language in this console. If you're not familiar with Groovy, don't worry. The language is basically just Java with some nice short-cuts. In fact, in many cases, you can probably just write Java code, and it will still work. Personally, I like the way that Groovy lets you refer to object properties via their property name, so you don't need to use the getter or setter methods explicitly. E.g. You can do "form.title", instead of "form.getTitle()", to get the form's title. The former is converted into the latter automatically for you. ## How to show Groovy and Kotlin DSL samples side-by-side DevFeed: [How to show Groovy and Kotlin DSL samples side-by-side]() Original publisher: [Read original article]() Author: Eric Wendelin Published: 2018-10-11T04:00:00Z Content type: tutorial Language: en Sources: [The Gradle Blog]() Topics: [Groovy](), [Kotlin](), [Documentation](), [GitHub](), [Markdown](), [CSS](), [HTML](), [JavaScript](), [interactive website](), [Vanilla JavaScript](), [LocalStorage](), [Web Development]() Tags: [css](), [documentation](), [github](), [gradle](), [groovy](), [guides](), [html](), [javascript](), [kotlin](), [markdown](), [ui]() ### AI overview A tutorial on displaying Groovy and Kotlin DSL examples side by side in GitHub READMEs and web-based documentation. It covers Markdown and HTML disclosure elements for GitHub, plus a CSS and vanilla JavaScript language-selector UI for websites that remembers the user's preferred language. ### Source excerpt Gradle build script samples now have Kotlin DSL snippets alongside the Groovy snippets in Gradle 5.0 docs and many Gradle guides. We want you to be able to show both DSLs in your READMEs and web-based documentation, so this post shows ways you can display examples in multiple languages on GitHub and on your websites. Groovy and Kotlin DSL samples on GitHub It's hard to find OSS projects that don't have a README.md or README.adoc. Though there aren't many ways to make these README pages interactive, we can use the
and HTML elements within Markdown or Asciidoc achieve a bit of interactivity yet avoid the verbosity of having multiple subsequent samples in view. Use these code snippets to show multi-language snippets on GitHub.
Groovy ```groovy logging.captureStandardOutput LogLevel.INFO println 'A message which is logged at INFO level' ```
Kotlin ```kotlin logging.captureStandardOutput(LogLevel.INFO) println("A message which is logged at INFO level") ```
++++
Groovy ++++ [source,groovy] ---- logging.captureStandardOutput LogLevel.INFO println 'A message which is logged at INFO level' ---- ++++
++++ ++++
Kotlin ++++ [source,kotlin] ---- logging.captureStandardOutput(LogLevel.INFO) println("A message which is logged at INFO level") ---- ++++
++++ Here it is in action: Note that this won't work for jekyll or static websites, so there we have to write a bit of code. Groovy and Kotlin DSL samples on the web With a bit of CSS and JavaScript, you can make a nice little language selector UI that remembers user selections. The combination of this vanilla CSS, HTML, and JavaScript creates what you see at the top of the post. A little bit about what the code does: First, the JS initializes the preferred language, getting and storing in window.localStorage so that user preferences are saved. Ne ## Yo Dawg! I heard you like Kotlin (Talk at Devfest Baltics) DevFeed: [Yo Dawg! I heard you like Kotlin (Talk at Devfest Baltics)]() Original publisher: [Read original article]() Published: 2018-01-15T00:00:00Z Content type: article Language: en Sources: [Antonio Leiva]() Topics: [Kotlin](), [Android](), [Gradle](), [Groovy](), [kotlin-native](), [iOS](), [Web]() Tags: [android](), [android-development](), [gradle](), [groovy](), [ios](), [kotlin](), [kotlin-native]() ### AI overview A recap of a Devfest Baltics talk about using Kotlin for Android development, replacing XML layouts with Anko, writing Gradle configuration with Kotlin, and sharing code across platforms through Kotlin Multiplatform. ### Source excerpt Everything Android, Kotlin and other random topics ## Tutorial: How to Add Support for other JVM Languages DevFeed: [Tutorial: How to Add Support for other JVM Languages]() Original publisher: [Read original article]() Author: Steve Hannah Published: 2017-07-17T00:00:00Z Content type: tutorial Language: en Sources: [CodeName One]() Topics: [Tutorial](), [Kotlin](), [Java](), [Scala](), [Compiler](), [Groovy]() Tags: [compiler](), [groovy](), [how-to](), [java](), [jvm](), [kotlin](), [programming-language](), [scala](), [tutorial]() ### AI overview This tutorial explains how to assess and port JVM languages to Codename One. It discusses runtime-library requirements, reflection, runtime byte-code manipulation, compiler output, and the example of Kotlin support. ### Source excerpt Update, July 24, 2026: JavaScript builds are now open source, available on every account tier, and buildable locally without a Codename One account. The original post and archived comments below are preserved as published. See the current announcement. As you may have already read, we have just added support for Kotlin in Codename One. In this post, I elaborate on some of the behind the scene work that was involved in bringing Kotlin to Codename One. ## Problem with random test data DevFeed: [Problem with random test data]() Original publisher: [Read original article]() Published: 2017-06-13T00:00:00Z Content type: opinion Language: en Sources: [Paweł Chudzik]() Topics: [Testing](), [data](), [Groovy]() Tags: [business-logic](), [data](), [groovy](), [object](), [test-data](), [testing](), [tests]() ### AI overview The article explains why random test data can make tests hard to reproduce, understand, and maintain once domain objects contain business logic. It recommends using object factories to create valid, predictable test objects. ### Source excerpt Some time ago I noticed new library in our code base - Random Beans which as the name suggests is a tool developed to easily create random data and random objects for testing purposes. Unfortunately, we used it in the wrong way. Here's how we backed up from the random test data to regain control over testing. Read more ## Faster Deployment for Large Services, Support for Node.js 6.10 Runtime with Serverless v1.10 DevFeed: [Faster Deployment for Large Services, Support for Node.js 6.10 Runtime with Serverless v1.10]() Original publisher: [Read original article]() Author: Philipp Müns Published: 2017-03-29T00:00:00Z Content type: release Language: en Sources: [Serverless Blog]() Topics: [serverless framework](), [Node.js](), [Deployment](), [Groovy](), [Template]() Tags: [aws](), [aws-lambda](), [cloud-computing](), [deployment](), [faas](), [framework](), [function-as-a-service](), [groovy](), [infrastructure-as-code](), [news](), [node](), [node-js](), [release](), [serverless](), [serverless-architecture](), [serverless-framework](), [services](), [v1]() ### AI overview The Serverless Framework v1.10 release introduces faster deployment times for large services, support for the Node.js 6.10 runtime, and a Groovy service template. ### Source excerpt Faster deploy times for large services, support for Node.js 6.10 runtime, Groovy service template and more in the Serverless Framework v1.10 release. ## Using Build Types with the Google Services Gradle Plugin DevFeed: [Using Build Types with the Google Services Gradle Plugin]() Original publisher: [Read original article]() Author: Michael Evans Published: 2016-04-01T01:11:55Z Content type: tutorial Language: en Sources: [Gadget Habit]() Topics: [Gradle](), [Android](), [Google](), [Groovy](), [JSON](), [API keys](), [configuration](), [Development]() Tags: [android](), [api-keys](), [code](), [configuration](), [development](), [google](), [gradle](), [gradle-plugin](), [groovy](), [json]() ### AI overview This tutorial explains how to use different Google Services configuration files for Android debug and release builds when the Google Services Gradle plugin supports build flavors but not build types. It presents a Groovy and Gradle task-based workaround that copies the appropriate JSON file into the app module before the Google Services processing task runs. ### Source excerpt If you want to integrate your Android app with most of Google Play Services nowadays, you'll find that you are instructed to set up the Google Services Gradle plugin to handle configuring dependencies. The plugin allows you to drop a JSON file into your project, and then the plugin will do a bunch of the configuration for your project, such as handling the API keys. This is all well and good--unless you're like me (and countless others) and want to use a different configuration for your debug and release builds. This would be useful, as an example, if you use Google Play Services for GCM and would like to have development builds recieve pushes from non-production systems. It seems that the plugin is configured in such a way that it supports build flavors, but it does not yet support build types. However, with a little Gradle magic, we can hack that support in. Disclaimer: This approach worked for me--but as with any hack, it is subject to break. So how can we go about doing this? We want to put the debug JSON file into the root of our app module during debug builds and use the release one for release builds. If you don't do that, or if you attempt to put it in app/debug and app/release, you'll get an error that says File google-services.json is missing from module root folder. The Google Services Plugin cannot function without it. This error is thrown by a task named process{VariantName}GoogleServices. What we could do to solve this is swap the file in before that task is run! Using a little Groovy magic, I came up with this: 1 2 3 4 5 6 7 8 9 10 android.applicationVariants.all { variant -> def hackTask = task("hackGps${variant.name.capitalize()}") << { copy { from rootProject.file("config/${variant.buildType.name}/google-services.json") into "${projectDir}" } } def googleTask = tasks.findByName("process${variant.name.capitalize()}GoogleServices") googleTask.dependsOn hackTask } For each one of your variants, this code will create a new task - hackGps{VariantName}, wh