Even better, continue working with JDK 6, and if you're a
dyed-in-the-wool JVM person, expand your programming horizons with Scala
or Clojure.
(defn drop-bombshell []
(.println System/out "I already know Clojure, actually."))
Yeah, I was a scout once, and still stick to that whole "be prepared"
thing.
Clojure comes in handy when you don't need seriously blazing speed and
the problem lends itself to a functional style.
Actually what Java really needs for speed these days is an API that lets
you do arbitrary SIMD math on the machine's GPU. That seems to be where
all the really sneaky optimizations are in rendering/number crunching
these days, ones that JIT won't get you, and pretty much everything else
you want to do is I/O bound.
Actually, the other thing we really need is OS/JVM integration so the JVM
heap plays nicer with paging and multitasking. I foresee a day when
there's a small kernel written in C that bootstraps and provides the main
API services for a JVM or similar VM, and all user-mode applications run
in the VM. If the VM is stable enough, they can't crash it, just catch
unhandled exceptions. The JVM's security features make it almost ideal
for something like this, combined with its maturity and JIT. It seems bad
for multiuser systems because one common heap would impede the ability to
set per-user quotas and the like, BUT this is easily solved by having
separate VM instances per user, with appropriate heap size limits and
appropriate limits on CPU hogging enforced by a minimalist scheduler in
the C kernel. But it'll probably be a while before we see this style of
OS; and a major competing possibility is for the OS to merge with the
browser instead and browser-based apps to take over. But then the browser
becomes a kind of VM, doesn't it...
