[bad_user]

     Java ... It’s one of the fastest languages 

Languages aren't inherently fast or slow, that's rather the quality of the underlying virtual machine / hardware architecture the compiled binaries run on. I think everybody can remember the days before Java 1.4 where the official JVM sucked performance wise. Did that mean Java the language is slow?

Of course, in designing a programming language, the architect can make some tradeoffs that will make the resulting implementations of certain algorithms run faster or consume less memory. So on one hand the architect can make tradeoffs regarding some features of the language that may help with performance, but on the other hand those tradeoffs can also stay in your way when trying to do higher-level optimizations.

     Community governance via that JCP (pre-Oracle).

It was Sun that refused to give a license for the TCK to Apache Harmony. The JCP was never nothing more than a bunch of people and companies bending over to Sun, now Oracle.

Of course, because of OpenJDK and because Sun always projected this "open" image of Java to the world, the genie is out of the bottle because OpenJDK can be forked, and because APIs aren't copyrightable (although that's still a gray area), so even third party implementations are possible (as seen in the Google vs Oracle trial). So Oracle has to be a good citizen here, or else they risk losing whatever control they have left.

But the JCP was never and probably will never be a standards body and Java will never be a published standard, in the same sense that C/C++ are.

     It’s popular to hate Java

You should definitely have feelings for programming languages, but only immature people think in terms of love/hate based on what other people think (basically you're kind of incompetent or still wet behind the ears if you hate Java based on what other people say about it).

Many of us in the trenches avoid using Java because it's lower-level than say, Ruby, or Clojure, or Scala. But Java is still there, still kicking ass, whenever the high-level abstractions are in our way, or whenever we are part of something bigger that imposes Java on us (like company politics). The same can be said about C/C++ - still kicking ass, but you don't really have to go that low level for 99% of the times, unless the project or organization dictates it. So why should you? Best tool for the job, right?

     ... are the industries that 
     are still stuck in the 50′s the problem? 

Because you know, we should rewrite everything from scratch every 5 years or so.

[astine]

"Languages aren't inherently fast or slow, that's rather the quality of the underlying virtual machine / hardware architecture the compiled binaries run on."

That's not really true. Some language semantics and features are difficult to implement in an efficient manner. Continuations are a good example. Dynamic typing, also can be inefficient because of the need for runtime inspection of object metadata. Clojure has this problem and that's why they added type-hints, purely as a speed hack to avoid this problem. True, most of Java's speed is probably due to the Hotspot VM, but in practice, it's still among the faster languages out there, certainly among the garbage collected languages.

[bad_user]

That statement I made is definitely true.

I'm not arguing for or against Java, I'm arguing that both the hypothesis and the conclusion and everything about that article is flawed (it basically screams LINK-BAIT).

     Continuations are a good example

First of all, most implementations for continuations that are in common use are on top of virtual machines that are stack-based, so providing first-class continuations is a bitch, because you've got no way out of it other than to save the classical call-stack somewhere and restore it later, should you need to. And because of the way the call-stack is implemented, saving / restoring it is both time and space consuming.

This was a pragmatic decision, more often than not, because explicit support is really not that useful, while being error-prone and because the major use-cases, like exceptions handling, coroutines, asynchronous tasks, etc... can receive language support that's also optimal on top of a stack-based VMs. And in most cases you don't need the unlimited extent that continuations on top of Scheme provide (most people just need the "async" support like it was done in C#, which is just compiler-related syntactic sugar). Some people even consider continuations "harmful" as sort of a modern Goto (a topic on which I have no opinion btw).

However, if you get rid of the traditional call-stack and make all methods receive an implicit continuation of the caller, and overload the "return" operator to call that implicit continuation (basically making everything CPS), then you could optimize this more efficiently. By how much, nobody knows yet, because there have been only weak attempts at solving this (I only know of Parrot, the new Perl 6 VM, but it hasn't done anything spectacular yet).

Also remember that our current commodity, general-purpose hardware is optimized primarily for C, which assumes a traditional call-stack. And you can always design hardware that's optimized for different things.

     Dynamic typing ... Clojure has this problem and that's
     why they added type-hints

You haven't actually mentioned the exact problem Clojure is having. Clojure added type-hints mostly to avoid primitive boxing/unboxing. It doesn't have much to do with "dynamic typing".

In case you weren't aware, the JVM bytecode is pretty dynamic. Besides primitive operations on primitives, which have special bytecode instructions, the only place where you really, really need the name of a class or interface is when calling a method. And so the name of the Class.method ends up hardcoded in the bytecode, but that's only because Java itself has clear rules for method-lookup, so providing the means to override that method-lookup was unnecessary.

However in Java 7 they added invoke_dynamic, which does provide the means of overriding the method-lookup being done. JVM engineers, like John Rose, promised the same performance characteristics as invoke_virtual.

But Clojure doesn't even need invokeDynamic most of the time, because in most cases method calls in Clojure are only polymorphic and not dynamic. And because most things in Clojure are immutable. JRuby would have been a better example.

EDIT: formatting (moved ending paragraph to the beginning)