4 ms·
So in terms of client-side startup it can become a pain, because if you're starting and stopping a jvm all the time you tend to feel it. You encounter these pr
by SCdF 13y ago
So in terms of client-side startup it can become a pain, because if you're starting and stopping a jvm all the time you tend to feel it.
You encounter these problems if:
- People write unix-style tools on the JVM (imagine if ls was a Java program). Thankfully almost no one does this, but...
- When you use tooling for things that involve JVM languages, such as Clojure's lein or Scala's sbt. Starting lein / sbt is annoyingly slow. Using Scalaiform to format scala code takes a noticeable chunk of time because it's booting up a jvm each time. So noticeable that as much as I'd like to have it happen every time I save a file it makes SublimeText way too choppy.
This is less noticable on faster computers (my current work box is a i7 laptop with 12GB and an SSD) but on older computers it's still a real pain. Working with Clojure on a 2009MBP can be an exercise in frustration.
- pjmlp 13y agoYou are assuming there is only ONE JVM, which could not be further from the truth. There are JVMs on the market that compile to native code, and others that cache the JITed code from previous executions. Aonix and Websphere Real Time JVMs are two possible examples. I really think developers should broaden their horizons. Oracle's JVM is only the reference implementation.