Using jshell with libraries

Wed Mar 21 13:40:48 UTC 2018

Actually, I would like to be able to use jshell with the AWS library for 
exploration, not for running scripts. And yes, it would be a dreadful 
pain to have to manually identify and acquire a multitude of dependent 
JARs and add them to the class path.

It's not a deal breaker for me if JShell never supports this scenario 
because I can always invoke the Scala REPL from sbt. But that's not a 
convenient option for everyone.

I don't want to drag JPMS into the discussion. It is what it is, and it 
has nothing to do with dependency resolution. There is one standard for 
dependency resolution in the Java world--the ubiquitous mechanism used 
by Maven, Ivy, sbt, etc...

Cheers,

Cay

Le 20/03/2018 à 21:55, Sam Pullara a écrit :
> Let's say I want to send someone a jshell script that accesses S3. What do
> I tell them to do before running it? I'm not intending on using jshell for
> exploration but for running scripts. Even if I was though, I would just add
> those same artifacts to maven.
> 
> UPDATE: While I was writing this I realize that you all didn't intend it to
> work this way at all and that it is supposed to be purely interactive. I
> don't know how you arrived at that decision but not being able to use it
> with
> 
> #!/usr/bin/jshell
> ...script...
> 
> is very surprising since the other normal repls like python, etc intend
> them to be used either for scripting or interactively. It deeply surprises
> me that jshell doesn't ignore the #! at the beginning and still outputs all
> its normal stuff when run in that way and ultimately enters interactive
> mode. Big miss imho. Guess I will move on since the intended use cases
> don't match up with my expectations.
> 
> That said, I agree with you that the compiler should also resolve
> dependencies and we failed to make a module system that handled
> dependencies. Still saddens me that the module system is focused on access
> control rather than dependency resolution. I was on the original JSR and
> pushed as hard as I could for that for years.
> 
> Sam
> 
> 
> On Tue, Mar 20, 2018 at 8:51 PM, Robert Field <robert.field at oracle.com>
> wrote:
> 
>> [Add cc: kawasima]
>>
>> Hi Sam,
>>
>> We have talked about this, but not talked it to death.  Mostly what we
>> talked about are ways to make functionality like this available as a
>> plug-in to JShell.
>>
>> Can you help my understanding of how you use these tools: once you have
>> done your exploration with jshell/try-artifact, do you then download and
>> use -classpath on the compiler or... ?
>>
>> Thanks,
>> Robert
>>
>>
>>
>>
>> On 03/20/18 15:26, Sam Pullara wrote:
>>
>>> Hi all,
>>>
>>> I don't know if you all have talked this to death but the jshell as it
>>> exists today isn't that useful to me because almost all my use cases
>>> require either 3rd party libraries or local code. Downloading the code and
>>> setting the classpath in each environment I want to use it doesn't seem
>>> that great. So instead, I have been using a jshell variant:
>>> https://github.com/kawasima/try-artifact . The variant lets me easily add
>>> 3rd party dependencies in the shell from the central maven repository so
>>> you can do things like:
>>>
>>> |  Welcome to JShell -- Version (version info not available)
>>>
>>> |  Type /help for help
>>>
>>>
>>> -> /resolve com.amazonaws:aws-java-sdk-s3:1.11.297
>>>
>>> |  Path /Users/sam/.m2/repository/com/amazonaws/aws-java-sdk-s3/1.11
>>> .297/aws-java-sdk-s3-1.11.297.jar added to classpath
>>>
>>> |  Path /Users/sam/.m2/repository/com/amazonaws/aws-java-sdk-kms/1.1
>>> 1.297/aws-java-sdk-kms-1.11.297.jar added to classpath
>>>
>>> |  Path /Users/sam/.m2/repository/com/amazonaws/aws-java-sdk-core/1.
>>> 11.297/aws-java-sdk-core-1.11.297.jar added to classpath
>>>
>>> |  Path /Users/sam/.m2/repository/commons-logging/commons-logging/1.
>>> 1.3/commons-logging-1.1.3.jar
>>> added to classpath
>>>
>>> |  Path /Users/sam/.m2/repository/org/apache/httpcomponents/httpclie
>>> nt/4.5.5/httpclient-4.5.5.jar
>>> added to classpath
>>>
>>> |  Path /Users/sam/.m2/repository/org/apache/httpcomponents/httpcore
>>> /4.4.9/httpcore-4.4.9.jar
>>> added to classpath
>>>
>>> |  Path /Users/sam/.m2/repository/commons-codec/commons-codec/1.10/
>>> commons-codec-1.10.jar
>>> added to classpath
>>>
>>> |  Path /Users/sam/.m2/repository/software/amazon/ion/ion-java/1.0.
>>> 2/ion-java-1.0.2.jar
>>> added to classpath
>>>
>>> |  Path /Users/sam/.m2/repository/com/fasterxml/jackson/core/jackson
>>> -databind/2.6.7.1/jackson-databind-2.6.7.1.jar added to classpath
>>>
>>> |  Path /Users/sam/.m2/repository/com/fasterxml/jackson/core/jackson
>>> -annotations/2.6.0/jackson-annotations-2.6.0.jar added to classpath
>>>
>>> |  Path /Users/sam/.m2/repository/com/fasterxml/jackson/core/jackson
>>> -core/2.6.7/jackson-core-2.6.7.jar added to classpath
>>>
>>> |  Path /Users/sam/.m2/repository/com/fasterxml/jackson/dataformat/j
>>> ackson-dataformat-cbor/2.6.7/jackson-dataformat-cbor-2.6.7.jar added to
>>> classpath
>>>
>>> |  Path /Users/sam/.m2/repository/joda-time/joda-time/2.8.1/joda-
>>> time-2.8.1.jar
>>> added to classpath
>>>
>>> |  Path /Users/sam/.m2/repository/com/amazonaws/jmespath-java/1.11.2
>>> 97/jmespath-java-1.11.297.jar
>>> added to classpath
>>>
>>>
>>> -> var s3 = new com.amazonaws.services.s3.AmazonS3Client()
>>>
>>> |  Added variable s3 of type com.amazonaws.services.s3.AmazonS3Client
>>> with
>>> initial value com.amazonaws.services.s3.AmazonS3Client at 463b4ac8
>>>
>>>
>>>
>>> Which is obviously much easier than downloading the artifacts and managing
>>> the classpath. Has there been much thought in adding something like this
>>> to
>>> the jshell that comes with the JDK?
>>>
>>> Sam
>>>
>>
>>

-- 

Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com