Re: Help me!! Why java is so popular

The single/multi processor state can be changed after an application has
been installed. A JVM will adjust accordingly, but happens to your EXE
that was selected/compiled for the single processor that existed at
install time?

Well, I'm recompiling it for the new target environment while they're
swapping the gear on the production box.

The entire argument around auto-configuration of runtime code is
valid, but it assumes you'll be changing the underlying platform over
the lifetime of the code. While that can and does happen in some
environments, sometimes frequently, there are many envs in which
that's not the case, or change is infrequent enough that it's trivial
to regenerate the runtime for the appropriate target if you need the
fastest speed you can get.

And just as the JVM can autoadapt, a programmer could build different
versions. Obviously it's not a side effect of the environment when
you're spinning it yourself, but just to be fair regarding all
available solutions.... startup logic could perform the same set of
checks to find out what hardware is installed on the host, and the
startup overlord can manipulate the runtime in some manner (rename the
binaries, change startup link pointers, etc) to facilitate the best-of-
breed for that environment accordingly.

The difference, obviously, is that with Java the programmer doesn't
have to concern her or himself with these mundane details -- all java
programs will inherently obtain this effect based on the JVM's
capacity to provide it. The skilled engineer can easily build a
library of platform checking and invoke or autoinstall the right code
when the changed hardware is detected. If that dynamicism were needed
based on the problem space, it's a reasonably easy feature to build.
"Back in the day" when controllers were really dumb, we used to write
streaming tapes with interrecord gaps that were the minimum size
possible and still provided ample time to perform inter-record
processing (programming DMA controllers, generating CRCs, etc) on the
slowest processors on the market at the time. It was always
interesting, as we had to run a sequence of instructions at startup to
see how fast they'd execute -- the faster they ran, the longer we
needed to configure our wait/delay loops in the inter-record
processing routines. That stuff was all based on the main clock,
since "smart" controllers weren't available to most devices at the
time, so drivers ran on the host's CPU.

Anyways, I'm not poopoo'ing the dynamic feature of Java -- it's very
cool and has its place to be sure. By the same token, HW engineers
may eventually standardize CPUs and aux processors, like FP
processors, to render the differences insignificant. And it's like a
lot of things provided by Java's dynamicism: they're awesome when you
need'm, pointless and wasteful when you don't.

More often than not I don't require the dynamicism, so it alone is not
a big selling point for me. Your mileage may vary, and that's cool,
it's just for me Java's dynamics are not why I choose it -- as I
mentioned, for me the overhead is a turn off. Heck, I'm not even
attracted by the fact the programmer is freed from the need to manage
her or his memory space -- I don't personally find memory mgmt
terribly challenging work.

What sells me on Java is the breadth of elegant frameworks, the
general (not always) ease of adding new functionality by adopting
classes into your app, and the completenes of many classes out and
about.

For example, we use Spring framework at the office, and it's a really
fabulous way to construct a distributed network of components as
services, and it does certain things to greatly reduce the "noise" in
code such as using "injection" to clean up constructors. Pretty
compelling stuff, and really a much bigger selling point, IMO, than
running under the auspices of a JVM.


.