Can second this. At work, we have a large legacy Java codebase, and our most useful ops tool is our entire codebase and Spring beans loaded into a Groovy shell. Extremely convenient. Groovy is largely compatible with Java, but it also has shorthand notations (splat operator, elvis operator, closures, optional typing) and collections that are much more expressive than Java.
What about, for instance, the difference in multi-methods presented here? I would assume you would get different results in the Groovy REPL than in a Java compiler.
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.
I get why that would be nice, but it feels kinda wrong for what Java is[0]. That's why if I need to quickly bang out or test something I use my Scala REPL.
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.
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
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.
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.
> 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!
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.
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
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.
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.
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.
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?
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.
Do your coworkers never have to go in and maintain your code? What about after you leave? Do you not have to pull request the code before it's merged in? At the end of the day it IS just a jar, but that ignores all the non-runtime aspects of coding.
> Do your coworkers never have to go in and maintain your code? What about after you leave?
I wrote an extension to our core app that is needed by 2 customers. Someone might need to touch it again one day, but it's more likely that a new spec will demand new engineering for a new solution in the future, at which point the most favorable technology will be used. That goes for me or the next person.
> Do you not have to pull request the code before it's merged in?
No. I'm a full-time employee and a core committer. We already have extensions in Java, Groovy, (very limited, nearly dead experiment) Jython, and now Clojure. Technically my extension is Java and it is a thin wrapper to a Clojure library.
> At the end of the day it IS just a jar, but that ignores all the non-runtime aspects of coding.
They are de minimis in this case. It survived review with nominal eyebrows raised. It's a Java shop but they're familiar with the family of other JVM languages.
Even if you don't write Clojure code in your project, the Clojure REPL can be used to experiment with Java code in the same way the Groovy or Scala REPLs can.
I'd say that Java's verbosity doesn't lend itself well to interactive use. There are quite a few REPLs that allow calling Java code from another language, e.g. the integrated Javascript interpreters (run `jjs` in a terminal), BeanShell, Jython, JRuby, etc.
The lack of interest. If you haven't used a language that has a REPL you don't know how powerful it is. Most of the Java devs I know haven't used REPL with any other language.
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)
Several months ago I wanted to have an REPL for C and couldn't find anything satisfactory and I had the similar thought: Why weren't there any decent REPL for C ?
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.