acceptCh    chan acceptResult // channel where all TCP listeners write accepted connection.
	ctxDoneCh   <-chan struct{}
	ctxCanceler context.CancelFunc
}

// start - starts separate goroutine for each TCP listener.  A valid new connection is passed to httpListener.acceptCh.
func (listener *httpListener) start() {
	// Closure to handle listener until httpListener.ctxDoneCh channel is closed.

/**
 * The abstract helper for configuration.
 *
 * This class provides a basic framework for managing configurations that can be reloaded.
 * It includes functionality for updating configurations in a separate thread and controlling the reloading interval.
 */
public abstract class AbstractConfigHelper {

    /**
     * Default constructor.
     */
    public AbstractConfigHelper() {
        // Default constructor

<!DOCTYPE module PUBLIC
    "-//Puppy Crawl//DTD Check Configuration 1.3//EN"
    "http://www.puppycrawl.com/dtds/configuration_1_3.dtd">

<!-- There are some rules that we only want to enable in an IDE. These  -->
<!-- are extracted to a separate file, and merged into the IDE-specific -->
<!-- Checkstyle config by the `:configureIdeCheckstyle` task.           -->

<module name="IdeFragment">

    <!-- See CONTRIBUTING.md for our guidelines on Javadoc -->

  maven-3.9.x should receive only serious bug fixes, as it is approaching EOL.

Backports are typically handled by maintainers; 
however, after agreement you may open a separate backport PR to the target maintenance branch.
-->

Following this checklist to help us incorporate your
contribution quickly and easily:

                "WEB-INF" + File.separator + "lib" + File.separator);
        // WEB-INF/env/thumbnail/lib
        appendJarFile(cpSeparator, buf, new File(servletContext.getRealPath("/WEB-INF/env/" + getExecuteType() + "/lib")),
                "WEB-INF" + File.separator + "env" + File.separator + getExecuteType() + File.separator + "lib" + File.separator);
        // WEB-INF/plugin

The benefit of a dedicated project for these tests are:
- `qa` projects are dedicated two specific usecases and easier to maintain
- It keeps the specific test logic separated from the common test logic.
- You can run those tests in parallel to other projects of the build.

    assertThat(expected).hasMessageThat().contains("connected");
  }

  public void testIntersection_general() {
    Range<Integer> range = Range.closed(4, 8);

    // separate below
    IllegalArgumentException expected =
        assertThrows(IllegalArgumentException.class, () -> range.intersection(Range.closed(0, 2)));
    assertThat(expected).hasMessageThat().contains("connected");

    <version>999.0.0-HEAD-android-SNAPSHOT</version>
  </parent>
  <artifactId>guava-tests</artifactId>
  <name>Guava Unit Tests</name>
  <description>
    The unit tests for the Guava libraries - separated into a
    separate artifact to allow for the testlibs to depend on guava
    itself.
  </description>
  <dependencies>
    <dependency>
      <groupId>${project.groupId}</groupId>
      <artifactId>guava-testlib</artifactId>

Instead, we use custom serialization where we explicitly describe how data objects should be serialized and deserialized.

For internal purposes, we use binary formats for their brevity.
We use the `Serializer` abstraction to separate the actual implementation of serialization from its uses.

When sharing data with external tools, we use JSON.

## Consequences

# This workflow uses actions that are not certified by GitHub. They are provided
# by a third-party and are governed by separate terms of service, privacy
# policy, and support documentation.

name: Scorecard supply-chain security
on:
  # For Branch-Protection check. Only the default branch is supported. See
  # https://github.com/ossf/scorecard/blob/main/docs/checks.md#branch-protection
  branch_protection_rule: