Baeldung

Java, Spring and Web Development tutorials

Read a Gradle Defined Variable in Java
2025-05-17 14:22 UTC by Gaetano Piazzolla

1. Introduction

In this short tutorial, we’ll explore three ways of reading a variable defined in the Gradle file at build time.

This is especially useful if our code needs to behave differently based on some configurations defined during the build – we can define the variable just once instead of duplicating it in both Java and Gradle code. We’ll solve this problem with code generation and variable injection.

2. Generating a Java Class

First, let’s define our Gradle variable:

ext {
   myVersion = '1.2.3'
}

By generating code at build time, we can make a Gradle-defined variable accessible in Java code.

Our first option is to create a Java final class file with a static variable. To do this, we first include in the Gradle Java compile source directories the folder where we’ll create the class:

def generatedDir = "$buildDir/generated-src"
sourceSets {
   main {
      java {
         srcDirs += "$generatedDir"
      }
   }
}

Then we can define a new Gradle task with the simple code to create a new file named BuildConfig.java in the right package:

tasks.register('generateBuildConfig') {
   doLast {
      def outputDir = file("$generatedDir/com/baeldung/gradle/config")
      outputDir.mkdirs()
      def file = new File(outputDir, "BuildConfig.java")
      file.text = """
         package com.baeldung.gradle.config;
         public final class BuildConfig {
            public static final String MY_VERSION = "${myVersion}";
            private BuildConfig() {}
         }
      """.stripIndent()
   }
}

This file might contain any number of variables: in this case, we’re just reading the pre-defined myVersion variable.

If we run the Gradle command generateBuildConfig, the output will be this simple class placed in the build/generated-src/com/baeldung/gradle/config directory:

package com.baeldung.gradle.config;
public final class BuildConfig {
   public static final String MY_VERSION = "1.2.3";
   private BuildConfig() {}
}

And since we’ve added the generated-src directory in the source folder of the project, we can easily read the value with static member access:

assertEquals("1.2.3", BuildConfig.MY_VERSION);

The last step would be to include this task in the standard flow of executions:

compileJava.dependsOn generateBuildConfig

With this configuration, we make sure that the compileJava phase will be executed after the generateBuildConfig.

3. Generating a Property File

Our second option is to create a properties file at build time. This approach is pretty similar to the previous one, but the output and the way of reading the values will be different.

In this case, we need to include the generated resource folder in the resources source directory:

def generatedDir = "$buildDir/generated-resources"
sourceSets {
   main {
      resources {
         srcDirs += "$generatedResourcesDir"
      }
   }
}

Then we can define a generateProperties Gradle task:

tasks.register('generateProperties') {
   doLast {
      def mainResourcesDir = file("$generatedResourcesDir/main")
      mainResourcesDir.mkdirs()
      def mainFile = file("$mainResourcesDir/version.properties")
      mainFile.text = "MY_VERSION=${myVersion}"
   }
}

This task creates a properties file in the build/generated-resources/main directory named version.properties with the following content:

MY_VERSION=1.2.3

We can now easily read the generated property file using the Properties class:

Properties props = new Properties();
props.load(Thread.currentThread()
  .getContextClassLoader()
  .getResourceAsStream("version.properties"));
String version = props.getProperty("MY_VERSION");
assertEquals("1.2.3", version);

In this case, as in the previous one, we need to set up task dependencies:

compileJava.dependsOn generateProperties

With this configuration, the generateProperties task will be executed before compileJava.

4. Injecting the Variable as an Environment or System Property

The easiest method is to inject the variable as an environment or system property. We need to specify the variable injected into the specific task we’re triggering.

As an example, let’s add the variable to the test grade task:

test {
   systemProperty "MY_VERSION", "${myVersion}"
   environment "MY_VERSION", "${myVersion}"
}

It’s possible to do the same with other Gradle tasks, e.g., the bootRun task.

Reading those variables is straightforward:

assertEquals("1.2.3", System.getProperty("MY_VERSION"));
assertEquals("1.2.3", System.getenv("MY_VERSION"));

In this case, we don’t have to edit the order of execution of tasks.

5. Conclusion

In this short article, we discussed three different ways of reading a Gradle-defined variable in Java code. Each method suits different scenarios.

The advantage of using code generation with constants is the compile-time check, which ensures fewer runtime errors.

With runtime injection, we get the most dynamic approach instead: we could theoretically update the value of the variables without restarting the application.

The code belonging to the above examples is available over on GitHub.

       

Content mobilized by FeedBlitz RSS Services, the premium FeedBurner alternative.