
Jshell: The Java Shell (REPL) - Garbage
http://openjdk.java.net/jeps/222
======
elmarschraml
If you're looking for a REPL for Java, try the Groovy shell (comes standard
with an install of Groovy).

Meant, as the name implies, for Groovy, but since Java is a subset of Groovy,
works fine for any Java code, too.

It's great for quickly trying out an API or library. Also makes it easy to
just drop a bunch of jar files onto the classpath.

~~~
vorg
> Java is a subset of Groovy

Java is _not_ a subset of Groovy. Some syntax valid in both will behave
differently in each, e.g. default visibility, and how == behaves.

------
arturventura
I had to implement a Java REPL like this one in school.

My experience of using it is that tells me that without a undefined type
keyword it becomes very boring to use. Each time you have to define a variable
you have to write all type info:

    
    
        Map<String,String> foo = new HashMap<>();
    

If java had a inferred type declaration, like Golang, Swift, Scala, etc. This
would be much simpler:

    
    
        var foo = new HashMap<String,String>();
    

But from what I think there is nothing like that on Java's roadmap. In fact, I
think it was proposed and rejected in the past.

~~~
josho
What's wrong with simply: Object foo = ...

Not quite var, and it would require the interpreter to do a little bit more
work when invoking methods to avoid the necessary downcasting.

~~~
Alphasite_
Because you're sacrificing consistancy and type safety for object to avoid
increasing the syntax which feels like optimising for the wrong metric.

~~~
jonathankoren
It's a REPL! It's for debugging. If you're not optimizing for ease of use,
you're optimizing for the wrong metric.

~~~
lgas
You could also just add support for the "var x =" notation into the REPL as a
preprocessing step that translates it to the appropriate typed representation.

