Server-side Java

[v4vijayakumar]

How would you justify the aditional layer (JVM) in application server?
Do server-side code really need platform-independence at the cost of
performance degradation?

 

[Jon Martin Solaas]

How would you justify the aditional layer (JVM) in application server?
Do server-side code really need platform-independence at the cost of
performance degradation?

Good question, but what's the alternative? .NET runs in a jvm too, PHP,
Perl, Ruby ... you name it. Maybe because the overhead isn't generally
that large?

Especially on a server, where the code runs for a long time, the jvm
optimizer does a good job translating to machine-code exactly suitable
for the CPU at hand. You can do the same with a traditional compiler,
but you'd have to re-compile/link, manually not for every platform but
for every CPU variant. So it seems most people think the answer to your
question is yes.

 

[Alex Hunsley]

How would you justify the aditional layer (JVM) in application server?
Do server-side code really need platform-independence at the cost of
performance degradation?

This reminds me of the thing about the first people to write
assemblers[1] meeting great resistance from management because it would
just be 'a waste of time'. Likewise for writing the first generation
language compilers. Yes, these things took up time to do, but in the end
the benefits made it worth it[2].
In the same way, running web applications in a JVM provides benefits.
And the performance degradation might not be as big as you think. Gone
are the days of running only cgi bins, which required a new process to
be launched for each request. Now you can have a web server, with a JVM
already loaded and read, and even a servlet pre-loaded and ready to do
business.
(Yeah, I do know about mod_perl etc. for apache, I'm not saying things
outside Java are still quite as clunky as old style cgi bins.)

[1] i.e. for turning assembly instructions like 'LDA#65' into machine
code instructions
[2] Unless you're Steve Gibson, who seems very pleased with himself (see
his website) that he writes windows apps in assembly. (No, not kidding.)

 

[Gordon Beaton]

How would you justify the aditional layer (JVM) in application
server? Do server-side code really need platform-independence at the
cost of performance degradation?

What does your server spend most of its time doing? Probably waiting,
closely followed by doing IO. Or maybe it's the other way around. Of
course these are just guesses, so you'll have to measure to be sure,
and every server is different.

Do you think that code written in Java waits any less efficiently than
code written in, say, C? Does it perform IO any less efficiently?

Here's another idea: regardless of whether Java is more or less
efficient than C or C++, it could be that it's easier or faster to
develop correct code in Java, or maybe it's easier to handle Runtime
errors in Java, or avoid some kinds of tricky problems.

Performance isn't everything. Remember: make it *work*, then make it
fast *enough*.

/gordon

 

[Chris Uppal]

How would you justify the aditional layer (JVM) in application server?
Do server-side code really need platform-independence at the cost of
performance degradation?

You have two assumptions here, and I don't think either is valid.

One is to assume that a JVM will impose a significant performance hit. It
/might/ but I doubt if it would in typical server-side applications. (Where IO
and DB performance tend to dominate).

The other is to assume that platform independence is the driving factor. There
are many reasons for wanting to avoid C/C++ such as wanting automatic GC
(minimises memory leaks -- /important/ for a server), wanting to avoid
buffer-overrun bugs (putting vulnerable C code in a network facing position is
a recipe for disaster), wanting access to good internationalisation facilities,
preferring to use Java as a programming language, etc, etc.

(BTW, machine independence is not entirely irrelevant for server-side
programming -- for instance it's nice to have the option to switch easily from,
say, Intel-based boxes to big iron from Sun, or from Windows to UNIX, or
vice versa, as the cost equations change).

-- chris