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

[Archie Cobbs]

On Wed, 4 Oct 2023 18:15:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 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.
>
> test/langtools/jdk/jshell/LocalExecutionTestSupport.java line 38:
> 
>> 36: 
>> 37:     /*
>> 38:      * This is a classfile corresponding to this source:
> 
> Compiling classes in the test is actually usually easier than inlining the bytecode in the test. One can use the `@compile` tag (which may not be ideal here), or `java.util.spi.ToolProvider` with tool `javac` (that can only compile sources on disk to classfiles on disk, but that would still be OK here), or `javax.tools.ToolProvider` (which allows to compile in memory, full or partial), or the `test/langtools/tools/lib/toolbox/ToolBox.java`. Given the context here, `java.util.spi.ToolProvider` might give good results without embedding bytecode in the test.

Thanks - fixed in 50bb7612c16.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15311#discussion_r1346531329