Hello,
let me contribute a word or two to this discussion...
John Goerzen wrote:
>
> This is not really the point. The point is that for a heavily-loaded
> server, even a small difference in performance can make a tremendous
> difference in the system -- possibly the difference between running well and
> not running at all.
AFAIK unix doesn't support real threads. For new requests a new instance
of the CGI is created with fork() or something like that? Now imagine a
server with a load around 99%.
The first is a "non-java-at-all" Server. It has to create a new process
when a request arives. Where? The system is almost at the limit? It is
likely that it starts paging and if paging starts performance will go
down very fast.
The second server uses servelets and a thread-pool. When a request
arrives a thread is taken from the pool, executes the request and sent
back to the pool. There are no processes to create. Memory is already
allocated (of course - paging may be done here too). When the Server
runs a while then all Classes are native-compiled.
> I do disagree that Java is more maintainable than Perl in general. If you
> know Perl, it is quite easy to read and maintain. The regexp support makes
> it far easier to code and maintain anything that parses things that are even
> vaguely complex.
Yes. RegExps are really missing in the java-core. But there are many
pure-java extensions available.
> I do not, and have never, reccommended PHP3 for anything "serious", for just
> these issues, and others. But mod_perl and FastCGI are quite good for CGI.
Database-Access with php or perl may be simple with simple problems. But
when the problem gets more complex the problems increase exponentially.
For instance you change your database from oracle to informix. With php
you may change all your pages and replace oracle_db_XXX() to
informix_db_YYY(). In java you write a factory which creates the
SQL-Statements and only change the factory. The remaining parts of your
application/applet/servlet remain untouched
> No, I've seen Java programs, and even a "serious" applet or two. The point
> is that this is not an acceptable or useful paradigm in my opinion. The
> fact that the language used is Java is really irrelevant.
Java is not just a language! It is an very large API and a Virtual
Machine too.
And one usefull use of Applets: I wouldn't do my online-banking with
ActiveAEKS or just SSL. A-X wouldn't run on a Sparc ;)
> If one really wants this sort of thing, embedded X may be a better solution,
> but it has lots of problems, too. I don't think it's a good solution either
> (except perhaps for corporate LANs.)
There are some problems which require not much data-transfer but a lot
of graphical work. I cannot imagine transferring every single screen via
X-protocol. (Embedded X is a X-Server inside the browser - isn't it?)
This would almost be like Microsofts "terminal server". (Which needs
huge amounts of main-memory for each clinent)
> You're clouding the issue. The point is that HTML itself is not adequate in
> the case you're describing. In fact, the whole Web idea is not adequate
> here, and it was never designed to be.
Of course it wasn't. But applets seem to be a good solution to extend
HTML to be more "active". (And I do not speak of scrolling texts or
animated images!)
> I have never disagreed that a Java-based GUI application (note, not applet)
> as a client would be good, and in fact, in the message to which you are
> replying, you snipped the part where I said so.
As already written - why to risk serious trouble by mixing lots of
different technologies when you can use one? (If you really need peak
performance you could use JNI with ANSI-C on the serverside)
> I wish people would stop comparing a current Java idea with an outdated CGI
> one. If you want to compare it to CGI, please do us the favor and compare
> it to current CGI ideas.
And I wish people would stop comparing a current CGI idea with an
outdated Java one ;)
Java was designed with JITs in mind. Why would the bytecode assume a
stack-architecture (which is simmilar to intermediate-code of "normal"
compilers) if not to compile the last stage?
regards
Chris
--
public class chu extends ChrisHübsch implements TUChemnitz {
String email = "mailto:[EMAIL PROTECTED]";
String SMSMail = "mailto:[EMAIL PROTECTED]?Subject=SMS: info";
URL homepage = new URL("http://www.tu-chemnitz.de/~chu/");
Talk talkto = new Talk("[EMAIL PROTECTED]");
Integer ePlus = new Integer(4628555);
}
