The goal is not to *own* a decision, but to *share* it with other teams, and improve the build tool together.

### Format

The format for ADR should follow this template:

```markdown
# ADR-000X - Title

## Status

- REPLACED by ADR-000X on 20YY-MM-DD
- DEPRECATED on 20YY-MM-DD
- ACCEPTED on 20YY-MM-DD
- REJECTED on 20YY-MM-DD
- PROPOSED on 20YY-MM-DD

## Context

# ADR-0005 - Introduce a UI architecture module to the core platform

## Status

- ACCEPTED on 2024-02-07

## Context

The Gradle core platform provides many services to the Gradle platforms and builds logic. One such group of services allows logic to interact with the build user, to provide diagnostics, progress information, prompt for questions, and so on. Currently, these services are part of the core platform runtime architecture module.

# ADR-0006 - Use of Provider APIs in Gradle

## Status

- ACCEPTED on 2024-06-21

## Context

# ADR-0002 - Avoid using Java serialization

## Status

- ACCEPTED on 2023-12-01

## Context

In Gradle we often need to serialize in-memory objects for caching, or to transmit them across process barriers, etc.
Java serialization is one way to implement this, however, despite its simplicity of implementation, it has several drawbacks:

- **Performance:**
Java's built-in serialization mechanism is often slower compared to other serialization solutions.

# ADR-0003 - Avoid introducing Groovy types to public API

## Status

- ACCEPTED on 2024-01-12

## Context

Gradle's public API requires equal access from all JVM-based languages.
Kotlin, Groovy, Java, and other JVM-based languages should be able to use the Gradle API without relying on another language's standard library.

Historically, Gradle has shipped with some Groovy types in very prominent APIs.

# ADR-0007 - Support running Gradle on multiple Java versions and do not embed a Java runtime in the Gradle distribution

## Status

- PROPOSED on 2024-12-20

## Context

### Embedding a Java runtime in the Gradle distribution

There have been discussions on embedding a Java runtime in the Gradle distribution.
This would allow users to run Gradle without having to install a Java runtime beforehand.

# ADR-0009 - Use American English

## Status

- ACCEPTED on 2025-11-24

## Context

Gradle is an international open-source project with contributors from around the world. English is the primary language for code, comments, documentation, and communication, but there are variations in English spelling and terminology, specifically American English vs. British English.

Inconsistency in spelling conventions can lead to several issues:

# ADR-0010 - Gradle properties naming

## Status

- ACCEPTED on 2026-03-05
- PROPOSED on 2026-02-26

## Context

[Gradle properties](https://docs.gradle.org/current/userguide/build_environment.html#sec:gradle_configuration_properties)
are flags that allow build engineers to opt into and out of features of Gradle Runtime or Core Plugins.
Practically every Gradle feature is behind a flag, and additional sub-flags or options provide further control.

	BEQ	1(PC)
	BEQ	2(PC)
	TBZ	$1, R1, 2(PC)
	TBNZ	$2, R2, 2(PC)
	JMP	foo(SB)
	CALL	foo(SB)

// ADR
	ADR	next, R11     // ADR R11 // 2b000010
next:
	NOP
	ADR -2(PC), R10    // 0a000010
	ADR 2(PC), R16     // 10000010
	ADR -26(PC), R1    // 01000010
	ADR 12(PC), R2     // 02000010
	ADRP -2(PC), R10   // 0a000090
	ADRP 2(PC), R16    // 10000090
	ADRP -26(PC), R1   // 01000090

* Use American English spelling in code, comments, and documentation (e.g., "color" not "colour", "initialize" not "initialise"). See [ADR-0009](architecture/standards/0009-use-american-english.md) for details.