[altcognito]

This article is a troll, but I'll bite: I'm not going to justify all of these, but this is my short list:

1) Java is slow (the JIT hides only some of this -- see below)

2) Java makes working in Hashes and arrays very painful

3) Very little functional support (yes, Java8 will help)

4) The java language moves forward very, very, very slowly

5) It scalability is a joke. I've worked as a Java contractor at a number of places and what a PERL/PHP/Python solution can get done in 5 boxes, it takes Java 30-40 boxes. This is NOT an exagerration. I think it's a side effect of some developers stuffing everything into the session and expecting clustering to fix everything.

6) Date and file handling is also really painful. (yes, JODA helps, but we're 15+ years into Java and only finally getting good date support baked into the language)

7) Library management. Maven has largely "fixed" this issue at last, but sorting through library conflicts in order to write in an exception is still not fun. And as already noted, this is one of the reasons you can't just jump in with a text editor and hammer out a simple example.

The library support of Java makes up for a lot, but honestly, Python looks better and better every day.

edit: I will add in support for why many, including myself perceive java to be slow. The startup of the JVM is horrendous. If you're doing even moderate web development, there is a minimum two to three second startup period for a web server. That simply doesn't exist in PERL/PHP/Python. There's no such thing as a permgen error in PERL/PHP/Python. I've never seen PERL/PHP/Python go off and spin the disk as furiously as Java trying to load classes. It's ridiculous.

Java's strength is its maintainability and library support.

[rufugee]

5) It scalability is a joke. I've worked as a Java contractor at a number of places and what a PERL/PHP/Python solution can get done in 5 boxes, it takes Java 30-40 boxes. This is NOT an exagerration. I think it's a side effect of some developers stuffing everything into the session and expecting clustering to fix everything.

Umm...I think you've been working in the wrong Java shops. I've never seen, nor do I believe it's possible, for a well-written python/perl/php app to be faster than a well-written Java app.

The startup of the JVM is horrendous. If you're doing even moderate web development, there is a minimum two to three second startup period for a web server. That simply doesn't exist in PERL/PHP/Python. There's no such thing as a permgen error in PERL/PHP/Python. I've never seen PERL/PHP/Python go off and spin the disk as furiously as Java trying to load classes. It's ridiculous.

Sure, Java's start-up is slow. But it shouldn't be an issue in web apps since your application will likely use threads if it's a Java app. I can see if your app was process-oriented, like many ruby/python web apps are, but with Java's native thread support it makes no sense to start up multiple processes unless you really have a need for the separation.

[altcognito]

> Umm...I think you've been working in the wrong Java shops. I've never seen, nor do I believe it's possible, for a well-written python/perl/php app to be faster than a well-written Java app.

I've been in the industry over 20 years. I've seen plenty. It is easy to assume that the java and a JIT should be able to take advantage of all the extra information to make fast code. But in practice, when you add in all the frameworks and abstraction overhead, Java on the web is slower. I routinely hit stack traces well over 50 levels of depth. Benchmarks really don't take this into account.

>Sure, Java's start-up is slow. But it shouldn't be an issue in web apps since your application will likely use threads if it's a Java app. I can see if your app was process-oriented, like many ruby/python web apps are, but with Java's native thread support it makes no sense to start up multiple processes unless you really have a need for the separation.

I mostly agree with what you say. It is mostly a development issue. While most software development in Java attempts to be centered around TDD and therefore eliminate the whole start-restart cycle, the ugly truth is that there are reasons that tools like JRebel exist.

[rufugee]

>I've been in the industry over 20 years. I've seen plenty. It is easy to assume that the java and a JIT should be able to take advantage of all the extra information to make fast code. But in practice, when you add in all the frameworks and abstraction overhead, Java on the web is slower. I routinely hit stack traces well over 50 levels of depth. Benchmarks really don't take this into account.

But your original post said Java was slow. It's not. Don't conflate the language with bad frameworks written with it.

[thebluesky]

Java is slow ... It scalability is a joke. I've worked as a Java contractor at a number of places and what a PERL/PHP/Python solution can get done in 5 boxes, it takes Java 30-40 boxes. This is NOT an exagerration.

