A DESCRIPTION OF THE REQUEST :
presently the only way we can import a class from thirdparty jar is specify the jar file location as classpath parameter to the jshell command, such as:

jshell --class-path ./sample-api.jar

so, at present, a jshell script is not self-contained. we need a wrapper script to set classpath or any other JVM parameters before we load the jshell

JUSTIFICATION :
scripting is all about ease, and java lacked it for quite a long. fortunately, jshell is filling that gap now, although quite late by a decade. now that it started and quite solidly too, every java shop would want to write build/deployment scripts in jshell, only if the integration of third party java/scripting libraries is made smoother.

if we can have an extensible mechanism with a default load from file/directory, the extensions can be implemented by the large java community with ease. it should be uncompromising goal to make jshell simpler as bash yet powerful as java

wider adoption of jshell will only strengthen the java ecosystem - today because we cannot write scripts in java, we either have to write those in shell/batch scripts, or python or groovy, etc, etc. with the advent of jshell, a java developer need not learn any of those scripting langs and can make better use of what he is good at, i.e. java.



EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -


    it would be better if we can import libraries from the shell itself, perhaps something like :

    import org.apache.tika.parser.Parser from /home/myname/libs/apache-tika-parsers-1.1.6.jar

or

    import org.apache.tika.parser.Parser from http://central.maven.org/maven2/org/apache/tika/tika-parsers/1.16/tika-parsers-1.16.jar

include (script) jvmLaunch.jsh from /usr/local/scripts # load script from directory
include (script) startdb.jsh from /usr/local/lib/scripts.jar #load script from jar
include (script) deployapp.jsh from http://example.com/scripts #load script from url

embed grep from /usr/local/scripts (load command from directory)
embed sed from /usr/local/scripts.jar (load command from jar)
embed cut from https://example.com/commands (load command from url)

where users can provide custom commands to jshell, implementing an interface

    or provide pluggable mechanisms that can be supplied by implementing an SPI to be loaded via standard/default import mechanism

    import org.apache.tika.parser.Parser from maven[org.apache.tika][tika-parsers][1.6.9][compile]


    it would be also good to load the available script engines to jshell, like:

    load lang scala as scala;
    load lang groovy as groovy;
    load lang jawk as awk;
    loag lang juel as el;
    load lang javascript as js;

var x = js.eval('1+1');

we can even set the JVM parameters or system properties like:

set Xmx 2g
set java.io.tmpdir /tmp

after all these imports/inclusions/loads are done with, a new JVM can be created using the same mechanism as used for /reset, /reload, or /env commands after which a new JVM can be launched in the same jshell with the set parameters and imported classes, scripts, commands, and JVM/System parameters.

ACTUAL -
we need another shell/batch script to pass these compile-time classpath parameters, which defeats the purpose of having a scripting environment for java.

CUSTOMER SUBMITTED WORKAROUND :
pass this info as command line arguments at the time of launching jshell, as shown below:

jshell -Xmx2g -Djava.io.tmpdir=/tmp --class-path ./sample-api.jar

importing classes with existing mechanisms like maven/gradle, and including other scripts from the various sources mentioned like files/directories/jar/url is not possible.

similarly, including other langs is only possible by creating an instance of the corresponding ScriptEgine, which is cumbersome.

other scripts can be loaded into jshell but must be mentioned as command line parameters.

 there is no extension mechanism provided, as of now, to add user developed commands