Aside from performance concerns, why is Java still chosen over Groovy/JRuby etc.?

Question

[This is an empirical question about the state-of-the-art: I am NOT asking if Java is cooler or less cool than the dynamic languages that work in the JVM.]

Aside from cases where performance is a main decision factor, do companies/developers still willingly chose Java over Groovy, JRuby or Jython?

Edit: If the answer is "yes," why?

Personal Note: The reason I am asking is that, while I do some subset of my professional work in Ruby (not JRuby, for now), in my personal projects I use Java. While I have written non-trivial apps in Groovy, I prefer Java, but I wonder if I should just get over it and do everything in Groovy. I like Java because I feel that static typing saves me time and aids refactoring. (No, I am not familiar with Scala.) However, I feel that this very empirical, on-topic programming question may inform my decision.

Answer 1

Since you are asking an empirical question, and I assume looking for empirical answers:

Aside from cases where performance is a main decision factor, do companies/developers still willingly chose Java over Groovy, JRuby or JPython?

Yes.

I don't think there is anything else to say.

Answer 2

Aside from cases where performance is a main decision factor, do companies/developers still willingly chose Java over Groovy, JRuby or JPython?

Yes, and I believe the main reason is inertia, either on the part of the developer or the company:

• Company: existing investment in Java (in terms of staff skills and infrastructure), the risks of change are perceived to outweigh the benefits
• Developer: there are plenty of Java jobs available, so why bother learning another language?

Lack of available resources is probably another reason, though this is something of a chicken-and-egg problem (or a Mexican standoff, or a self-fulfilling prophecy, or something else). I imagine there are a lot of companies watching Groovy, Jython, etc. but waiting for them to become more widely adopted before taking the plunge. Obviously, by postponing adoption themselves, they're exacerbating this lack of resources problem.

Personal Aside

I spent the last year working as a Groovy/Grails developer. I recently changed jobs and am now working as a Java 1.4 developer and (compared to Groovy programming) it's about as pleasant as gouging your eyes out with a rusty spoon.

Static typing is great in that it facilitates compile-time checking and code analysis tools like FindBugs, but no way does it compensate for the massive amounts of (boilerplate) code it takes to accomplish the simplest of tasks when writing Java (particularly if you're using a version earlier than 1.5).

Answer 3

Static typing still is a big thing.

While it has been argued over and over again and proponents of the dynamic approach say that the problems that dynamic typing bring can be reduced (or even eliminated) with sufficient unit tests.

I don't want to argue whether or not this argument is correct, so I'll assume that it is, for this answer.

In that case there is still one problem, which is that many shops don't have the procedures/know-how/rules/management to produce a sufficient number of high-quality unit tests.

And if I have to choose between dynamically typed code without unit tests and statically typed code without unit tests, I'll choose the statically typed one every day.

A similar issue exists with double dispatch:

In Groovy method calls are dispatched based on the actual types of the arguments at runtime (which is almost required, because the static type is unknown and/or Object most of the time). This means that there is no reliable way to know which method is called at any given point at the code, when faced with extensible class hierarchies.

Any code that calls a method with the signature foo(String) most of the time may suddenly call foo(Integer) or foo(SomethingElseEntirely) depending only on the actual type of the argument at runtime. In the Java language that can never happen, because the exact signature of the method to be called is decided at compile time.

Much like other "dynamic" language features, double dispatch is occasionally a very useful tool and the lack of it can produce some ugly constructs in Java, but it has its cost in that it makes it even harder to read, understand and reason about code.

Answer 4

I can tell you what is going on in my company. Our current application is done in java, but we have started a transition to grails/groovy and this will most probably be the platform for the next generation of our products.

Answer 5

Yes, obviously.

Why are companies still "willingly" using Java?

Because companies are inherently conservative. They don't change technologies because they're cool, or even groovy. They change, reluctantly, when there's a prudent reason to do so. Early adopters pay very heavy penalties for being early adopters.

Edit: this is not "inertia" in the pejorative sense, as in "no reason to avoid change except resistance to change", but in the sense of prudence. It is right for companies to not abandon what's working, until there's something that's provably better.

And not in the "makes developers happy because it's cool" sense of better, but in terms of more quickly and reliably meeting whatever business requirements drive development in the organization.

Java offers:

1. Large base of trained, experienced developers. It's hard enough finding people who are able to do software development well, without picking a language which hasn't been around as long. And training people in a new language is expensive, in both time and money.

2. Brand-name recognition and an easily proven track record of successfully completed projects. This is nothing to scoff at: if I tell upper management I'm beginning a project in some groovy new language they've never heard of, I have to educate them on it, and they'll rate that as a risk. With any "established" language, I can skip that step.

3. Well-established, mature support tools, and third-party support.

These advantages accrue to any comparison between a long-established language and a new one, not just Java and your list. I expect that one day, Groovy, et al, will be the established language, and there'll be people asking the same question about some newer, shinier language. This is the cycle. It's how it's been for longer than I've been in the business.

Answer 6

non-statically typed languages don't "scale" well in the maintenance sense. Up to a few tens of thousands of lines of code they are maintainable. Past that they just take more effort to maintain, re-factor or update. This is true of any of the non-static typed languages, Perl, Python, Groovy, Ruby etc. The tools for working with half a million lines of Python code vs the same number of lines of code in C/C++/Java just aren't there. Now it is true that Python is about 1/3 to 1/5 the number of lines of code as an equivalent Java program. So this is never going to be apples and oranges, but there is a cut off point where the number of lines of code in a non-static language will have diminishing returns on maintenance. And everyone knows that maintenance is where the true cost of a software project has always been.