[[running-your-application]]
= Running your Application with Gradle

To run your application without first building an archive use the `bootRun` task:

[source,shell]
----
$ ./gradlew bootRun
----

The `bootRun` task is an instance of {apiref-gradle-plugin-boot-run}[`BootRun`] which is a `JavaExec` subclass.
As such, all of the {url-gradle-dsl}/org.gradle.api.tasks.JavaExec.html[usual configuration options] for executing a Java process in Gradle are available to you.
The task is automatically configured to use the runtime classpath of the main source set.

By default, the main class will be configured automatically by looking for a class with a `public static void main(String[])` method in the main source set's output.

The main class can also be configured explicitly using the task's `main` property:

[tabs]
======
Groovy::
+
[source,groovy,indent=0,subs="verbatim,attributes"]
----
include::example$running/boot-run-main.gradle[tags=main]
----
Kotlin::
+
[source,kotlin,indent=0,subs="verbatim,attributes"]
----
include::example$running/boot-run-main.gradle.kts[tags=main]
----
======

Alternatively, the main class name can be configured project-wide using the `mainClass` property of the Spring Boot DSL:

[tabs]
======
Groovy::
+
[source,groovy,indent=0,subs="verbatim,attributes"]
----
include::example$running/spring-boot-dsl-main-class-name.gradle[tags=main-class]
----
Kotlin::
+
[source,kotlin,indent=0,subs="verbatim,attributes"]
----
include::example$running/spring-boot-dsl-main-class-name.gradle.kts[tags=main-class]
----
======

By default, `bootRun` will configure the JVM to optimize its launch for faster startup during development.
This behavior can be disabled by using the `optimizedLaunch` property, as shown in the following example:

[tabs]
======
Groovy::
+
[source,groovy,indent=0,subs="verbatim,attributes"]
----
include::example$running/boot-run-disable-optimized-launch.gradle[tags=launch]
----
Kotlin::
+
[source,kotlin,indent=0,subs="verbatim,attributes"]
----
include::example$running/boot-run-disable-optimized-launch.gradle.kts[tags=launch]
----
======

If the {url-gradle-docs-application-plugin}[`application` plugin] has been applied, its `mainClass` property must be configured and can be used for the same purpose:

[tabs]
======
Groovy::
+
[source,groovy,indent=0,subs="verbatim,attributes"]
----
include::example$running/application-plugin-main-class-name.gradle[tags=main-class]
----
Kotlin::
+
[source,kotlin,indent=0,subs="verbatim,attributes"]
----
include::example$running/application-plugin-main-class-name.gradle.kts[tags=main-class]
----
======



[[running-your-application.passing-arguments]]
== Passing Arguments to Your Application

Like all `JavaExec` tasks, arguments can be passed into `bootRun` from the command line using `--args='<arguments>'` when using Gradle 4.9 or later.
For example, to run your application with a profile named `dev` active the following command can be used:

[source,shell]
----
$ ./gradlew bootRun --args='--spring.profiles.active=dev'
----

See {url-gradle-javadoc}/org/gradle/api/tasks/JavaExec.html#setArgsString(java.lang.String)[the javadoc for `JavaExec.setArgsString`] for further details.



[[running-your-application.passing-system-properties]]
== Passing System Properties to Your application

Since `bootRun` is a standard `JavaExec` task, system properties can be passed to the application's JVM by specifying them in the build script.
To make that value of a system property to be configurable set its value using a {url-gradle-dsl}/org.gradle.api.Project.html#N14FE1[project property].
To allow a project property to be optional, reference it using `findProperty`.
Doing so also allows a default value to be provided using the `?:` Elvis operator, as shown in the following example:

[tabs]
======
Groovy::
+
[source,groovy,indent=0,subs="verbatim,attributes"]
----
include::example$running/boot-run-system-property.gradle[tags=system-property]
----
Kotlin::
+
[source,kotlin,indent=0,subs="verbatim,attributes"]
----
include::example$running/boot-run-system-property.gradle.kts[tags=system-property]
----
======

The preceding example sets that `com.example.property` system property to the value of the `example` project property.
If the `example` project property has not been set, the value of the system property will be `default`.

Gradle allows project properties to be set in a variety of ways, including on the command line using the `-P` flag, as shown in the following example:

[source,bash,indent=0,subs="verbatim,attributes"]
----
$ ./gradlew bootRun -Pexample=custom
----

The preceding example sets the value of the `example` project property to `custom`.
`bootRun` will then use this as the value of the `com.example.property` system property.



[[running-your-application.reloading-resources]]
== Reloading Resources

If devtools has been added to your project it will automatically monitor your application's classpath for changes.
Note that modified files need to be recompiled for the classpath to update in order to trigger reloading with devtools.
For more details on using devtools, refer to xref:reference:using/devtools.adoc#using.devtools.restart[this section of the reference documentation].

Alternatively, you can configure `bootRun` such that your application's static resources are loaded from their source location:

[tabs]
======
Groovy::
+
[source,groovy,indent=0,subs="verbatim,attributes"]
----
include::example$running/boot-run-source-resources.gradle[tags=source-resources]
----
Kotlin::
+
[source,kotlin,indent=0,subs="verbatim,attributes"]
----
include::example$running/boot-run-source-resources.gradle.kts[tags=source-resources]
----
======

This makes them reloadable in the live application which can be helpful at development time.



[[running-your-application.using-a-test-main-class]]
== Using a Test Main Class

In addition to `bootRun` a `bootTestRun` task is also registered.
Like `bootRun`, `bootTestRun` is an instance of `BootRun` but it's configured to use a main class found in the output of the test source set rather than the main source set.
It also uses the test source set's runtime classpath rather than the main source set's runtime classpath.
As `bootTestRun` is an instance of `BootRun`, all of the configuration options described above for `bootRun` can also be used with `bootTestRun`.
