5 ms·

I've been wondering for awhile if the JVM really has a lot of runway left; Java 7 has been amazingly slow in coming, and it'll be at least six months, and more

by donw 16y ago

I've been wondering for awhile if the JVM really has a lot of runway left; Java 7 has been amazingly slow in coming, and it'll be at least six months, and more likely a year, before even the early adopters can really use it in production. Startup time is a very real problem, as is memory use compared to other, similar VMs (V8, LLVM). With closures (lambda expressions), Java will be a lot more useful, but my money is honestly on V8 and JavaScript at this point. It's moving faster, and the node.js guys are very right that JavaScript is the language of the web.

sb 16y ago
Hi, just for the record, V8 differs in one very important aspect from the JVM: it includes no interpreter. It directly compiles methods to native code before their first execution, whereas the JVM includes a highly optimized interpreter for the first couple of executions. This affects memory usage, too (a couple of things that come to mind are profiling, additional memory for de-optimization, etc.)
- bad_user 16y ago
  I have a hard time believing that V8 doesn't do profiling / de-optimizations ... as these are crucial parts for optimizing runtime dispatch or boxing/unboxing of primitives. I know that V8 doesn't do tracing compiling, but still, it should at least have inline caches.
noelwelsh 16y ago
The JVM does a huge amount more than V8/node.js. If your world consists solely of shuffling bytes around a network then node.js may be a good solution, but it doesn't extend much further than that. For example, I wouldn't want to write a machine learning algorithm in Javascript, nor would I want to write a storage engine, nor a ... you get the idea. Furthermore, while node.js may be growing quickly (easy when you're small!) the development of the Javascript language is taking a rather torturous route as the various vendors play games at the Ecmascript table. To return to the article, what I really want from both the JVM and Javascript is tail recursion. I'd also like proper lexical scoping in Javascript, though that isn't so important. I don't view Java or Javascript as languages you write but rather languages you compile to (well, you compile to bytecode for the JVM, but hopefully you get my point). Scala and Clojure make mighty fine Java replacements; I haven't seen anything yet for Javascript that is much of an improvement.
- sanderjd 16y ago
  Could you list some reasons why you wouldn't want to write a machine learning algorithm in Javascript, or a write storage engine nor a ...? Lack of libraries? Too high level? Or do you not like the syntax/semantics/...?
  - jshen 16y ago
    threading maybe?
  - noelwelsh 16y ago
    Performance -- Javascript VMs are not optimised for numeric code. Lack of libraries. I don't particularly like JS for involved projects (e.g. no module system, so you have to write your own).
axod 16y ago
Why is startup time relevant if you're doing backend server stuff? It's pretty much the ideal use case for Java. Java 7? meh. If you like chasing new shiny things all day, sure. Javascript is a great language, no doubt, but for me, it lacks a lot of the things Java does so well to ensure that things don't break, finding bugs easy, etc etc Why are so programmers so fashion conscious though? Do we write programs to solve problems, or do we write programs to be fashionable. If we write to solve problems, then use Java5. Use BASIC. Who cares if it solves the problem well. If you write to be fashionable, then sure, use <NEW SHINY THING THAT REINVENTS THE WHEEL BUT ISN'T UP TO MUCH YET>. People will marvel over your great fashion sense, but will it solve the problem even as well as a less fashionable approach? The amount of man hours wasted on reinventing the wheel in programming languages is staggering. So much time spent making a saw with a more comfortable handle that doesn't cut as well.
- bad_user 16y ago
  > Why is startup time relevant if you're doing backend server stuff? It's pretty much the ideal use case for Java. Even on "backend server stuff" I pretty much prefer the FastCGI model, with multiple processes handling requests, as I don't have to worry about memory-leaks or about a rogue thread that can take out my whole server. With the JVM, this is impossible ... you need a monolithic process that takes care of everything (no support for forking, long startup time, high resource usage). And having multiple apps running in their own JVM (so they don't interfere with one another) is no panacea. You can also look at the problems Google's App Engine has with Java apps ... as resources are elastic, extra servers / VMs are loaded on demand, and the first requests hitting such a cold VM almost always ends up with a timeout error (although they are working to fix this, the magnitude of this issue is not the same with Python on GAE). And this is solely because of the slow warm-up time. > People will marvel over your great fashion sense, but will it solve the problem even as well as a less fashionable approach? I have ideas that I can prototype over a single weekend, which wouldn't be possible without the help of those people with "great fashion sense". > The amount of man hours wasted on reinventing the wheel in programming languages is staggering Why don't you teach people then how to spend their time better with constructive arguments? The easiest thing in the world is to dismiss / critique.
swannodette 16y ago
Counterpoints: 1) Javascript is the slowest moving language standard since Common Lisp 2) Node.js is a cool project that is heading very gradually towards adoptability for projects that aren't tech demos 3) JVM is mature enough to support other languages - can't say that about V8 and probably not for some time. JVM languages moving fast and in good/interesting directions. 4) Android 5) JVM startup time not an issue for web services, games, etc - only one-off shell scripts. 6) Memory use. Unless you're running on a mobile platform - who cares? Projects like Node.js will have a bright future with small agile teams. But no more so than Clojure or Scala. And unlike Node.js, I think Clojure and Scala certainly have the ability to scale up to heavy-lifting tasks that require concurrency, real perf, and mature libraries. I love JS in the browser. But on the server, I have yet to see anything that convinces me that JavaScript will ever really trump what the JVM offers.
- 10ren 16y ago
  Aside on 5): if you make your shell scripts call an already-running JVM, it is amazingly fast (ie. it's a server). A very very simple hack for is to run the JVM in an xterm, inside rlwrap, and implement a rudimentary command-loop - then type your commands directly.

by donw 16y ago

sb 16y ago

Hi, just for the record, V8 differs in one very important aspect from the JVM: it includes no interpreter. It directly compiles methods to native code before their first execution, whereas the JVM includes a highly optimized interpreter for the first couple of executions. This affects memory usage, too (a couple of things that come to mind are profiling, additional memory for de-optimization, etc.)

bad_user 16y ago
I have a hard time believing that V8 doesn't do profiling / de-optimizations ... as these are crucial parts for optimizing runtime dispatch or boxing/unboxing of primitives. I know that V8 doesn't do tracing compiling, but still, it should at least have inline caches.

noelwelsh 16y ago

The JVM does a huge amount more than V8/node.js. If your world consists solely of shuffling bytes around a network then node.js may be a good solution, but it doesn't extend much further than that. For example, I wouldn't want to write a machine learning algorithm in Javascript, nor would I want to write a storage engine, nor a ... you get the idea. Furthermore, while node.js may be growing quickly (easy when you're small!) the development of the Javascript language is taking a rather torturous route as the various vendors play games at the Ecmascript table. To return to the article, what I really want from both the JVM and Javascript is tail recursion. I'd also like proper lexical scoping in Javascript, though that isn't so important. I don't view Java or Javascript as languages you write but rather languages you compile to (well, you compile to bytecode for the JVM, but hopefully you get my point). Scala and Clojure make mighty fine Java replacements; I haven't seen anything yet for Javascript that is much of an improvement.

sanderjd 16y ago
Could you list some reasons why you wouldn't want to write a machine learning algorithm in Javascript, or a write storage engine nor a ...? Lack of libraries? Too high level? Or do you not like the syntax/semantics/...?
- jshen 16y ago
  threading maybe?
- noelwelsh 16y ago
  Performance -- Javascript VMs are not optimised for numeric code. Lack of libraries. I don't particularly like JS for involved projects (e.g. no module system, so you have to write your own).

axod 16y ago

Why is startup time relevant if you're doing backend server stuff? It's pretty much the ideal use case for Java. Java 7? meh. If you like chasing new shiny things all day, sure. Javascript is a great language, no doubt, but for me, it lacks a lot of the things Java does so well to ensure that things don't break, finding bugs easy, etc etc Why are so programmers so fashion conscious though? Do we write programs to solve problems, or do we write programs to be fashionable. If we write to solve problems, then use Java5. Use BASIC. Who cares if it solves the problem well. If you write to be fashionable, then sure, use <NEW SHINY THING THAT REINVENTS THE WHEEL BUT ISN'T UP TO MUCH YET>. People will marvel over your great fashion sense, but will it solve the problem even as well as a less fashionable approach? The amount of man hours wasted on reinventing the wheel in programming languages is staggering. So much time spent making a saw with a more comfortable handle that doesn't cut as well.

bad_user 16y ago
> Why is startup time relevant if you're doing backend server stuff? It's pretty much the ideal use case for Java. Even on "backend server stuff" I pretty much prefer the FastCGI model, with multiple processes handling requests, as I don't have to worry about memory-leaks or about a rogue thread that can take out my whole server. With the JVM, this is impossible ... you need a monolithic process that takes care of everything (no support for forking, long startup time, high resource usage). And having multiple apps running in their own JVM (so they don't interfere with one another) is no panacea. You can also look at the problems Google's App Engine has with Java apps ... as resources are elastic, extra servers / VMs are loaded on demand, and the first requests hitting such a cold VM almost always ends up with a timeout error (although they are working to fix this, the magnitude of this issue is not the same with Python on GAE). And this is solely because of the slow warm-up time. > People will marvel over your great fashion sense, but will it solve the problem even as well as a less fashionable approach? I have ideas that I can prototype over a single weekend, which wouldn't be possible without the help of those people with "great fashion sense". > The amount of man hours wasted on reinventing the wheel in programming languages is staggering Why don't you teach people then how to spend their time better with constructive arguments? The easiest thing in the world is to dismiss / critique.

swannodette 16y ago

Counterpoints: 1) Javascript is the slowest moving language standard since Common Lisp 2) Node.js is a cool project that is heading very gradually towards adoptability for projects that aren't tech demos 3) JVM is mature enough to support other languages - can't say that about V8 and probably not for some time. JVM languages moving fast and in good/interesting directions. 4) Android 5) JVM startup time not an issue for web services, games, etc - only one-off shell scripts. 6) Memory use. Unless you're running on a mobile platform - who cares? Projects like Node.js will have a bright future with small agile teams. But no more so than Clojure or Scala. And unlike Node.js, I think Clojure and Scala certainly have the ability to scale up to heavy-lifting tasks that require concurrency, real perf, and mature libraries. I love JS in the browser. But on the server, I have yet to see anything that convinces me that JavaScript will ever really trump what the JVM offers.

10ren 16y ago
Aside on 5): if you make your shell scripts call an already-running JVM, it is amazingly fast (ie. it's a server). A very very simple hack for is to run the JVM in an xterm, inside rlwrap, and implement a rudimentary command-loop - then type your commands directly.