Hard to believe this one is still getting wheeled out in 2012. Java is MASSIVELY faster than Perl/Ruby/Python: http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...

I've seen over and over how Java code is at the very least an order of magnitude faster than a solution in a scripting language.

BTW the correct spelling is "exaggeration"

[Roboprog]

Man I dislike the language shootout benchmarks. I'm not a chemist :-(

The DNA complement substitution is close to string processing, but still feels like mostly bit twiddling. Likewise, lot's of numeric fidgeting in those benchmarks.

I want something that does numeric and string conversions; string concatenation; file I/O; network I/O benchmarks. Also, something that could indicate how the strings were encoded, perhaps separate benchmarks for 7 bit ascii vs UTF-8, etc.

[thebluesky]

You'll get similar results for most benchmarks. Languages such as Ruby/Perl/Python are consistently slower than Java. There's no such thing as a perfect benchmark, but I've found the language shootout page to be a pretty accurate reflection of what I've observed in practice.

[Roboprog]

My data says "usually, but not always":

http://roboprogs.com/devel/2009.12.html

I suppose I need to update this on newer machines (e.g. - 6 core AMD box I have now, for starters, instead of an old Pentium-D), and it's certainly possible I FUBARed the Java implementation. If anybody thinks they can clean up the Java, so that the single-threaded performance is better, here it is:

https://github.com/roboprog/mp_bench

I got similar results, albeit with much older versions of Perl and Java, about 10 years ago on sample code I made to index a flat-file in Perl and Java. That code belonged to my then employer, so I don't have it.

[igouy]

>> FUBARed the Java implementation <<

    // deliberately *not* using StringBuffer / StringBuilder,
    // as a real app would have many transient string variables

[Roboprog]

Because I know that every corporate app dev is (NOT) going to write:

   StringBuilder buf = new StringBuilder( s1);

   buf.append( s2);

   String cat = buf.toString();

instead of:

   String cat = s1 + s1;

in their application code. (although I think that is pretty much what the compiler generates on your behalf, anyway)

The loop is in the benchmark so I don't have to write code dealing with many different string values of differing size manually.

[igouy]

Man I dislike people who complain instead of fixing what they don't like :-(

Create the task definitions you want; write the best code you can for those tasks with an interpreted language, a JIT'd language and an aot compiled language; set-up the measurements framework and SCM for open contribution of programs; and then put up a website showing all that stuff and maintain it for the next 5 years.

[wreckimnaked]

    5) It scalability is a joke. I've worked as a Java contractor at a number of places and what a PERL/PHP/Python solution can get done in 5 boxes, it takes Java 30-40 boxes. This is NOT an exagerration.

I wonder why Twitter is moving their Ruby codebase to Java and Facebook is building a JVM backend of their PHP compiler .

[randomdata]

> I wonder why ... Facebook is building a JVM backend of their PHP compiler .

For fun, it seems. Facebook also built a PyPy backend[1], and even their own VM[2].

[1] http://morepypy.blogspot.ca/2012/07/hello-everyone.html

[2] https://github.com/facebook/hiphop-php/tree/master/src/runti...

[st3fan]

"It scalability is a joke. I've worked as a Java contractor at a number of places and what a PERL/PHP/Python solution can get done in 5 boxes, it takes Java 30-40 boxes. This is NOT an exagerration."

Yeah, Poorly written code in language X can do that.

If developers with poor judgement or knowledge build badly performing Java apps, is that a language problem? I don't think so.

Sounds like they though they got some magical clustering with whatever they used. Instead they should have coded their Java implementation with the same principles that makes PHP rock: don't share state, memcache, scale horizontally. You can then probably replace those those 5 PHP boxes with a single Java server :-)

[cnlwsu]

5) It scalability is a joke. I've worked as a Java contractor at a number of places and what a PERL/PHP/Python solution can get done in 5 boxes, it takes Java 30-40 boxes. This is NOT an exagerration. I think it's a side effect of some developers stuffing everything into the session and expecting clustering to fix everything.

Our app handles a million concurrent connections per box so I don't know where that is coming from.

[Mitt]

Twitter should have consulted you before translating their system to mostly Java. Could have saved them lots of money.