Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8353590

JShell LocalExecutionControl should allow decorating the execution task

XMLWordPrintable

    • Icon: CSR CSR
    • Resolution: Unresolved
    • Icon: P4 P4
    • None
    • tools
    • None
    • source
    • minimal
    • This is adding a new protected method. Existing subclasses of LocalExecutionControl should not be affected unless they happen to already define the a method with the same name and parameter type.
    • Java API
    • JDK

      Summary

      Add a new method to allow subclasses of JShell's LocalExecutionControl to configure thread-local context in the thread within which snippets execute.

      Problem

      JShell local execution mode is useful for implementing ad hoc tasks within a single application. For example, a Java application may want add support for evaluating Java expressions to its command line interface (CLI), or it may want to support some more general form of Java "scripting" within the application itself.

      In such cases, there is often a need to "decorate" the execution of each snippet by wrapping its execution somehow. For example, a database application may want to automatically open a transaction for the duration of a snippet's execution and make it available to the snippet via its standard mechanism (e.g., ThreadLocal variable, Hibernate session, etc).

      Another example is an application that wants to log something, or track time elapsed, at the the start and stop of every snippet execution.

      Currently this is effectively impossible, because LocalExecutionControl executes snippets in a separate thread and subclasses have no access to the creation or invocation of that Thread.

      To support the use cases described above, JShell's LocalExecutionControl could provide a simple hook that allows a subclass to take action anytime a snippet executes - within the actual thread of execution.

      Note: Currently LocalExecutionControl provides methods clientCodeEnter() and clientCodeLeave(), but these are not useful for the situations described above, because those methods are not invoked in the thread that actually executes the snippet; instead, they are invoked in the thread that creates the thread that executes the snippet.

      Solution

      Add a new protected method that does the work of actually executing the snippet, allowing subclasses to "decorate" that execution by overriding the method.

      Specification

      The patch below shows the new API surface:

      @@ -224,4 +224,25 @@ protected void clientCodeLeave() {
               }
           }
      
      +    /**
      +     * Execute the snippet.
      +     *
      +     * <p>
      +     * This method is invoked within the snippet execution thread to actually execute snippets.
      +     * The given method is a static method that takes zero parameters.
      +     *
      +     * <p>
      +     * The implementation in {@link LocalExecutionControl} just invokes {@code method}.
      +     * Subclasses may override this method to configure thread-specific context during snippet
      +     * execution, etc.
      +     *
      +     * @param method static method to be invoked taking zero parameters
      +     * @return the return value from {@code method}, or null if {@code method} returns void
      +     * @throws IllegalAccessException if {@code method} is inaccessible
      +     * @throws InvocationTargetException if {@code method} itself throws an exception
      +     * @since 25
      +     */
      +    protected Object doInvoke(Method method) throws IllegalAccessException, InvocationTargetException {
      +        return method.invoke(null);
      +    }
       }

            acobbs Archie Cobbs
            acobbs Archie Cobbs
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: