RFR: 8314327: Issues with JShell when using "local" execution engine [v2]

[Archie Cobbs]

> There are a few bugs (or "opportunities for improvement") in JShell's support for "local" execution control.
> 
> **Background**
> 
> JShell utilizes two distinct "class lookup" functions. First, it looks up clases when compiling snippets. This happens indirectly via the Java compiler using its `JavaFileSystem` interface. Secondly, JShell executes code by supplying an execution engine with class files and asking it to invoke methods. The execution engine therefore performs a class lookup function when it links and loads these classes. The compilation happens on the local machine while the execution happens either locally or remotely.
> 
> For everything to run smoothly, both of these lookup functions must be working for whatever class(es) you want to name in JShell input.
> 
> Local execution is implemented by `LocalExecutionControl` and provided by the `LocalExecutionControlProvider` under the name `"local"`. In turn, `LocalExecutionControl` uses a `LoaderDelegate` to manage class loading. The default `DefaultLoaderDelegate` uses a custom subclass of `URLClassLoader` (called `RemoteClassLoader`). This class loader has two functions: (a) keep track of snippet classes generated by JShell, and (b) find classes for the execution engine (normal class loader function).
> 
> **Issue 1**
> 
> The `RemoteClassLoader` is hard-wired with the system class loader as its parent loader. This means that in non-trivial class loading scenarios, such as when running in web servlet container, the application's classes are not visible to the local execution engine.  As a result, it's impossible to resolve any of these classes.
> 
> **Issue 2**
> 
> JShell has a `--class-path` parameter that is supposed to handle properly configuring *both* lookup functions, i.e., compilation and execution. Internally, this is done by (a) configuring the compiler's class path, and (b) passing this flag to the execution engine as a "remove VM option".
> 
> However, the "local" execution engine ignores the remote VM options.
> 
> Here's a simple demonstration:
> 
> 
>     $ ls classes/test/Foo.class
>     classes/test/Foo.class
>     $ jshell --execution=local --class-path classes
>     |  Welcome to JShell -- Version 20.0.1
>     |  For an introduction type: /help intro
> 
>     jshell> Class.forName("test.Foo");
>     |  Exception java.lang.ClassNotFoundException: test.Foo
>     |        at URLClassLoader.findClass (URLClassLoader.java:445)
>     |        at DefaultLoaderDelegate$RemoteClassLoader.findClass (DefaultLoaderDelegate.java:154)
>     |        at ...

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Update tests to compile source instead of including bytecode.
 - Merge branch 'master' into JShellStuff
 - Make the DefaultLoaderDelegate class public.
 - Apply the "--class-path" flag to the "local" execution engine.
 - Add new "contextLoaderParent" parameter for LocalExecutionControlProvider.
 - Allow specifying a parent class loader when creating a LocalExecutionControl.
 - Allow specifying a parent class loader when creating a DefaultLoaderDelegate.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15311/files
  - new: https://git.openjdk.org/jdk/pull/15311/files/1e3c5140..50bb7612

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15311&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15311&range=00-01

  Stats: 135560 lines in 3803 files changed: 64113 ins; 27176 del; 44271 mod
  Patch: https://git.openjdk.org/jdk/pull/15311.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15311/head:pull/15311

PR: https://git.openjdk.org/jdk/pull/15311