* Unsafe on modern JVMs (if perhaps not quite as fast as VarHandle?). However, I'm not sure
       * exactly what we've benchmarked, and we certainly haven't benchmarked as far back as JDK 8.
       * (We also haven't benchmarked under Android. We continue to use UnsafeAtomicHelper there so
       * that we don't change the performance there, for better or for worse.) Fortunately, JVM

        item.id = 50L;
        assertEquals(50L, item.getId());

        // Second modification
        item.id = 100L;
        assertEquals(100L, item.getId());

        // Third modification back to 0
        item.id = 0L;
        assertEquals(0L, item.getId());
    }

    /**
     * Concrete implementation of DictionaryItem for testing purposes.

                                </table>
                            </div>
                            <div class="card-footer">
                                <button type="submit" class="btn btn-default" name="list" value="back">
                                    <em class="fa fa-arrow-circle-left">
                                    <la:message key="labels.crud_button_back"/>
                                </button>

						</div>
					</div>
					<div class="text-center">
						<la:link href="/"
							styleClass="btn btn-default">
							<em class="fa fa-arrow-circle-left">
							<la:message key="labels.profile.back" />
						</la:link>
						<button type="submit" name="changePassword"
							class="btn btn-success"
							value="<la:message key="labels.profile.update"/>">
							<em class="fa fa-pencil-alt">

     *
     * @param form the search form containing current state
     * @return HTML response for the search log list page
     */
    @Execute
    @Secured({ ROLE, ROLE + VIEW })
    public HtmlResponse back(final SearchForm form) {
        saveToken();
        return asHtml(path_AdminSearchlog_AdminSearchlogJsp).renderWith(data -> {
            searchPaging(data, form);
        });
    }

    /**

   * expectedCapacity)) rather than O(calls to add).
   *
   * <p>This implementation attempts to detect hash flooding, and if it's identified, falls back to
   * JdkBackedSetBuilderImpl.
   */
  private static final class RegularSetBuilderImpl<E> extends SetBuilderImpl<E> {
    // null until at least two elements are present

   *
   * The [dispatcher][OkHttpClient.dispatcher] defines when the request will run: usually
   * immediately unless there are several other requests currently being executed.
   *
   * This client will later call back `responseCallback` with either an HTTP response or a failure
   * exception.
   *
   * @throws IllegalStateException when the call has already been executed.
   */
  fun enqueue(responseCallback: Callback)

  /*
   * We use large numbers to avoid the integer cache. Normally, we'd accomplish that merely by using
   * `new Integer` (as we do) instead of `Integer.valueOf`. However, under J2KT, `new Integer`
   * gets translated back to `Integer.valueOf` because that is the only thing J2KT can support. And
   * anyway, it's nice to avoid `Integer.valueOf` because the Android toolchain optimizes multiple

  /*
   * We use large numbers to avoid the integer cache. Normally, we'd accomplish that merely by using
   * `new Integer` (as we do) instead of `Integer.valueOf`. However, under J2KT, `new Integer`
   * gets translated back to `Integer.valueOf` because that is the only thing J2KT can support. And
   * anyway, it's nice to avoid `Integer.valueOf` because the Android toolchain optimizes multiple

   * ParametricNullness parametric nullness}. Sometimes, code may receive a null {@code T} but store
   * a "null sentinel" to take its place. When the time comes to convert it back to a {@code T} to
   * return to a caller, the code needs to a way to return {@code null} from a method that returns
   * "plain {@code T}." This API provides that.
   */