Hacker News new | ask | show | jobs
by casenelson 5336 days ago
It's rare that I've seen the Java VM described as horrible.

In fact, it seems to be quite highly respected and seems to be working out well for Scala and Clojure. Obviously, there's also Twitter who partially moved to the VM from Rails.

Would you care to elaborate? Has Linus talked about the VM before?

3 comments

The Java VM is quite bad. There just isn't an alternative that meets these criteria:

1. cross platform (windows, mac, linux, mobile devices, embedded)

2. kinda fast

3. reasonably mature

4. bunch of libraries

If you want to create a new programming language today Java is the only viable platform. .NET and Mono isn't quite mature enough (and it's very similar to Java anyway). If you bootstrap from C it'll be fast and portable but you'll have no libraries for the first 5 years or so.

There just isn't a low level language layer, just above C that can be used for interopability between programming languages. What we need, what we really need, is some sort of Java--. A simple bytecode layer that other languages can target. So libraries written in one language can be used (and inspected) from another language. I know it's not going to happen anytime soon, but it'd be nice.

Correct me if I'm wrong, but aren't you confusing Java the language with the actual JVM? On your last paragraph, you pretty much described what the JVM is in my perspective.
There is no proper separation of concerns in the JVM. The JVM instruction set has instructions like `invokevirtual` and `invokestatic`, `invokeinterface`, which are Java specific features. The JVM also knows the concept of classes and methods and fields, even though those abstractions should be defined at the language level, not at the VM level (a Lisp or Forth-like stack machine needs different abstractions).

The datatypes in the JVM are pretty weird. You have chars, but not unsigned chars, some integer types (but not all). You have no support for unicode. There is a low-level struct for arrays and multidimensional arrays (of a specific type), but for nothing else. It supports exceptions, but only Java like exceptions. (You can't make an exception system where execution can be retried or resumed; it's just not supported). It also has a java-specific thread model (want to create lightweight threads with lockfree data structures? nope, not gonna work).

What you want is a low-level platform with different modules that can be picked by the people who implement the programming language. Pick a parser module, a garbage collection module, a JIT compilation module, and so forth. This is really difficult, because you have to have a good understanding what kind of primitives different programming languages need. When all these things are fixed and non-interchangeable you end up with a virtual machine that is suitable only for a specific kind of language. It's turing complete, so of course you can make any language on the JVM, but it's just not a good fit.

I see. This makes more sense now that you've explained it. I'm now even more compelled to dive more into JVM details.
It sounds like you're saying The JVM is the worst possible VM, except for the alternatives

My understanding is that it is state-of-the-art, and includes many innovations (unlike Java itself). Of course, state of the art does not mean perfect. There's still room to improve, which the JVM, CLR or some other VM might manage. But it seems over-the-top to bash the best in the world. It's like saying that, as a sprinter, Usain Bolt is quite bad.

The real tiger is never a match for a paper one, unless actual use is wanted. - Brooks

"A simple bytecode layer that other languages can target"

What about the Parrot VM: http://parrot.org/

Parrot is basically just a VM for Perl. The opcodes are tied heavily to Perl 6 semantics (type coercion for everyone, the string "0" is false, etc etc).
Intellij, Eclipse and Netbeans, great software written in Java. Haddop, as well. Not to mention Minecraft, but this point I'll leave to Techcrunch[1]

Java is not a great language by all means, the VM does have it issues (it is very old, and has to deal with its legacy), but it is not on a really important piece of software, its quality is quite good.

At the very least, it is, ironically, responsible for LISP's renewed interest through Clojure.

[1] http://techcrunch.com/2011/01/15/a-brief-explanation-of-why-...

It's highly respected by people who are willing to use JVM based software. Frankly, typical JVM startup times alone is enough of a pain that I avoid anything-JVM if I can.
> " Frankly, typical JVM startup times alone is enough of a pain"

The default JVM options are biased toward long running processes. That's kinda what most software running on a JVM is going to be though - start it running, leave it for weeks.

If you want a JVM that is tailored for short lived processes, then quick startup time is just a few options away after you RTFM. Or use a language/runtime more tailored to short lived scripting.

FWIW I've never seen a JVM take more than a second to startup though, which is more than adequate for server software.