<div dir="ltr"><div>Hi Jan,</div><div><br></div><div>Thanks for taking a look.<br></div><div dir="ltr"><br></div><div dir="ltr">On Tue, Aug 15, 2023 at 8:12 AM Jan Lahoda <<a href="mailto:jan.lahoda@oracle.com" target="_blank">jan.lahoda@oracle.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
  <div><br><blockquote type="cite"><div dir="ltr"><div><div><b>Question</b>: Shouldn't <span style="font-family:monospace">LoaderDelegate.addToClasspath()</span>
            have been passed the <span style="font-family:monospace">--class-path</span>
            flag at some point in the example above? <span style="font-family:arial,sans-serif">JShell's L</span><span style="font-family:monospace">ocalExecutionControl</span>
            uses <span style="font-family:monospace">DefaultLoaderDelegate</span>,
            which uses a class loader of type <span style="font-family:monospace">DefaultLoaderDelegate.</span><span style="font-family:monospace">RemoteClassLoader</span>.
            This would have added <span style="font-family:monospace">classes</span>
            to <span style="font-family:monospace">RemoteClassLoader</span><span style="font-family:arial,sans-serif">'s class path.<br>
            </span></div>
        </div>
      </div>
    </blockquote>
    
    <p>Possibly.<br></p></div></blockquote><div>Thanks for the mild endorsement :) If you don't object I may file a bug for this.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
    </p>
    <p><br>
    </p>
    <blockquote type="cite">
      <div dir="ltr"><b>Question</b>: Shouldn't <span style="font-family:monospace">DefaultLoaderDelegate$RemoteClassLoader</span><span style="font-family:arial,sans-serif"> use the current
              thread's context loader as its parent loader instead of
              defaulting to the system class loader?<br>
            </span>
        
      </div>
    </blockquote>
    
    <p>If that was done from the beginning, maybe. Now, probably not, as
      that would be an incompatible change. Should be possible to have a
      custom ExecutionControl (an instance of or subtype of
      LocalExecutionControl), with custom LoaderDelegate (where,
      possibly, there could be a factory for DefaultLoaderDelegate
      taking a custom ClassLoader). Does not seem this should be very
      too difficult?</p></div></blockquote><div>Yes, it's not too difficult and I've already done it (<a href="https://github.com/archiecobbs/java-console-toolkit/blob/main/jshell/src/main/java/org/dellroad/jct/jshell/LocalContextExecutionControlProvider.java" target="_blank">link</a>) but it's still an annoying hassle...</div><div><br></div><div>But I think we can get the best of both worlds, by adding a new parameter that <span style="font-family:monospace">LocalExecutionControlProvider</span> would accept, e.g. <span style="font-family:monospace">contextLoaderParent=true</span>. This would obviate the need for writing custom a <span style="font-family:monospace">ExecutionControl</span> but also not change the current behavior. Do you see any issue with this idea?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <p>(I am a bit confused about the command line example - at least
      the "agent" (i.e. the
      DirectExecutionControl/LocalExecutionControl) must run inside your
      target VM.)<br></p></div></blockquote><div>I was probably unclear. My point is that, if we're just looking at the available JShell flags and parameters, you have zero control over the execution class path when using local execution. The only control available at all is the JVM classpath setting, which is what that example shows.<br></div><div><br></div><div>This is just a restatement of problem #1, i.e., the <span style="font-family:monospace">--class-path</span> flag is effectively broken when using local execution, because it affects only the compilation class path, and not the execution class path.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
    </p><br><blockquote type="cite"><div dir="ltr"><div><div><b>Question</b>: Should JShell provide a way to "best
            effort" extract a compilation class path from a given
            ClassLoader (and its parents)? It could work for any <span style="font-family:monospace">URLClassLoader</span>
            instances, but being part of the JDK it could also take
            advantage of inter-module access to the system and other
            built-in class loaders, which are all of type <span style="font-family:monospace">jdk.internal.loader.BuiltinClassLoader</span>,
            which has an internal <span style="font-family:monospace">URLClassPath</span>
            field.</div>
        </div>
      </div>
    </blockquote>
    
    <p>Sorry, I don't think so. There has been some thinking some time
      ago on supporting compilation based on ClassLoaders, but it is
      fairly tricky, and very easy.</p></div></blockquote><div>I assume you meant "not very easy" there...<br></div><div><br></div><div>I'm curious to learn more.  Do you recall the upshot of that thinking? Does it "work"? If not, what are the limitations?<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>Having heuristics inside JShell to
      read some data from some ClassLoaders does not sounds like a very
      good idea to me, sorry.</p></div></blockquote><div>I have to agree. This would be gross/hacky and I don't really like it either (even though this is the workaround I'm currently being forced to use).<br></div><div><br></div><div>For the sake of argument, suppose we found a reliable way to make a <span style="font-family:monospace">ClassLoader</span> look like a <span style="font-family:monospace">JavaFileManager</span>. Then all that would be missing is a way to configure it in the <span style="font-family:monospace">JavaShellToolBuilder</span>.</div><div><br></div><div>Is there any particular reason why <span style="font-family:monospace">JavaShellToolBuilder</span> couldn't have a <span style="font-family:monospace">fileManager()</span> method like <span style="font-family:monospace">JShell.Builder</span> does?</div><div><br></div><div>Thanks,</div><div>-Archie<br></div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>