Slashdot Mirror
Even Sun Can't Use Java
cowmix writes "It turns out that Sun does not eat its own dog food. Specifically, this
internal memo from Sun strongly
suggests that Java should not be used for Sun's internal projects.
More interesting still, they go on to state which other languages
fullfil Java's goals better than Java does itself. Finally, the
memo states Sun's own Solaris is the cause of many of Java's woes. Yikes."
When people ask me about using Java, I always give them a simple answer: it is much nicer to program in then any other language that I use (except for API changes over different versions), but it takes way too much memory and is too slow for programs that I would use regularly.
The memo agrees with me and lists the huge memory requirements as the number 2 problem (number 1 is that Java programs require the JVM to run).
Considering that compiling Java into a native executable would seriously improve its performance (and remove the JVM requirement), I wonder why the memo doesn't discuss that possibility?
My wife writes Java GUIs and actually has never ever had any of the problems that they are referring to in this memo. The GUIs she writes runs fine, and they are very complex GUIs, things that do tasks such as controlling telephone switches.
/I/ may personally like it for many uses, where control outweighs performance. But it's malicious for Sun to claim it fit for mainstream desktop apps.
I have written complex GUIs, which actually overwrite the paint() methods of Components, and Swing is slow on Windows and Unix. Also, I've used Swing apps, and guess what, they're slow memory hogs too.
Inevitably someone proclaims that Swing runs fast if you program well enough. (I'm not referring to you but to Sun's party line.) BULLSHIT. It's slow. It trades memory for speed, and still isn't that speedy. Run Jext or Borland JBuilder and you'll see what I mean.
Now,
It boggles the mind that after half a dozen years of Java, Sun has not yet moved their default desktop over to Java GUI apps. And Sun has missed lots of great opportunities popularizing Java by failing to deliver desktop apps and utilities that would motivate Windows, UNIX, Linux, and Mac users to download the JRE.
I am a former Sun employee and I wrote these kinds of memos.
Specifically, I wrote that Java was unsuitable for Sun's own web development projects, and that this represented a serious problem in terms of missed opportunities to improve our software and for our public relations and marketing.
The memo may be a fake, but it's right on target. I especially agree with the problem of internal tech support for critical bug fixes.
I worked on several projects that were a nightmare due to subtle bugs in Java's HTML and XML classes. In each case, the bugs were easy to fix: a few lines of code, changing private methods to protected methods, etc.
The response from Sun support? "Will not fix."
So I had to rewrite the classes-- basically rederiving the entire Java HTML+XML parsing tree-- which stuck the customer using my custom code. Talk about a bad upgrade path!
There were many, many examples of this. As a result, I deployed many projects using Perl on Linux instead of Java on Solaris, and I wrote internal memos like the one in this article.
All that said, the Java engineers were some of the smartest, nicest people I've ever had the pleasure of working with. I have a lot of confidence in them, and each Java release gets substantially better and faster. The problem IMHO is not the engineers, but the corporate culture that misses opportunities to learn from employee projects.
The Sun engineers and internal developers can really do some amazing things, if McNealy and Zander could start prioritizing Java inside Sun, and start funding rapid-turnaround tech support for employee programmers.
Cheers,
Joel