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.

Armagh

Your question sounds as if you think that things like Groovy, JRuby or Jython (not JPython) are better than Java for all purposes. That's simply not the case. – Transalpine

@Jesper, aside from where performance is a concern, when else is it not the case? – Armagh

Well, you're already saying yourself that static typing is an advantage. I haven't seen any really large software projects done with dynamic languages, but I suspect that dynamic languages scale less well (when you get a lot of source code, it will become very hard to understand and maintain because of the lack of type safety). – Transalpine

@Transalpine - proponents of dynamic languages would say that the reason you haven't seen any really large dynamic language projects is because the flexibility of dynamic languages means you don't need as much code to get the job done. In other words, large projects are (to some extent) caused by choosing to use a statically typed language. I'm not saying I 100% agree with this, but it's the standard response to the "dynamic languages are unsuitable for large projects" argument. – Foresight

Answer 1

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.

Kaon

+1 what kind of tools are there for Java that allow you to work with half a million lines of code (that are not there for Python)? – Armagh

why would anyone create 50 KLoC + projects any more? – Recapitulate

any refactoring IDE like Intellij IDEA that can refactor across an entire code base based on Type, which no Python tool can, because there is no type information at non-runtime. And 50lk LOC is not a lot of code in a carrier grade solutions, most people don't have to work at the problem domain where they have millions of users and millions of concurrent users, so most people don't see the need for the scale of code I am used to using as an example. – Kaon

@fuzzy lollipop, it's interesting, but I don't know what proportion of projects that would be. On the other hand, you're making a point that's actually deeper: refactoring might NEVER be possible without type information. I wonder whether that's true. I asked that once -- stackoverflow.com/questions/2317579 -- but the question got taken over by SmallTalk answers and never really took off :) – Armagh

the majority of projects I work on are well into the 100'sk SLOC, so proportion isn't an issue for me, everything I work on is large scale and I have to be able to architect for maintenance of solutions of that size. – Kaon

I don't doubt there are still people writing monolithic apps, I just wonder why? – Recapitulate

nothing monolithic about anything, I am working on. I have over a dozen different services that run in stateless clusters, they just have lots of business logic in them. Lots of GUI logic in them, lots of GUI code period. Vertical integration projects are especially complex because of the logic mapping systems to one another. Just because there are lots of SLOC doesn't imply anything about the architecture. – Kaon

multitier apps can also be monolithic, for example 100s of entities (or services) in a single app. As a sidenote, grails makes creating modular web apps a breeze with their plugin architecture. In standard J2EE you need a lot of plumbing to pack few wars into one. – Recapitulate

but he said other than performance reasons and Groovy preforms TERRIBLY compared to straight up Java. – Kaon

@fuzzy lollipop, regarding performance check out this article: ibm.com/developerworks/library/j-jtp12214 groovy is compiled into bytecode and on modern vms measuring performance is not that simple. – Recapitulate

you say that groovy is compiled to bytecode like that means something, it doesn't, groovy has many levels of indirection to enable the syntactic sugar that it uses and they all add up to many extra cycles to do all the indirection to do the same thing in straight Java. Groovy is slower than Java for most things, that's just a fact. That article you link to is about Java, a lot of those JIT optimizations can't be done with groovy because of all the intermediate classes and indirection and reflection that is done by groovy. groovy bytecode != java bytecode. – Kaon

groovy is slower than java, no doubt about that, but the difference is generally exaggerated. Check out another article: wiki.jvmlangsummit.com/images/8/8c/Theodorou_Groovy.pdf "Hotspot need much longer for groovy" – Recapitulate

Up to date comparison of performance of modern Groovy and Java implementations. note that when used in the correct way Groovy performance is not an issue, used in the wrong way it will cripple your application. – Kaon

Answer 2

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.

Viscardi

That's true, but isn't code with unit tests the inevitable future for everybody, even in Java? For usage example for the Java Collections code, the standard answer is, "see the unit tests." – Armagh

@yar: in an ideal world: true enough. In the real world: I'm afraid that we won't ever reach that utopia. Also: there's still the question if unit tests actually negate all the problems of dynamic binding, which isn't definitely answered yet, in my opinion. – Viscardi

Writing unit tests should be mandatory regardless of the programming language used, but why throw away the extra safety that the compiler provides? The idea "we don't need type safety, we just write unit tests!" sounds foolish to me... – Transalpine

@Jesper: I don't agree with the argument that unit tests can replace static type checks, but I heard it a lot. I just wanted to avoid the discussion and show why unit tests are not a sufficient solution even if we assume that the argument is correct. – Viscardi

@Joachim - I think you're overstating the significance of double dispatch. This is only an issue when you have overloaded methods in the same class that take the same number of args, and the args in equivalent positions have a parent-child relationship. It's a fairly rare occurence. Moreover, polymorphism has exactly the same "problem", i.e. you don't know until runtime which implementation of a method will be called – Foresight

