Skip to main content

Poll Result: Most Java/JVM Developers See Good Reasons for Sometimes Using non-Java JVM Languages

Posted by editor on May 20, 2014 at 6:49 PM PDT

In the most recently completed Java.net poll, more than 75% of the developers who chose to vote found there to be good reasons for using a non-Java JVM language. A (perhaps surprising?) 19%, however, considered there to be absolutely no good reason to use anything but Java on the JVM. A total of 181 votes were cast in the poll, and one comment was posted. The exact poll prompt and results were:

The best reason to use a non-Java JVM language is:

  • 23% (42 votes) - More modern language syntax
  • 6% (11 votes) - Better performance
  • 38% (69 votes) - Some non-Java JVM languages are better suited for certain types of programming
  • 8% (15 votes) - If you don't know Java that well, but you know another language that's been ported to the JVM
  • 19% (34 votes) - There's no good reason
  • 6% (10 votes) - Other

It took me a lot of crafting to come up with this poll, and I find the results (though this isn't, of course, a scientific poll) quite interesting. I wonder what people were thinking, in some cases.

First of all, that "Some non-Java JVM languages are better for certain types of programming" won a plurality of the voting seems very reasonable to me. The variety of non-Java JVM languages is already extensive, and it's ever-growing today.

I think the "More modern language syntax" surely was also a very reasonable selection. Some of the language changes in both Java 7 and Java 8 were essentially an attempt to catch up with features offered in other languages (including some popular modern non-JVM languages). Newer JVM languages, where there is no need for backward compatibility, no immense base of legacy code, can be designed from scratch with a fully modern syntax. That syntax, too, can be designed to facilitate the accomplishment of specific types of programming tasks, bringing us back to "Some non-Java JVM languages are better for certain types of programming."

I put the "Better performance" option into the poll largely out of curiosity. Java is not exactly known as a plodding beast when it comes to performance right out of the box, and if you really know what you're doing, you can tune Java to have incredible processing speed, or incredibly low latency, or incredible capability for processing massive volumes of data... I suppose there may be some non-Java JVM languages that, in their native state, already tune the JVM for various high-performance characteristics. I'm hoping, anyway, that that's the kind of thing the 6% who chose "Better performance" were thinking about...

I'm glad to see that only 8% said the best reason to use a non-Java JVM language is "If you don't know Java that well, but you know another language that's been ported to the JVM." I can see using a non-Java JVM language for that reason in a pinch, where you are pretty certain you won't be using the JVM much in the future. But, to become a Jython or JRuby developer simply because you don't want to learn Java probably isn't the best strategy if you're planning a long-term career as a software developer, perhaps some day proceeding into becoming a software architect.

This brings us to the 19% who selected "There's no good reason." I put this option into the poll in part to let some voters have fun and/or show their lifetime allegiance to Java. The question is, did most people select this option for fun? did some select it because they tried out a non-Java JVM language and didn't like it? did some select it because they are barely aware that non-Java JVM languages exist? I wonder... I'm hoping it was mostly proud Java veterans who selected this option.

6% of the votes went to "Other" and pjmlp commented:

Voted other, as I think it is a set of options and not a single one.

  • Modern syntax
  • Proper support for type inference
  • Value types
  • Reified generics
  • Better FFI support with foreign languages
  • Ability to AOT to native code, if desired, officially supported as part of the reference toolchain

A nice list of reasons, I'd say...

New poll: Update on Java/JVM work opportunities

Every now and then, I like to ask the community about the outlook for work (whether you work at a full-time position at a company, or you're a consultant, or a trainer, or an author, or perhaps you run some other type of Java-related business). Our current poll prompts you to respond to: Where I live, work opportunities for Java/JVM developers are.... Voting will be open until Friday, May 30.

What Java.net poll would you like to see?

If you have a poll idea, get in touch with me by commenting on this blog post, or by sending an email to editor _at_ java.net, or by using our Submit Article/Blog form.


Subscriptions and Archives: You can subscribe to this blog using the java.net Editor's Blog Feed. You can also subscribe to the Java Today RSS feed and the java.net blogs feed. To follow Java.net net on Twitter, follow @javanetbuzz.

-- Kevin Farnham (@kevin_farnham)

Comments

Looking at the really great Java 8 language changes like ...

Looking at the really great Java 8 language changes like lambdas and streams I really am shocked that you wrote "I'm HOPING it was mostly proud Java veterans who selected this option.": Do you really hate Java 8 so much that you HOPE this? Don't you think that 19% actually voted for that because they REALLY mean it? Speaking for myself, I think Java 8 is so freaking great that in fact I do not see why I should even think about NOT using it. Think about the chaos that exists in teams where one decides to use non-Java while the others do not, or you must maintain legacy software written in non-Java. Look at the Tiobe index at Java and at Scala, Clojure etc. and you see why that 19% voted like this! If you think other languages are better, then try to talk Latin on the street: It might be superior than English, but that simply does not count at the end of the day!

Actually, I agree that Java 8 is spectacular. But, does this ...

Actually, I agree that Java 8 is spectacular. But, does this mean that there is no conceivable case where a non-Java JVM language would be a better fit for a particular application than Java?

For example, what if your application was such that you ...

For example, what if your application was such that you would save a lot of development time if you could use something that's in Python's NumPy or SciPy libraries? Wouldn't it make sense in that case to write at least that portion of your application in Jython, using JyNI to bring in NumPy and/or SciPy?

For a company, the development time is only one component. ...

For a company, the development time is only one component. Think of all the other components, like e. g. the costs for one developer being able to speak one of those rather seldomly used language in a such professional way that he can dcontinute your non-Java-JVM-language development in the same quality than the average Java pro -- and how much time you need to find such a person to replace someone leaving the team. Java is common sense (see the tiobe index), and I hardly don't know anyone unable to do Java, while I don't know anyone being able to speak Scala AND ALL OTHER languages you might have used because those look so suitable. Only TCO counts at the end of the day, which means, in the end the costs to maintain a Java-implemented system is so much smaller than one implemented in other languages, and the risk that a bug cannot be fixed in time is nearly at zero for Java, while it is rather high for those "new" languages. So in the end it really makes NOT MUCH _economic_ sense to use something else than Java if you compute ALL costs and risks of the complete lifecycle of the average professional application.

There is a reason why the Tiobe index is lead by C and Java for years, while e. g. Scala even at its 10th birthday still is just at rank 35 -- even behind COBOL.

BTW, you cannot compare a third-party library to a language. The comparison is either JPython-vs-Java8 _or_ SciPy-vs-Java-based-third-party-library. And, this discussion actually started about non-Java-JVM-Languages. SciPy is not written in JPython, it is written in Python, which is _not_ a JVM language.

Implicit in my example is that there is no Java library that ...

Implicit in my example is that there is no Java library that would provide the same development time savings compared with what's available in NumPy/SciPy... You either use a bridge to NumPy/SciPy, or rebuild the wheel in Java, then call that...