Re: Java 8 Lambda binary snapshot
On 14.11.2011 15:45, Lew wrote:
Arved Sandstrom wrote:
What actually holds us back with adoption of recent Java (JDK/JRE)
versions is not any particular reluctance on the part of most
clients to keep up with the Joneses in that respect, but because
they are very conservative with all their major software (like app
servers)...which if it's not certified for a later Java means we
can't move to it.
That's just the same phenomenon - "not certified for a later Java"
means that someone was unwilling to move to that later Java until it
was EOLed.
Why don't the vendors certify for the later Java in anything less
than five years?
It's the same question. Pushing it back one level doesn't answer
it.
One reason might be the partial failure of the promise of GC. What I
mean is this: when introduced to GC the usual message is that it is
better than manual memory management and with it software will be more
robust (i.e. not throwing cores, some may even claim that there are no
memory leaks) by having the JVM decide when to collect which garbage.
Also, developers will be more productive etc. This works remarkably
well in a number of situations.
However, the enterprise world often has more demanding requirements
(such as dealing with large memory *and* low latency at the same time).
Whoever went through the exercise of tuning GC settings (of which
there are plenty - just execute [1] on your favorite JVM) for such an
application will be very reluctant to switch to a new Java version (or
other garbage collector for that matter). If you have found a set of
settings with which your application works reliably as expected then you
are not easily giving it up because the cost to go through the testing,
measuring etc. with a new JVM can be significant.
Kind regards
robert
[1] Find out all the options:
$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/