assertEquals("ThreadLocal Kryo should work correctly", original, deserialized);
        }
    }

    /**
     * Test serialization with large data
     */
    @Test
    public void test_serializeDeserialize_largeData() {
        List<String> original = new ArrayList<>();
        for (int i = 0; i < 1000; i++) {
            original.add("Item number " + i);

var writeTests = []WriteTest{
	{
		Name:   "foo",
		Data:   []byte("Rabbits, guinea pigs, gophers, marsupial rats, and quolls."),
		Method: Store,
		Mode:   0666,
	},
	{
		Name:   "bar",
		Data:   nil, // large data set in the test
		Method: Deflate,
		Mode:   0644,
	},
	{
		Name:   "setuid",
		Data:   []byte("setuid file"),
		Method: Deflate,
		Mode:   0755 | fs.ModeSetuid,
	},
	{
		Name:   "setgid",

       * work under Android.
       *
       * (Clearing inheritableThreadLocals could still be useful independent of class unloading, but
       * that's a larger problem, which we don't attempt to solve anywhere else in Guava.)
       */
      return null;
    }
    try {
      Field inheritableThreadLocals = Thread.class.getDeclaredField("inheritableThreadLocals");

		if field == nil {
			continue
		}

		if len(joinFields) == 0 || len(joinFields[idx]) == 0 {
			db.AddError(field.Set(db.Statement.Context, reflectValue, values[idx]))
		} else { // joinFields count is larger than 2 when using join
			var isNilPtrValue bool
			var relValue reflect.Value
			// does not contain raw dbname
			nestedJoinSchemas := joinFields[idx][:len(joinFields[idx])-1]
			// current reflect value

//
//   - <KbBlockSize>
//     Veeam Block Size for backup and restore processing before compression is applied. The higher the block size, the more
//     backup space is needed for incremental backups. Larger block sizes also mean less performance for random read restore
//     methods like Instant Restore, File Level Recovery, and Database/Application restores. Veeam recommends that vendors

        assertEquals(expectedTime, decoded.getLastWriteTime());
        assertEquals(0, decoded.getAttributes());
    }

    @Test
    @DisplayName("Test with large time values")
    void testWithLargeTimeValues() throws SMBProtocolDecodingException {
        // Use large but valid time values
        long largeTime = System.currentTimeMillis() + 365L * 24 * 60 * 60 * 1000; // 1 year from now
        int maxAttributes = Integer.MAX_VALUE;

   * typically useful for {@code return} statements. That leaves the code with two options: Either
   * add the suppression to the whole method (which turns off checking for a large section of code),
   * or extract a variable, and put the suppression on that. However, a local variable typically
   * doesn't work: Because nullness analyses typically infer the nullness of local variables,

   * typically useful for {@code return} statements. That leaves the code with two options: Either
   * add the suppression to the whole method (which turns off checking for a large section of code),
   * or extract a variable, and put the suppression on that. However, a local variable typically
   * doesn't work: Because nullness analyses typically infer the nullness of local variables,

        return b;
    }

    /**
     * Get the maximum of two dialect versions
     *
     * @param a the first version to compare
     * @param b the second version to compare
     * @return larger of the two versions
     */
    public static DialectVersion max(final DialectVersion a, final DialectVersion b) {
        if (a.atLeast(b)) {
            return a;
        }
        return b;
    }

## Why this policy exists

There is a fundamental **asymmetry** between submitting a contribution and reviewing one: AI tools make it easy to generate and submit large amounts of code, but they do not make it equally faster for us to review it. 
This policy protects our limited review budget, allowing us to invest our attention wisely.