The Gradle team is pleased to announce Gradle 4.9.
First and foremost, this version of Gradle features experimental new lazy task API. In a nutshell, the new API allows builds to avoid the cost of creating and configuring tasks during Gradle's configuration phase when those tasks will never be executed. This makes every Gradle invocation faster, including IDE syncs.
Gradle projects that have adopted these new APIs have seen 10-15% faster configuration times. This chart shows the performance impact for a few projects.
You will see configuration times reduced more and more as Gradle tasks are converted to use them. Gradle task and plugin authors: we need your feedback on this new API! Please read the documentation, try it out in non-production environments, and file issues on GitHub or discuss on the forum.
Next, publishing tools get some more love: projects that publish auxiliary publications (e.g. test fixtures) through
ivy-publish can now be depended upon by other projects in the same build. There is also a new Publishing Overview chapter in the user manual and updates throughout the documentation regarding publishing artifacts using Maven and Ivy.
In addition to lazy tasks use, Kotlin DSL build scripts are evaluated faster with version 0.18.4, included in this version of Gradle. IntelliJ IDEA and Android Studio user experience is also improved. See details in the Kotlin DSL v0.18.x release notes.
You can now pass arguments to
JavaExec tasks directly from the command-line using
❯ gradle run --args 'foo --bar'
No more need to hard-code arguments in your build scripts. Consult the documentation for the Application Plugin for more information.
Last but not least, this version of Gradle has an improved dependency insight report. Read the details further on.
Switch your build to use Gradle 4.9 RC1 quickly by updating your wrapper properties:
./gradlew wrapper --gradle-version=4.9-rc-1
Standalone downloads are available at gradle.org/release-candidate.
Here are the new features introduced in this Gradle release.
Command line arguments can be passed to
--args. For example, if you want to launch the application with command line arguments
foo --bar, you don't need to hardcode it into the build script - you can just run
gradle run --args 'foo --bar'. See the Application Plugin documentation for more information.
failOnVersionConflict()no longer fails the dependency insight report in case of conflict
The Gradle Native project continues to improve and evolve the native ecosystem support for Gradle.
Gradle now stores more state in the Gradle user home instead of the project directory. Clean checkout builds on CI should now be faster as long as the user home is preserved.
The Java and Groovy compilers both used to leak file descriptors when run in-process (which is the default). This could lead to "cannot delete file" exceptions on Windows and "too many open file descriptors" on Unix. These leaks have been fixed. If you had switched to forking mode because of this problem, it is now safe to switch back to in-process compilation.
Promoted features are features that were incubating in previous versions of Gradle but are now supported and subject to backwards compatibility. See the User guide section on the “Feature Lifecycle” for more information.
The following are the features that have been promoted in this Gradle release.
The dependency insight report is now considered stable.
Many types and methods that were previously marked
@Incubating are now considered stable.
Features that have become superseded or irrelevant due to the natural evolution of Gradle become deprecated, and scheduled to be removed in the next major Gradle version (Gradle 5.0). See the User guide section on the “Feature Lifecycle” for more information.
The following are the newly deprecated items in this Gradle release. If you have concerns about a deprecation, please raise it via the Gradle Forums.
EclipseProjecttasks defined for
gradle eclipsemay now run in Buildship
Previous versions of Gradle did not execute the closures defined in
EclipseProject when invoked from Buildship (only those in
EclipseClasspath). Now Gradle executes them both, similarly to when invoked from the command-line.
This leads to a potential change of behavior in this scenario: - These closures were defined for use with
gradle eclipse - The gradle project was later imported into Eclipse, but these definitions were not removed.
The code in these closures will now become active in the
Gradle -> Refresh Gradle Project action.
In previous versions of Gradle, it was sometimes possible to use a GPath expression with a project's task collection to build a list of a single property for all tasks.
tasks.withType(SomeTask).name would create a list of
Strings containing all of the names of tasks of type
SomeTask. This was only possible with the method
Plugins or build scripts attempting to do this will now get a runtime exception. The easiest fix is to explicitly use the spread operator.
We would like to thank the following community members for making contributions to this release of Gradle.
ClassCastExceptionwhen generating Eclipse files for Gradle (gradle/gradle#5278)
javadoctasks of dependent Java projects (gradle/gradle#5221)
NullPointerExceptionwhen extension isn't found (gradle/gradle#5547)
We love getting contributions from the Gradle community. For information on contributing, please see gradle.org/contribute.
Known issues are problems that were discovered post release that are directly related to changes made in this release.