<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>On 15. 08. 23 16:41, Archie Cobbs wrote:</p>
    <blockquote type="cite" cite="mid:CANSoFxtRzHvv1M8+XWL9i4gxy=UceRP8RaN_reqdUpvrQcY-wg@mail.gmail.com">
      
      <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" moz-do-not-send="true" class="moz-txt-link-freetext">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">
            <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>
    <p><br>
    </p>
    <p>Sure, please do!</p>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:CANSoFxtRzHvv1M8+XWL9i4gxy=UceRP8RaN_reqdUpvrQcY-wg@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <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://urldefense.com/v3/__https://github.com/archiecobbs/java-console-toolkit/blob/main/jshell/src/main/java/org/dellroad/jct/jshell/LocalContextExecutionControlProvider.java__;!!ACWV5N9M2RV99hQ!NLf38Yz7eZhnS-RW-sdl_Rq5zTa9_4oYqZrKGZEtJm0olgVuLNX3UGDo22Xtt2e0Fdi3pvudhaBLhh6m8YjX7jY$" target="_blank" moz-do-not-send="true">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>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>If a new constructor for LocalExecutionControlProvider taking
      (probably) the ClassLoader would work, that would be a very good
      solution, I think.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:CANSoFxtRzHvv1M8+XWL9i4gxy=UceRP8RaN_reqdUpvrQcY-wg@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <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>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>Yes, sorry.</p>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:CANSoFxtRzHvv1M8+XWL9i4gxy=UceRP8RaN_reqdUpvrQcY-wg@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <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>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>Generally, as far as I know, ClassLoaders can load a
      resource/class given a name, but cannot provide a list of things
      under a directory/package. This causes two problems, IIRC:<br>
    </p>
    - given a file containing only:
    <p><span style="font-family:monospace"><span style="color:#000000;background-color:#ffffff;">import
          does.not.exist.*;</span><br>
      </span></p>
    <p>I believe the specification says there should be an error for
      this import - but for that, we would need to know if there's a
      class (or possibly source) file under 'does.not.exist' or not.
      (There are some similar constrains on exports and esp. opens, but
      those are not relevant to JShell.)<br>
    </p>
    <p>- when the code contains something like "java.util.List", javac
      won't try to load "java.util.List". It will rather list the
      content of the whole "java.util" package, and look if there's a
      "List.class" (or alike) inside. If I remember correctly from the
      time I was experimenting with this, it is probably not impossible
      to change, but not easy, and consequences are not completely
      clear.<br>
    </p>
    <p><br>
    </p>
    <p>Jan</p>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:CANSoFxtRzHvv1M8+XWL9i4gxy=UceRP8RaN_reqdUpvrQcY-wg@mail.gmail.com">
      <div dir="ltr">
        <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">
            <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>
    </blockquote>
  </body>
</html>