A new approach to configuration in Gradle 3.4 ends 'dreaded' classpath leakage Credit: napoliroma Gradle, the build system of choice for Android mobile development, has been upgraded with better support for building Java applications. Gradle 3.4 offers fast incremental results and “the end of dreaded compile classpath leakage,” said Cedric Champeau, a software engineer who has worked on developing the tool. Changes in the upgrade can dramatically improve build times, he said. Classpath leakage refers to elements on the classpath of a library required for compiling sources leaking to the classpath of dependent libraries or applications. To halt this problem, a separation is introduced between the “api” and “implementation” configurations, so dependent projects only see the classpath from the api configuration; hence, only the libraries necessary to use the public-facing interfaces to the library see it. Implementation-specific external libraries would be on the “implementation” classpath and not visible to the dependent library’s compile classpath. The upgrade’s compile avoidance capability is enabled by a mechanism that offers up-to-date checking of Java compilation sensitive to public API changes only. If a comment or even a private API is changed in a downstream project, Java compilation for upstream projects will be up to date. An experimental incremental compiler featured previously becomes stable in the 3.4 upgrade. It also offers better performance. The compiler, which will become the default soon, leverages in-memory caches living in the Gradle daemon across builds, thus making it significantly faster, Champeau said. Gradle 3.4 also features a Java library plugin for building a component for use as a dependency from another project. This provides a stronger separation between public and private code and improves performance and enforces architectural boundaries on the build level. Software DevelopmentTechnology IndustryOpen SourceDevelopment Tools