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."

Embedded and Java shouldn't be seen together!

[Bad Mamba Jamba]

There's been all kinds of growth lately in cellphones and more and more embedded systems.

As an unfortunate software developer on one of Sun's high profile embedded Java projects, OCAP, it irks me to see Java and Embedded listed in the same sentence. I could rant for days on the shortcomings of Java and it's unsuitability for an embedded environment but to name some of my biggest peeves...

1. Any language without unsigned primitive types doesn't belong in embedded land. Embedded systems frequently use unsigned data types. Making me cast up to a bigger primitive size and doing all kinds of bit manipulation gyrations to make unsigned byte data come out right is just wrong.

2. Most embedded implementations don't have room for a JIT compiler. So you end up interpreting everything or precompiling on the way down to the embedded device. Most embedded devices these days still have pretty lame CPUs in them so everything Java is extra extra slow even relative to a desktop counterpart. Especially if you're doing an app with any kind of graphics. As for pre-compiling...this simply isn't an option in some deployments...say OCAP for instance!

3. Many embedded environments use multithreading to process various IO tasks etc. Having what amounts to a critical section for your only means of synchronization (and yea Java 5 tries to solve this but most embedded devices are still back on 1.x implementations of Java) leads to one heck of a deadlock nightmare if you aren't very careful with your design. I need not cite the performance hit here either if you're lazy with your syncs. I also need not mention that the thread scheduling is left unspecified so your app may run OK on one JVM but when you port ot another there's no telling...

4. Java requires a lot of memory if you really want to do something useful. Especially anything graphics related. Most embedded devices don't abound with a ton of memory. As such you end up garbage collecting more and running into problems. Garbage collection can be a costly operation per #2 above. And finding a memory leak in a Java program ain't no picnic either. Especially on an embedded device where you may or matynot be able to get tools in there to see what's going on.

Yeah you can circumvent some issues if you're smart about your design and don't do stupid things but so far most embedded Java developers I've met are imports from desktop/server land and don't think about this stuff so you can imagine the mess you end up with.

Just my two cents...

Java bloat

[Anonymous Coward]

Now I know I am going to get mod down, tossed to the wolves, raked over the coals with an inbox full of your nuts -- but here goes because after spending 4 years in Java I now have an opinion.

Java is bloatware and sells hardware. It is great on a desktop as an applet or even as a program running locally where you have 2GB or ram and dual procs to itself. But it has no freaking business on a server. In fact, those writing server apps in Java are plain utterly stupid.

Lets do the math... I have 600 users on a machine using C/C++ based programs, runs quite confortable with a DB and 8GB of RAM.

Now some Java replacement, needs 256MB per user. 256MB * 600 == happy salesperson. T2000 are nice machines, but to run much of that Java code you need many of them.

Ya, I know Java is threaded... how many developers know that and server 600 users out of one instance? Even if it is nicely threaded with apache, if you have to restart the VM for some reason you kick all users off. Messy.

I hear someone say Java runs as fast as C... if I ever meet them I hope they are a betting person.

Java is for those too lazy to learn C/C++.

Unsigned types

[Anonymous Coward]

As someone who has also use Java for low-level network stuff, let me just confirm, you are absolutely correct, lack of a simple unsigned byte type is hyper-annoying. I would like to have an unsigned byte type and easy operations to do bit manipulation. That stuff can be some of the most annoying part of code to debug. If some bit gets set in the wrong place, all of Java's fancy strong typing and all that doesn't provide any help. The only thing that would help would be better instructions or some helper methods.

Oh and on this subject, there should be a built-in simple way to convert a byte[] into a plain old hexadecimal string. They have ways of doing pretty much everything, including manipulating zip files, URL-encoding, on and on, but no built-in way to convert a string to hex.

Don't get me wrong, Java really is an excellent language for low-level network coding, and in fact a DNS server I wrote in pure Java was able to out-perform BIND, so it is a great language for this stuff. It's just that I always find myself getting stuck occasionally on bit twiddling.

Anyway, one of things that hurt Java was there was too much hype for running it on the desktop, when the reality was... AWT. At this point, with Java 6, Swing is getting quite excellent. I now think that Java is also a first-class desktop app development language. ----------
Contact management, sales automation, time zones, mobile alerts [contempo.biz]

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 [contempo.biz]