This sort of reaction is surprising to me. Java has been a useable, performant language for some time now. The tooling is excellent, the JVM is astonishingly good, and it will run circles around Python, no less Perl. I don't think many of the arguments against Java are based on how it works once you've written it, but rather to the horrendous verbosity, class-explosion-as-a-design-pattern, painfulness to read (not debug with an IDE, which is easy, but to actually read Java code), and so on. I'm not a Java developer by trade, but I'm surprised that other people are surprised by Java being high-performing, and the JVM being a good platform. I mean, Clojure Scala and Groovy all run on the JVM, and we talk about them all the time!
Of course you have to understand in my context I've really come in close intimate contact with Java twice. The first time about 14-15 years ago when the JVM was pretty doggish. I think it was Java 1.4 or 1.5. I don't think Eclipse was even out then, and the first version I remember seeing was so dog slow at the time compared to Visual C++ that I remember just writing off Java entirely.
To my surprise it stuck around in Enterprise spaces and I ended up running a team that ported a pretty large-ish Perl project (about 20k lines of Perl) into a piece of Java middleware. I didn't do any of the coding, but I knew the Perl bits inside and out so I knew what kind of testing and performance to expect and getting the Java port up to 1/3rd to 1/2 the performance of the original Perl was a pretty big challenge at the time. This was about...8 year ago. But to the credit of the team and I guess the tooling, they were able to get the port done remarkably quick.
So I've been pretty surprised to see that Java code can get fast, really fast. I've also managed to bang out some pretty slow code if I wasn't paying attention. For my latest touch into it, I ended up spending a week just benchmarking various collections to see how they actually worked under the kind of real-world uses I'd be putting them through (vs. what their big-O sheets claimed) and came away with a set of practices for me to get going with.
I've also had to come to terms with benching code a bunch of times to give the JIT compiler or whatever runs under the hood in the JVM some time to optimize, the first few runs are invariably much slower than run 1000.
> painfulness to read (not debug with an IDE, which is easy, but to actually read Java code)
This is incredibly important and I never see any Java advocate addressing it. I _do_ see tons of people pointing out how easy it is to automate refactoring, and then they leave dozens of ugly, poorly-thought-out methods lying around...
The problem is that there are two major kinds of "reading code".
There's (A) the brief pass you do to get the gist of what a class/method does, and (B) the deeper pass when you try to build a mental model and step through bits of code in your head.
While Java's verbosity does harm skimming, it also aids targeted comprehension, since it is easier to see the "one right behavior" that code has. Fewer sneaky surprises, leaky abstractions, weird type coercions, inferring which class-interface the designer intended to target, etc.
As mentioned already, the other big advantage to explicit-ness is all the static analysis the IDE can do for you.
Verbosity adds noise (redundant information), or information that is usually redundant, so you get used to it, so when you see the ~same pattern again, you skim over the things that you think are the same. But then sometimes it isn't quite the same, because of a bug or because the for loop does a decrement rather than an increment, which is lost on you.
Finding the balance between terseness and having a little bit of redundant information is of course very hard.
> I mean, Clojure Scala and Groovy all run on the JVM, and we talk about them all the time!
5 years ago those 3 languages were the talk of the town for alternate JVM languages, but things change. Scala's pulled way ahead of the pack, Clojure's consistent, and Groovy's on a downward trajectory, following in Beanshell's and JPython's footsteps. Eclipse users are drifting into Xtend, and IntelliJ users may look at Kotlin more. JDK 8's Nashorn is likely to scoop up those who just want to write quick-n-dirty's manipping Java classes.
Within the Spring Framework 4.0 Reference , the Spring Expression Language takes up all of chapter 7, whereas Groovy takes up little section 28.3.3 only, with only one use case presented. Your statement didn't have any specifics, only sales adjectives like "great test frameworks."