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?
Anyway, regardless of the JVM, applets are only applets. Its security model prevents it from doing anything useful than pretty animation and fancy UIs. But for fancy UIs, we have Flash, which is definitely faster and easier to program. .Net ... in a race that has strong parallels with and implications for Unix/Linux vs Windows on the server side.
I think the primary interest here is "server side Java", doing heavy lifting business applications. Currently Java/J2EE is in a competition with
This memo makes me a bit nervous. Right now, I'm a Java/Perl guy professionally, and this is horrendous publicity for Java, and could pontentially tarnish Unix as well, since Java is so popular for business apps there.
(Applets seem to have kind of fallen by the wayside, though they seem to show up in more places than you'd expect...I can't do applets at work, it pops up a message about the firewall config, and I see that dialog a heck of a lot.)
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
I don't think the "bugs" with huge memory usage and general slowness is limited to the Solaris platform since I've noticed it while running Java applications on Windows as well, while using Sun's JRE. Many of the bugs discussed in the memo is connected to the JDK itself as well, and Sun is concerned with how many bugs are closed with the "Will Not Fix" status. Since the JDK is mostly the same on all platforms due to Java's nature, I'm pretty sure this is a cross-platform problem in many ways.
Beware: In C++, your friends can see your privates!
I'd be interested in finding out what are the causes of the problems with Java. Virtual machines don't have to be pigs. When the IBM PC was first introduced, I wrote a lot of software in Pascal using the UCSD p-System. The applications ran comfortably on machines with a 4.77 Mhz 8088, 8087 FPU and 512KB RAM. Most of the applications and operating system were compiled into p-code, which is similar to Java byte codes. The p-machine interpreter was a small resident module written in 8086 assembly language. The p-code was actually more memory efficient than the machine code produced by conventional compilers.
Mea navis aericumbens anguillis abundat
Although it is well known that Java is a performance hog, and these bugs they talk about are real. And it is well know for anyone who has done extensive Java programming that the people who write Java have always put more emphasis on delivering the JDK and JRE's faster and more bug free for windows, I really do not believe that this memo has been sent or will be taken serisously if it has.
I have never directly worked for Sun, but I have worked with them in many ways and they have been using Java in production environments for a long time and I'm certain they will continue to.
They use it in Solaris 8 & 9. No one ever told me this, but it is not difficult to see this, login to a machine running that OS and start up their print manager, looks amazingly like the Java L&F.
If you've ever taken a training class from Sun, the survey that you fill out at the end of the class is a Java application. I worked at a training center for a while and we never had any problems with this application.
Friend of mine that work for Sun talk about where they are using Java internally and it is immense, there is no way that in the forseeable future any of this is going to change. I'm going to talk to them and see if this memo was really sent out.
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'm not saying that Java doesn't have some performance problems by any means. I program in Java and I know a lot of peoplel who do and we've discussed these performance problems. I've also written hello world programs that don't take up 9M, but then again I question the validity of the programmer who wrote that program. I know if I write it bad enough, I could write a C program that would allocate 9M of memory and have the only functional thing it does is be to print out "Hello world."
So I guess this could be true, but as someone who has worked with Sun before, I find it very, very hard to believe.
"Everybody knows the moon's made of cheese," Wallace.
And I thought I was the only one actually using them. I use them all over. They're a great way to intimidate the other developers, plus I needed them to pass Sun's Cert.
...namely Java. By bringing the Sun Java implementation through ARC, these issues can be resolved.
But what I've never needed to do with them is serialize them. Interesting.
Did you notice that of the 9 key bug/issues, 5 were AWT (GUI) related and 1 was Serializing Anonymous Inner classes.
Why would they bring those up, and then within a sentence or two, mention Python. From what I understand, Python is mainly used for server side scripting. I doubt anyone uses Python for serializing anonymous inner-classes!
The letter was put together hastily at best. It was an eclectic set of beefs.
The last sentence really sums it all up. It's politics to get some resources shifted in their favor for the next build:
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.
The internal memo was from an idiot.
b ugParade/ index.jshtml
Anyone that compares a scripting languate (python) to a full programming language that also as a VM has no clue. a scripting language has minimal overhead memory requirements because it does not have much of a memory management job to do.
Complaining about 'will not fix' items on an older JRE is dumb as their must be SOME reason for the 1.4. If everything could have been fixed in 1.3.1, it would have been 1.3.2.
Further I personally was told not to rely on the "sun" classes as they change. The article writer suggest that each release of the JRE causes classes to be dropped and added. I have NEVER experienced this and its a violation of SUN's stated practice.
"4. It is not backward-compatible across minor releases." Then this fool goes and compares 1.3 to 1.4 or 1.1 to 1.2 as IF those are minor releases. (anyone that uses java knows the 3rd digit has been the minor one) The 2nd number has so far been treated majorly by Sun's releases and I would NEVER call 1.2 or 1.3 or 1.4 a minor release, they have years between them.
As for large footprints, I stopped complaining about even M$ abuse of memory after the price came down so much. Just go buy some more. Its a valid issue, but I wouldn't mark it as worth of writing a letter.
Finally I'd like to ask why none of his bug numbers appear in the Java BugDatabase on the javasoft website
http://developer.java.sun.com/developer/
I'm skeptical of this letters validity.
Why in God's name is this modded troll? Have we offended the slathering hordes of Java devotees? Lemme tell all of you something, when I was laid-off from a position, I went to interview with two shops, both with a heavy Java focus, and roughly equivalent in their focus, style, and clients. I didn't get a job with the first. But with the second, I was given some very good advice: Talk a lot about J2EE, Beans, and a bunch of other buzzwords, a few of which I had never heard of. "Doesn't matter if you don't know, man, just throw the words in. That's all they care about."
.NET. (Don't start gnawing on me because I put "portability" and ".NET" in the same sentence - I was referring to the VM.)
Got the job.
Java is so much about a culture and not a technology that it's disgusting. And it's a pity too, because all the PRINCIPLES of Java (portability through the VM, objectification, etc.) are so good that Microsoft took them to build
Hell, I think Java is a great language. It concerns me that it takes seventeen steps to accomplish something as basic as opening a database connection, grabbing some results, and outputting them into an HTML stream (and seventeen may be generous). But, it's a very straightforward language, very teachable because it's so logical.
But too much of the culture is fluff. Why is it that Sun doesn't focus on point releases that improve performance but instead focuses on getin gthe newest buzzword, uh, "feature" out the door? Why did they invent something called Java2 which is, IIRC, just Java 1.3? Because they're more concerned about IMAGE than about getting their product - which is great in principle - in a usable state.
But let's talk substantively. I've developed large scale server-side applications in Java, C, C++, and - on the web-app side - PHP, Cold Fusion, and ASP.
The slowest of those was, almost without exception, Java. Java took the most coding to do a basic task, and Java was BY FAR the most difficult to package, deploy, and deliver to my customers. That's a real pity, because I was about 90% certain that our customer's architecture didn't really matter if we were playing with Java. Upgrading those old Dell NT servers to IBM? No problem. We'll just move the app over, and it should run without a hitch.
But, lord have mercy, it ran slowly.
To top it all off, here's some advice I received from a Java-guru at another company. I was griping about how slow Java was, and he said to me, "Oh, everybody knows it's slow. But why worry? Hardware's getting faster every day. True, 2ms is half the speed of 1ms, but who's gonna notice?"
I almost fell off my chair. It's that sort of laziness that makes my skin crawl.
Look, I love Java. I want it to succeed. It's a brilliant idea: an utterly cross-platform language whose apps run without regard to the hardware and OS under them.
But it's a seriously flawed masterpiece.
(The funny thing is, I was just going to write "Why was this modded troll? But then my post bloated... kinda like how you go to write "Hello World" in Java and... ok, ok, nevermind.)
Everything about this memo sounds as fake as can be. For example:
Sun complaining about the JRE support model for internal projects...THEY ARE THEY JRE SUPPORT MODEL. It would be a bit like Ford recommending people don't use Ford parts for internal work because they'd have to go to Ford to get support for them. Eh?
Listing off the memory footprint of various "demo" applications. The "Hello World" reference gives this away as totally bogus. Anyone who's used Java knows about its memory consumption. From day one people understand that it is not recommended for smaller applications. That's not the intention of Java, and it's not a recommendation or warning Sun would ever make internally. Java is excellent, perhaps better than anything else, for interoperable, server-side, cross-platform development. The claim that there are "better languages for that" is totally bogus. Show me another single language that packages object communication, database-independent persistance, compile once, reliable threading, and hundreds of other Java features, while being available on every major (and most minor) operating systems and platforms available. An external user trying to take Java down a notch (perhaps a disgruntled C++ developer?) would almost certainly point at the size of a "Hello World" application. BTW, guess what: Hello World compiles to a couple kB of Java code. If the platform uses 9M for a small program, that's not part of Hello World's memory footprint. How much memory does a compiled C program take (including all external libraries and the kernel itself) compared to its compiled size? The holistic difference is striking.
The numbers about startup time and third-party application time. Why on earth would Solaris care if TogetherJ takes a long time to start up? If TogetherJ is written badly enough that it consumes 900MB of memory, then it's a failing of Togethersoft, not of Java. Too many Java developers have fallen into the trap of "memory is cheap, objects are garbage collected" and use truly gross algorithms in their software. A little common sense would reduce the footprint of some of these applications down to much more manageable levels. One should look at Java applications that do extremely well with regards to memory management, for example JBoss 3 and Eclipse. Eclipse provides one of the best, cleanest, well designed Java IDEs out there, and starts up into around 25M on my system. JBoss is a fully J2EE-compliant container, and starts up into about 32M on my machine. Compare that with other offerings.
Backward compatibility across minor releases. Everyone familiar with Java knows that 1.2, 1.3, 1.4, are as far from "minor releases" as they could possibly be. There's absolutely nothing "minor" about them. The small compatibility issues that are listed in this document are almost certainly issues someone would face if they move from one level to the next and use deeper features of the JVM. The concern about Class.fields() is ludicrous. It changed after 1.1 (about FIVE YEARS AGO, PEOPLE) and hasn't changed since. The other two complaints are about UI behavior changing across major versions (1.3 to 1.4 and 1.2.2 to 1.3.1). Guess what...they're going to introduce improvements into UI behavior to improve the performance of the platform's UI as a whole. The interfaces did not change. The contracts between classes did not change. If someone's tables ended up looking a little different (boo-hoo, perhaps this is a Java UI developer who's out of his league) then you either recommend one major revision or another, or you format your UI in such a way as to prevent problems (not a difficult thing to do with Java's UI support). These gripes more than any others point to this being a fake: Everyone outside of Sun knows that 1.2->1.3->1.4 are not "minor revisions" and would never treat them as such. There's NO WAY Sun would refer to them in that way.
Other issues are also well known to Java developers, and are easiliy avoided:
JNI is unstable: Well duh...anytime you link out of the JVM you are dependent on external code for reliability. If the external code bloze or doesn't behave, guess what...you crash. Sun recommends not using JNI unless there's no other way to solve a problem, and wouldn't list this as a fault.
Vitria: 450+ containers? What in holy hell are they doing with 450+ containers? Running a single component in each one? No reasonable architecture would EVER use this many JVMs on a single machine. The person who recommended this should be shot, and the person who wrote this obviously fake memo is looking for worst case scenarios to support their arguments. Regardless of Sun's marketing, companies with alternative languages and platforms would not be buying on if the platform itself wasn't so powerful. Would IBM have blown $1B+ developing Eclipse if they thought Java had unsolvable issues? Not bloody likely.
JSSE referred to like a distant cousin: JSSE is Java's Security Extensions, and although the article is correct (it was formerly a plugin, now included in J2EE) it is referred to as "an external module called JSSE" and never once listed as a security extension. Does the author of this "memo" not know a primary, core technology that Java uses for security? Someone is extremely ill-informed, or has nothing whatsoever to do with Java.
Ultimately, even if this does turn out to be an internal memo, I'd wager it's from a lower-level developer on the C++ side of the company that is angry (or worried) about the push towards Java-based applications over native languages. You can bet your ass this isn't a company-wide, high-level memo, because it's simply not true. How about this scenario:
1. Internal Sun employee NOT involved in Java becomes disgruntled about getting fewer new projects and more maintenance and support work.
2. Employee starts to monkey around with Java, either to nitpick well-known faults and flaws or to gain a better understanding, hopefully to get an "in" on new Java-based projects
3. Employee finds enough nitpicking details to write an "internal memo" recommending Java not be used, or get frustrated that they can't learn the entire language in a day and does the same.
4. Employee writes said "internal memo", hoping to stir up some discussion
5. After the employee's claims are shot down, much like I did above, the employee gets even more frustrated
6. Employee "leaks" the memo to stir up bad press for employer. Since the memo appears on a site where "accidentally" leaked memos appear, employee can feign ignorance.
Everyone jumps to conclusions on these things. Don't believe everything you read. Java is a spectular language...anyone who has used it for any length of time knows that. The people who have never used it on a real-world project are routinely its biggest critics.
I've long believed that Sun, a hardware company, should have taken their Java team and spun it off completely as JavaSoft Inc., as was contemplated in the mid 90s. The consulting and development teams would have one objective: furthering the Java platform. Doing so would have made this memo, if it is legit, a non-issue from a PR perspective. JavaSoft probably would have made the same decision on where to focus their efforts: on making the Win32 JVM implementation the best, and supporting other OSes secondarily. That's what this memo is about: pissed off Solaris admins who are tired of sitting in the back of the bus when it comes to Java. Before the advent of the web applications as the platform of choice for developing new applicattion, and even since, Win32 is where the money is because of the wide install base. (I won't go into whether monopolistic forces caused it; for a software company, you just have to accept this as the current lay of the land.) Obvioiusly the Win32 JVMs get the most development resources, and rightfully so (with Linux probably a close second, thanks to IBM, who wrote their own JVM). Unfortunately, Sun didn't do the spinoff completely, and now people want to see this as a "rift from within" and "Sun not eating its own dog food." I want to reiterate the point that others have made, because some of the early posters missed it: the problem highlighted in this article is with the specific JVM implementation for the Solaris OS. It is not about the failings of Java as a language, J2EE as a specification, nor interpreted vs. compiled applications. Java will be around for a long time to come, particularly in large environments, as evidenced by most major application vendors supporting it (Oracle, Siebel, SAP, PeopleSoft, JD Edwards, etc.) and by the fact that most academic programs are switching to it. In fact, this year for the first time, the high school AP test for programming will be in Java, not C++. It is here to stay because it is a decent enough OO language.
I use and admin Solaris systems every day, at work and at home, and in itself it's a great product. But its biggest problem is Java. More and more stuff is being java-ised, resulting in absolutely horrid performance.
Examples: the SunScreen 3.2 commandline. Takes ages to load or do anything, especially viewing your firewall logs. Sun Managment Center: It does not perform. It becomes completely laughable when you try to display the screen on another Xserver. This is how Sun was demo-ing it at Lisa2001, and although the lead developers over there agreed that it didn't perform, they blamed this on Swing but had this scary religious fervor when it came to doing things in Java.
The new patch-managment tools from Sun? Nice idea, very flawed implementation. Sloooooow, and so buggy that we ditched it, prefering to keep our Suns up to date by hand.
Java installers are another fun item. Sun has a very nice packaging system, which makes it possible to jumpstart machines with identical software configurations etc. But more and more software becomes 'java installed'. It does not add any functionality apart from a badly drawn gui, but it breaks all the convenience of having one standard packaging tool for the os.
Please stop this madness.
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