| Hotspot is the most commonly used JVM impl I was referring to. Last I looked into it (probably a year ago), some of the graphics libraries it includes weren't open source - but everything important (including the JIT) is. The patent issues are regarding Dalvik AFAIK, so I don't see how it's relevant to this discussion ... (although, from what I've heard, it seems like Oracle's being a jerk ...) If you think that a general purpose language has to be able perform as well as C without calling native code (JNI, FFI, etc), I guess I'd have to agree Java isn't 'general purpose' . But I'd contend neither are Python, Ruby, Erlang, Javascript, etc under that definition. Therefore, that's probably not the right definition, since it excludes most general purpose languages ;-) Being able to synchronize on any object is actually really efficiently implemented (8 bytes of Object overhead total, neat optimizations like biased locking, etc). And, if you don't want to share state between threads, Java can do pretty clean actors/message passing (http://doc.akka.io/docs/akka/2.0/java/untyped-actors.html) or transactional variables (AtomicRefs are built in). Java concurrency does give you the ability to shoot yourself in the foot if you use it wrong, but so will any sufficiently powerful tool. Re the JVMs support for FP: - JVM7 added an InvokeDynamic instruction which I believe addresses your polymorphism concerns. - It sucks that there isn't a bytecode instruction to allow TCO. But, in practice, many JVM languages will convert recursion to iteration at compile time with constructs like http://clojure.org/special_forms#Special%20Forms--(recur%20e... - What do you mean by 'fast object allocation'? I'm not familiar with the term ... Creating objects is fairly fast in Java though. A quick test suggests I can alloc around 200 million objects per second on the heap once the code path is JIT'd on my laptop. Incidentally, it's surprisingly tricky to fool the JVMs escape analysis and force a heap (not stack) allocation, without introducing too much extra work in a microbenchmark ;-). - AFAIK, you're right that closures require an object allocation - but how else would you do it? When I was writing Common Lisp, we had to avoid creating closures in tight loops for the same reason |
http://www.reddit.com/r/scala/comments/m1dks/poor_performanc...