If you have multiple changes to accept (and you're sure they ought to be accepted instead of corrected), you can use the `Accept Changes for all Errors` button to speed the process.
This button will cause a Javascript alert dialog to appear asking you to type a reason for accepting the changes, e.g. "Added new API for Gradle 8.x".

        // Threshold of 0 should be accepted
        request.threshold(0);

        assertEquals(0, request.threshold());
    }

    @Test
    public void testThresholdWithNegative() {
        CurlRequest request = new CurlRequest(Method.GET, "https://example.com");

        // Negative threshold should be accepted (though may not make sense)
        request.threshold(-1);

      recordCompletion();
    }

    private void recordInputCompletion(
        ImmutableList<AbstractFuture<T>> delegates, int inputFutureIndex) {
      /*
       * requireNonNull is safe because we accepted an Iterable of non-null Future instances, and we
       * don't overwrite an element in the array until after reading it.
       */

   * InetAddress}.
   *
   * <p>This method accepts non-ASCII digits, for example {@code "１９２.１６８.０.１"} (those are fullwidth
   * characters). That is consistent with {@link InetAddress}, but not with various RFCs. If you
   * want to accept ASCII digits only, you can use something like {@code
   * CharMatcher.ascii().matchesAllOf(ipString)}.
   *

            // ## Assert ##
            Map<String, List<String>> props = mockHolder[0].getRecordedRequestProperties();
            assertTrue("Accept-Encoding header should be set", props.containsKey("Accept-Encoding"));
            assertEquals("gzip", props.get("Accept-Encoding").get(0));
        }
    }

    @Test
    public void test_CustomHeaders_AppliedToConnection() throws Exception {

# 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-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.

        // Test with no roles
        testUser.setRoleNames(new String[] {});
        assertFalse(fessUserBean.hasRoles(new String[] { "admin", "user" }));

        // Test with single role matching one of accepted
        testUser.setRoleNames(new String[] { "admin" });
        assertTrue(fessUserBean.hasRoles(new String[] { "admin", "user" }));
        assertTrue(fessUserBean.hasRoles(new String[] { "guest", "admin" }));

# 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-0001 - Use Architectural Decision Records

## Status

- ACCEPTED on 2023-12-01

## Context

In a distributed team with many subteams, the best solution to communicate decisions is to use a format accessible by everyone in charge of development.

We use *Specification* and *Discovery* documents stored in Google Drive, but they present some downsides: