5 ms·

The JVM itself got faster -- and in many places, relies on native code for particularly expensive functionality -- but it's still unusable for end-user applicat

The JVM itself got faster -- and in many places, relies on native code for particularly expensive functionality -- but it's still unusable for end-user applications because: 1) The long load time / hotspot JIT overhead when starting applications. 2) The large memory overhead of the Sun/Oracle GC's reserved heap. To some degree, Dalvik solved some of these issues, but has also retained the (very necessary) escape-hatch-to-native JNI. JavaScript is SO MUCH HARDER to optimize than JVM bytecode. Whereas you can even feasible AOT-compile JVM code, JavaScript's dynamism makes this all but impossible. On top of that, JS is welded to the DOM and CSS, the combination of which incurs huge rendering pipeline CPU and memory overhead for anyone doing anything as complicated as a "native" UI view hierarchy. Rather than enumerate all the failures, I'll note that it's not all doom and gloom. We've got a web bytecode in the works that's much saner than JS. Canvas and WebGL exist. Progress on those fronts may create a situation like you're describing, but -- and this is no great loss in my book -- it won't be the web.

jebblue 11y ago
Minecraft alone shows your first two points are not valid. Write a hello world app in Java, the startup time is miliseconds, the memory is not humongous.
- kuschku 11y ago
  Yes, recently, Java actually became usable for a lot of seemingly native apps. And it does this a lot better than the browser.
- teacup50 11y ago
  (non-casual) Games aren't generally known for fast load time, sharing resources on a multitasking system, or short playing sessions -- all of which plays to the JVM's strengths (or avoids its weaknesses). As far as fast load time; just launching my (JVM-based) build tool (sbt) takes 7 seconds on my laptop. Running 'Hello World' from an uncompressed class file takes 0.12s, and most software is quite a bit larger than a couple lines of bytecode in an single uncompressed class file. The C version, by comparison, completes in 0.005s.
simoncion 11y ago
> [The JVM is] still unusable for end-user applications because [it makes application startup slow and uses too much RAM.] I can't agree. The poster child for "bloated, overweight, slow-as-shit Java application" is Eclipse. Circa 2013, I found it to be not substantially slower or any less usable than Visual Studio on the exact same hardware.
- yellowapple 11y ago
  That's implying that Visual Studio isn't also bloated, overweight, and slow-as-shit - three traits which VS serves as the textbook definition of. It makes Emacs look like ed in comparison, yet without offering any actual improvement in functionality. In other words, "but it's on par with Visual Studio" does absolutely nothing to counter the argument that the JVM is unusable for end-user applications; if anything, it proves it.
  - simoncion 11y ago
    After several years of working with both VS and Eclipse, I can say that IDEs are slow because they're doing a lot of work. (Eclipse suffers a bit because the Eclipse Steering Committee[0] won't let go of the dream that is the Eclipse Platform, but that dream primarily damages the ease of writing software for Eclipse, rather than Eclipse's execution speed.[1]) Consider two applications that each solve tasks of comparable complexity: One of these applications is written in C++. The other is written in Java. Both are written by programmers skilled in their respective languages. If both of these programs have roughly equivalent performance, what does that say about each underlying language? [0] Or whatever their official name is. [1] Source: In a former life, I was tasked to write and maintain bespoke software written on top of the Eclipse Platform. I cannot recommend the Platform for any new development that isn't writing software for Eclipse, itself.
  - oldmanjay 11y ago
    >It makes Emacs look like ed in comparison, yet without offering any actual improvement in functionality. Well, it does offer the functionality of being usable integrated environment, which I know a lot of the emacs/vi people dismiss, but it's a very real thing despite those dismissals. On the other hand, I don't really care much, since I've never had the emacs/vi user disease of insisting that everyone else acknowledge that my opinions are superior.

jebblue 11y ago

Minecraft alone shows your first two points are not valid. Write a hello world app in Java, the startup time is miliseconds, the memory is not humongous.

kuschku 11y ago
Yes, recently, Java actually became usable for a lot of seemingly native apps. And it does this a lot better than the browser.
teacup50 11y ago
(non-casual) Games aren't generally known for fast load time, sharing resources on a multitasking system, or short playing sessions -- all of which plays to the JVM's strengths (or avoids its weaknesses). As far as fast load time; just launching my (JVM-based) build tool (sbt) takes 7 seconds on my laptop. Running 'Hello World' from an uncompressed class file takes 0.12s, and most software is quite a bit larger than a couple lines of bytecode in an single uncompressed class file. The C version, by comparison, completes in 0.005s.

simoncion 11y ago

> [The JVM is] still unusable for end-user applications because [it makes application startup slow and uses too much RAM.] I can't agree. The poster child for "bloated, overweight, slow-as-shit Java application" is Eclipse. Circa 2013, I found it to be not substantially slower or any less usable than Visual Studio on the exact same hardware.

yellowapple 11y ago
That's implying that Visual Studio isn't also bloated, overweight, and slow-as-shit - three traits which VS serves as the textbook definition of. It makes Emacs look like ed in comparison, yet without offering any actual improvement in functionality. In other words, "but it's on par with Visual Studio" does absolutely nothing to counter the argument that the JVM is unusable for end-user applications; if anything, it proves it.
- simoncion 11y ago
  After several years of working with both VS and Eclipse, I can say that IDEs are slow because they're doing a lot of work. (Eclipse suffers a bit because the Eclipse Steering Committee[0] won't let go of the dream that is the Eclipse Platform, but that dream primarily damages the ease of writing software for Eclipse, rather than Eclipse's execution speed.[1]) Consider two applications that each solve tasks of comparable complexity: One of these applications is written in C++. The other is written in Java. Both are written by programmers skilled in their respective languages. If both of these programs have roughly equivalent performance, what does that say about each underlying language? [0] Or whatever their official name is. [1] Source: In a former life, I was tasked to write and maintain bespoke software written on top of the Eclipse Platform. I cannot recommend the Platform for any new development that isn't writing software for Eclipse, itself.
- oldmanjay 11y ago
  >It makes Emacs look like ed in comparison, yet without offering any actual improvement in functionality. Well, it does offer the functionality of being usable integrated environment, which I know a lot of the emacs/vi people dismiss, but it's a very real thing despite those dismissals. On the other hand, I don't really care much, since I've never had the emacs/vi user disease of insisting that everyone else acknowledge that my opinions are superior.