Using jshell with libraries

Wed Mar 21 22:10:16 UTC 2018

Thanks Shinya,

I'd definitely like to see the plug-in functionality addressed. We have 
less than three months for the JDK 11 train, but if it is far enough 
long that would work, and if not JDK 12 is only six months after.

As Cay points out, this resolution functionality would be useful for 
exploration as well.  Correct me if I'm wrong but there would be no 
precedent for integrating dependency management into the JDK?  Assuming 
that is true, then plug-in is the path for this. Allowing the plug-in 
JAR to be referenced by URI might ease usage.

-Robert

On 03/21/18 11:24, ShinyaYoshida wrote:
> Hi Sam, Cay, and Robert,
>
> As Robert mentioned above, I've tried to add plug-in feature to jshell.
> We was developing prototypes of plug-in feature like:
> jshell> /plugin add try-artifact.jar
> /resolve is installed
> jshel> /resolve com.amazonaws:aws-java-sdk-s3:1.11.297
> installing com.amazonaws:aws-java-sdk-s3:1.11.297...
> jshell> // now you can use aws-java-sdk-s2
>
> We ware close to the train, but unfortunately, we missed the train of 
> JDK9.
> (Though we've started to discuss such feature after May/2016, the 
> feature complete was May/2016 and feature extension complete was 
> Dec/2016...)
> On the other hand, fortunately, we have a new rapid release cycle model.
> So if it can, I'd like to try to develop the plug-in feature again and 
> ship it as soon as we can.
>
> What do you think?
> Can this kind of feature solve your issues?
>
> JFYI, shebang feature was also requested before and Brian says[1]
> ```
> I understand why you'd like to coopt jshell into this -- after all, it 
> is convenient and it seems "so close" -- but this is trying to turn 
> jshell into something it wasn't designed for. But this wasn't an 
> oversight; we deliberately chose to leave this *outside* of the jshell 
> requirements, because it feels like an entirely different feature. 
> More generally, "hacks" like this always come back to bite you. What 
> you want is a "no main, no compile java runner". Jshell looks like 
> that, but it isn't. When you have nothing, a little of something seems 
> like a really good idea; but the warts will become apparent almost 
> immediately. I'd much rather do nothing for this now, and consider 
> doing something better in the future, than doing something bad now -- 
> which is what this would be.
> ```
> And we actually may have another feature of java command: 
> http://openjdk.java.net/jeps/8192920
>
> FYI for jshell with dependency management system, I'm developing 
> jshell-integration with maven and gradle:
> https://github.com/bitterfox/jshell-maven-plugin
> https://github.com/bitterfox/jshell-gradle-plugin
> Using these plugin, you can launch jshell with dependencies written in 
> pom.xml or build.gradle.
>
> [1]: 
> http://mail.openjdk.java.net/pipermail/kulla-dev/2016-October/001689.html
>
> Regards,
> shinyafox(Shinya Yoshida)
>
> 2018-03-21 12:51 GMT+09:00 Robert Field <robert.field at oracle.com 
> <mailto:robert.field at oracle.com>>:
>
>     [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
>         <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/httpclient/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
>         <http://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.297/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
>
>
>