Interview With the Father of Java

Eh-Wire writes "The Globe & Mail interviews James Gosling after a keynote talk to Sun developers in his home town of Calgary. His thoughts and comments regarding the 'dead end' oil industry, disconnected Telco strategist, and unleashing 'creative weirdoes' makes for an interesting read." From the article: "Java is evolving. It's sort of embedded in the social experiment that is the Internet. There's been tremendous adoption of Java for building large-scale enterprise apps. It's worked tremendously well there. There's been all kinds of growth lately in cellphones and more and more embedded systems. It's all about making the environment around us more intelligent."

Comments

Um, what?

[Anonymous Coward]

Where does this 256mb per user figure come from? Any app that requires that much mem per user, and isn't doing something like ray tracing the next King Kong movie, is broken. Yeah I can write utterly broken C++ that also sucks up 256mb per user to log in to a website, but that has nothing to do with the language.

I think you probably don't understand how Java server stuff works. Your reference to Apache being part of a Java server deployment shows that. It used to be, back in the old days a few years ago, that people often installed Tomcat and Apache together using a connector. I don't know anyone who still does this. Tomcat 5 servers static content about as fast as Apache.

As for threading: If you're writing a web application, you don't need to write any threads. You need to give a little bit of thought to threads, because your Servlets are objects and they can be used by multiple threads at the same time. Handling this is quite trivial: you just don't touch any instance variables from methods in your servlet. If you don't want to try to figure out threading, that's all you need to know. Tomcat will do all the rest.

Again, I have no clue where you got that 256mb per user, but I'll clarify a few points. In a typical Java Servlet application, which would use Tomcat (or similar) to serve an application where users log in, do stuff, and data are stored in a DB, this is how resource use will work:

• Threads: Tomcat can be configured to create however many threads you want. A few dozen to a few hundred is typical. It certainly does NOT create a new thread per request. Just like Apache 2 in threaded mode (which is not its default mode btw) it creates these threads and has them hanging around until they are needed. Just like Apache 2 in threaded mode, these are plain old operating system threads
• Threads again: Your reference to threads, and developers not knowing that Java is threaded, and again this 256mb per user makes me think that you are assuming that every user needs a separate JVM. This is not the case on any server-based app that is correctly written. Yes I can imagine some bozo creating a web app where Apache forks off a ne JVM for each user session... but wow, that is an inconceivably bad way to design a web app, ie, using a JVM for doing CGI. That's fighting hard against the design and the right way to do it, so of course it won't work. You do not Java for doing CGI servers! One web application = one JVM per machine = one JVM overhead per machine. If you are looking at any deployment where that is NOT the case, it was done by someone who is incompetent.
• Memory: Sessions are created with a simple session map. A session itself takes up about 1k of memory. If you're smart, you store a user ID in the session and then the servlets can use that to interact with the database. So you're still storing less than 2k per user in memory in the session. It's no different from how PHP is often used. If you're really clever you use Hibernate and store a lightweight user object in the session, and have Hibernate do all its magic caching and proxying. You still have only a few K per user session to store.
• CPU: Any real-world benchmarks Java just isn't slower. I would expect that a Java web app would use less CPU than a PHP app, because PHP has to parse and compile some large subset of the application with every single request. In Java, the whole thing is compiled to bytecode, which has probably been compiled to native assembly, and it's all loaded in the thread, in memory, ready to go when a request hits it.
• Garbage collection: This is a problem that Java has. The GC does have to use a global lock and stop every thread (I believe) at certain times to do GC. In practice, this isn't so bad on web server apps. It's worse on desktop apps, which do in fact freeze up for a few seconds at a time occasionally.

I really don't think you understand how these things work, and if you have real-world experience with Java webapps, then the ones you are thinking of were written by clowns.

-----------
Contact management, calendar management, sales automation