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

...Or not.

[dolphinling]

Funny. Some Mozilla people were just about how Sun completely screwed up and all the different places (LAMP, interaction with webpages, etc.) where java could have been big, but wasn't.

Shameful exploitation of VIPs at Sun

[Anonymous Coward]

I attended the Sun Developer Day in Calgary this week that Mr. Gosling gave the "keynote" at.

The talk was almost the exact same rambling "Java is everywhere..." speech that he's been giving for years now. The highlight was when his Mac completely locked up during the presentation and he had to do a cold restart! He claimed it's never happend before in 5 years of Mac use... ...Hmmm, I'm sensing a unique opportunity to enrage both the Apple zealots AND the Java zealots in one post! ;)

Anyway, my point is that Sun has a long history of exploiting some of their top talent by forcing them to travel around the world giving these lightweight marketing talks at corporate events. I remember in the late 90's it was the same thing with Bill Joy. They had him doing so many talks in different cities every day that the actual meeting was in a room at the airport! He was literally on the ground for less than 2 hours, then off to the next stop.

They fly these guys around on these whirlwind trips to try to draw people to marketing events they would otherwise not bother with. It's seems like such a waste of talent/time. Maybe Sun would be better off letting Gosling and his ilk work on interesting projects that might actually provide Sun with new revenue sources, or at least give them something new and interesting to talk about when they do have to give speeches.

Even at JavaOne, Gosling's role in Java has been reduced to little more than the "funny looking guy that throws out the T-shirts". It's sad really, I never thought I'd feel sorry for James Gosling, but on Tuesday I did.

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

Re:Java's so 90's!

[leenks]

Haven't you seen annotations ?

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