@Don: true, it's not a common problem. Which makes the problem worse, because people don't tend to think of that difference. Also, with single dispatch the problem is quite different: When a method overrides another one, then it's well-known that it must be drop-in compatible. – Viscardi

@Joachim Sauer, while double dispatch problem is just another example of moving problems from compile-time to run-time (and therefore not going to change anybody's mind who thinks Groovy is groovy), it's also the price you pay for wanting to do "Dynamic Java." In Ruby, there's just no operator overloading, and I think it makes no sense in dynamic languages. Poor Groovy, like any language, suffers from non-language factors (wanting to interoperate with Java). Sorry that I have no point in this long comment :) – Armagh

@yar: personally I find Groovy to be a very groovy language, and I love writing code in it. I just think that Groovy is just one more tool in my toolbox and it won't displace Java completely, because for many things I prefer (or even need) the more explicit, more verbose approach of Java. – Viscardi

@JoachimSauer sorry that in 2010 I didn't have the depth to understand this answer, nor appreciate how well-written it is. It's 100% right: unit tests cannot solve the problem (because they can't if they could due to humans) and double-dispatch makes code less deterministic for little gain. "...harder to read, understand and reason about code" is stated perfectly. Thank you. – Armagh

Answer 3

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.

Doornail

Awesome, +1. Thanks for contemplating and thinking about this objective and empirical programming question. So if you had to take a completely wild, speculative guess, would you say that dynamic languages will replace static languages in the long haul? – Armagh

@yar I would expect my guesses to be even less value in an objective discussion than anecdotal evidence, but my not-entirely speculative guess is that no, dynamic languages won't replace static ones. My reason for thinking this is that languages don't get replaced. They become less used, less cool, even "legacy", but they don't get replaced. Consider: people are still writing Cobol. – Doornail

Very true, @CPerkins. Personally, I'm waiting for my train to come in, to find a language that can refactor/autocomplete as well as Java, but is dynamic and fun like Ruby. SmallTalk and Scala keep coming up in conversations recently. I might be forced to check out Obj-C soon, since it's the iPad language of choice, which is a relative. But yeah, a pluralistic universe, that sounds about right given what we've seen so far. – Armagh

@Daniel 'yar' Rosenstark Sorry I missed this comment somehow. I'm waiting for my airship too, at least for the next evolution. – Doornail

@Yar you should really give scala a shot. I feel that this is sort of language is where things may be headed. It is statically typed, yet the compiler is much more sophisticated than anything I've used before. It uses things like type inference and implicit type conversions to bring a set of features that allows you to write code that looks and feels a lot like dynamically typed code, with the benefit of being able to explicitly type things when you need or want to. It isn't perfect, and you do need to specify a type in certain situations but it seems like you may really like it – Mcwilliams

Thanks @grinch, just about now I'm only doing Objective-C, which is a language that I really do not like. That said, there's a certain peace in being trained at the highest levels of absurdity, like having to deal with autorelease pools etc. That said, I'll be checking out Scala for curiosity's sake soon. How hard would it be to set up for command line scripting, of impossible because it's compiled? – Armagh

@Yar You can use it for scripts because there is an interpreter for it. I haven't done much scripting with scala but there seem to be plenty on the forums that do. I do use the command line interpreter though - it's really nice to just test something out quick or to sit there and really play with things to try and get a feel for the compiler and how it handles certain situations. – Mcwilliams

Thank you @grinch, I'll check that out. #6231011 there are probably better links, too – Armagh

Answer 4

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).

Ablepsia

thanks for that, +1. Interesting, but it doesn't bode well for Java moving forward: is anyone choosing Java due to language features? – Armagh

Regarding Groovy vs. Java 1.4: I feel your pain, but it's kind of unfair to compare such an old version as Java 1.4 (which is already at its end-of-life for quite some time) to such a young language as Groovy. – Viscardi

+1 for pointing out inertia. That's a huge driver in decision, change is unsafe and using new technology makes managers nervous. While a few companies thrive on real innovation, most prefer copying a formula (language, platform) that worked elsewhere and feel much more comfortable with lagging behind. – Adda

@Yar - The only way I could see Java being chosen based on it's features is if a lack of features is considered a good thing. Some might call this lack of features "simplicity", but I call it "frustration". – Foresight

Answer 5

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.

Recapitulate

anecdotal evidence isn't that fascinating, but +1 anyway, since it does help, thanks. – Armagh

Answer 6

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.

Waers

So why are they still choosing Java? Is it an inertia thing (which to me implies that it will change someday), or based on language features? – Armagh

you'd have to ask each individual company and developer, this is really an unanswerable/subjective question. 1) familiarity 2) knowledge 3) comfort 4) etc – Waers

it's not subjective, though the data needed to answer would involve knowing what developers and companies think. But if you had to speculate, based on experience and your knowledge, would you say that "inertia" (familiarity, knowledge, comfort) explains choosing Java where performance is not a concern most of the time in 2010? – Armagh

Yes, but I don't think that is necessarily a bad thing either. Also, performance often is a concern. – Waers