------
drtse4
If someone is interested in using something like that (minus the API part),
right now, try this: [https://github.com/albertlatacz/java-
repl](https://github.com/albertlatacz/java-repl)

~~~
LoSboccacc
Why everyone keeps forgetting beanshell? It is both a shell and a scripting
language with context bridges to pass object back and forth from java, it was
doing everything groovy became and then some but three or more year earlier

~~~
pjmlp
Because it was left to rotten?

Last time I checked it, in 2010, it didn't had any commits.

~~~
LukeShu
The last release from the original author was 2.0b4 (2.0 beta 4) in 2009.

However, there is a community fork "beanshell2"[1], which was created exactly
because the original was left to rot. It looks like the most recent change to
beanshell2 was February 2014, so it may be going the same direction.

[1]:
[https://github.com/pejobo/beanshell2](https://github.com/pejobo/beanshell2)
(formerly
[https://code.google.com/p/beanshell2/](https://code.google.com/p/beanshell2/)

------
russtrotter
I'd add my vote for using Groovy's shell (groovysh) for Java REPL. The
shortcuts and conveniences the Groovy lang provides make it perfect for this
kind of application.

~~~
vorg
> The shortcuts and conveniences the Groovy lang provides make it perfect for
> this kind of application

Groovy's original purpose, as frequently stated by its creator James Strachan,
was exactly this kind of application. There's been a lot of other things going
on with Groovy since then which anyone considering using it would have to
evaluate. Although other JVM scripting languages existed at the time of its
birth in 2003, e.g. Jython since 1997 and Beanshell since 1999, Groovy brought
more to the JVM than Beanshell had and did it using Java's syntax style,
unlike Jython. Groovy's also used a lot in scripts for manipulating and
testing JVM classes. And it's this use of Groovy that made it a good match for
Gradle, i.e. short 50-liners defining builds.

Groovy's been extended to other use cases since then. Graeme Rocher had a
meta-object protocol added to Groovy so he could bundle it as the scripting
language of Grails (used just like Ruby is in Rails). The backers of Grails
have an overbearing attitude towards Groovy, as they do all the software
Grails bundles. They muscled in on the consulting market for Spring until they
got bought out by SpringSource in 2008. Grails 3, released earlier this year,
bundled Gradle for the first time, and the Grails backers will no doubt use
that as justification to attack Gradleware's placing in the market for Gradle
consulting, and so ultimately wrest control of Groovy via its primary
applications from its neutral home at the Apache incubator.

Groovy was also extended in version 2 by a static type-checking and
compilation facility, which was duplicated from an addon created by Alex
Tkachman. Making no headway into the overcrowded market for statically-typed
JVM languages, last year the Groovy backers then repurposed that static-typing
facility to make Groovy target the Android platform. This year, Groovy's sole
full-time developer supporting it all was retrenched when the Groovy/Grails
group moved from VMware/Pivotal to OCI Consulting.

I'm picking Groovy will remain popular on the JVM for scripting and REPL work,
including Gradle build scripts, for quite a while. It will never be used much
for statically typed work on the JVM or Android, and eventually its use for
scripting a web framework will slowly decline as Grails follows Rails into
eventual obscurity perhaps 5 years down the line. Groovy will continue to
suffer from leadership difficulties, perhaps with the Grails group taking
control of Gradle via a sustained attacked on their consulting business, and
through this eventually taking over the Groovy code base at, or from, the
Apache incubator. I wouldn't want to pick the time frame for all this, though!

~~~
blackdrag
vorg, some corrections for you. Only 2 of 6 did go to OCI. Another 2 did go to
Gradle. And then about Alex Groovy++. At least you are not spreading the false
rumors anymore that the codebase was copied. I have not seen any original
ideas in Groovy++. So what exactly has been duplicated? Plus, Groovy's static
compiler uses flow typing, Groovy++ not. It has a big impact. How can you call
this duplication at all? That is as much duplication as Java is a duplicate of
C.

And I actually think you belittle Alex with your focus on Groovy++. Alex best
work on Groovy was the introduction of callsite caching. That was his best and
biggest work. In terms of features of the language there are surely numerous
other things. But they are sources of trouble. And that is because he did
never finalize his work. Instead he always wanted to have new things and added
half-done code to Groovy. That goes for the stub based compilation, for
mixins, for many of his internal changes. I could make a really long list.
Most of these things have been a huge step forward and a huge source of
trouble.

------
jetpm
I developed something similiar but for the Android API, it goes together with
an app, but it is also a Java Read-Eval-Print Loop where the code is executed
on the device. It's in beta phase.
[https://runondroid.com](https://runondroid.com)

~~~
jnbiche
Oh very cool. I've used sl4a for this, but it would be very nice to have
access to the original Java API for experimenting with new features for an
actual native Android application. I look forward to trying it out.

------
suprgeek
For those of you in the Bay Area, there is a Hackathon (SVJUG Meetup) at
Google on July 11th that is expressly dedicated to JShell -
[http://www.meetup.com/sv-jug/events/223263007/](http://www.meetup.com/sv-
jug/events/223263007/)

Drop by, check it out & please stop the Snarky "Should have had it 10 yrs ago"
comments.

------
cbsmith
As they mention, BeanShell was already serving this purpose, and really would
provide a great foundation for building what is needed. The fact that it
hasn't been updated much kind of speaks volumes of the importance of this
effort.

------
arikrak
BlueJ [1] is geared at beginners, but it includes a codepad for trying out
Java code and also provides a way to interact with objects.

[1] [http://www.bluej.org/](http://www.bluej.org/)

~~~
zak_mc_kracken
All IDE's do. Please stay away from BlueJ, its compiler is terrible.

------
github-cat
So each programming language are becoming more and more alike. Many of them
are not pure OOP or pure functional language anymore.

~~~
NhanH
OOP and functional has never really been a meaningful axis to categorize
programming languages. There are more difference between Smalltalk(OOP) and
Java(OOP) than say, Smalltalk and Lisp(supposedly more FP).

It's probably better to categorize things based on (pick one of) semantic,
runtime (JVM vs Beam vs blablabla), productivity, correctness, readability
etc.

------
Elrac
Much of the description of Jshell is in the future tense. Can someone give us
an idea of the state of progress?

~~~
anjanb
@Elrac : You can get the shell running if you have linux or mac. Yesterday, I
tried on windows but couldn't get it working yet. Instructions are here :
[http://www.jclarity.com/2015/04/15/java-9-repl-getting-
start...](http://www.jclarity.com/2015/04/15/java-9-repl-getting-started-
guide/)

~~~
Elrac
Cool, thanks!

------
spacemanmatt
Too late. Learned Clojure.

~~~
pjmlp
Great if are allowed to use it at work. Many of us are not.

~~~
escherize
Sorry to have to ask, but why choose to work at a place that doesn't use tools
that you like, or does not give you the autonomy to use your best skills?

~~~
rwallace
Because life is about tradeoffs. Optimising for criterion A mean sacrificing
the opportunity to optimise for criterion B. And there are far more important
criteria than programming languages for which to optimise choice of employer.

------
theknarf
I read JS-Hell. Not the best name for a shell.

------
anon3_
This is big news. Java should have had this one from the start.

My question is, what took so long? What prevented it?

~~~
LoSboccacc
Beanshell was there since 1999

~~~
sam_lowry_
Yes, finally someone remembered it!

Reinventing the wheel is so human...

~~~
LoSboccacc
I know right? But if you say groovy and the like are just respin of age old
stuff they treat you like an old fart

And to think that when I advocated for writing business logic in a scripted
language in 2003 everyone was looking at me like I was crazy (well italy is
always quite behind last trends, so while in the states they were starting
with scripting languages we were still writing ejb with xml - and we still do
in many places)

