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."
... a memo which says that Sun has standardized on C# and Microsoft .NET.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
Read the article poeple, what their saying is that the JRE on solrais has huge significant bugs that need fixing!!
To me, this report seems to be the manifestation of a battle going on with Sun between the Java Engineers and the folks who integrate Java with Sun's other products. They went to the Engineers initially to explain the problems, but it didn't change anything. So they wrote a damning memo to management to force them to deal with the situation.
This isn't Sun saying to the world that Java sucks, its simply two groups within Sun saying that their official implementation needs to have a few bugs worked out.
-jrod5000
Assuming the memo is for real, this is a real boon for the Python community, even though it gets the bit about bytecode compilation wrong (Python DOES compile to bytecode and one CAN take the bytecode and ship without source). The point about Python carrying its compiler with it is true but IMHO it is a feature, not a bug. It always bugged me that Java had no good mechanism to compile simple expressions on-the-fly.
I am, however, a little leary on the performance parity bit. Don't get me wrong, I love programming in Python, but I know from experience that it still costs a good bit to create all the dictionaries that are used for frame construction, global maniuplation, and object management.
Python is, however, fast enough for a great many applications. I'm just a little skeptical about it being quite as fast in certain aspects.
This memo states that Sun believes their Solaris implementation of Java to be flawed.
It states the flaws; ie. which flaws should be fixed.
So?
A REAL "shocking memo" would be one in which the company goes out of it's way to not criticize it's own product.
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?
In the rush to bash Java, the summary here was totally off the mark. From the article:
A review of the problem indicates that these issues are not inherent to Java but instead represent implementation oversights and inconsistencies common to projects which do not communicate effectively with partners and users.
And it goes on to mention issues with Solaris. Nothing about Java itself being inherently problematic, just issues with certain implementation.
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
InternalMemos is notorious for running hoax emails. This email is no exception. It includes a number of inaccuracies and curious references. The comparisons with Python are just amusing.
Doing a quick search on the names, you'll note that there's no reference to the sender anywhere in Google, let alone associated with Sun. Most of the folks in the CC list do not have Sun email addresses. They're probably friends of the hoaxer. The Sun folks in the CC list include a JavaOne and a guy who has himself on the J2ME JSR.
I wouldn't hold out for Sun switching to Python. haha
I was especially interested in the part of the memo that talked about extensions being rolled into the main product. But, apart from backwards compatibility, I think it just makes learning the language more difficult.
I learned the language back in 1.3, and I'm amazed at how much more has been added to the 1.4 release. Sifting through the javadocs has become a bit more of a pain, but nothing someone already familiar with the language can't handle.
My concern is people who are learning the language. I think the API is becoming more and more overwhelming to future Java developers. Look how much fatter O'Reilly's Learning Java book has become!
A smaller J2SE with standard extensions to be downloaded as necessary makes better conceptual sense.
quiquid id est, timeo puellas et oscula dantes.
Reads to me like a memo that has intentionally leaked out into the open, trying to force Sun Management to act. Software Development Dept is clearly unhappy with the Solaris implementation of JRE and therefore stops all use of it, until is has been fixed. While the Java Dept does not seem to have too much hurry to do that (majority of cases closed - "will not fix".
What would you do in your own line organization, when you are the boss of one department and the boss of the other department just gives you the finger? And your superior is unable/unwilling to solve the conflict? You write a flaming mail to your superior's superior, threaten to withdraw any support for the platform your company is famous for and leak the memo into the open to get public support. This, of course, has to be done nicely so that no-one can blame you directly for it.
Excellence: Moderate (mostly affected by comments on your karma)
How do we know this is even a real internal memo? I mean, this is comming froma site *named* internalmemos.com. Come on! There's a submission form. I could just send any old thing in if I wanted. The only difficult part is making it look convincing. That only takes a few hours of effort.
Anyone that has an axe to grind with Sun could have sent this in. That could be some big company or (far more realistic) some random slob that just wants to be mean.
Or it could be real. But who cares? As the Score 5 AC pointed out, this is about bugs in the JRE on Solrais, not necessarily about Java in general.
Does anyone on slashdot remember what FUD is?
Furry cows moo and decompress.
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:
Purported internal memo. There's nothing there that suggests it is genuine and a few things that suggest it isn't.
I hope this illiterate drivel was intended as a troll, but just in case it was not:
Forget Java man and go to PHP!
Java is a general purpose programming language, PHP is not. PHP is a scripting language designed for server side web scripting. Ever tried writting a server in PHP? You can't, it doesn't let you accept incomming socket connections.
PHP is 4 times faster than Java technology 'JSP' (Java server pages).
I'm not sure where you get your numbers from (the link you post is to a non-existent howto in the LDP), but I doubt that they are accurate. PHP is an interpreted language, C is a compiled language, Java is a hybrid (Just-In-Time compiled). C is likely to be faster than both (although a JIT language can make use of run-time profiling for optimisation, so in theory Java could run faster than compiled C code, but this is new technology so it doesn't - yet). Primitives in C are typed, in PHP they are not. This means that PHP has a lot of type checking to do even for simple variable assignments. PHP is unlikely to be faster than Java (although it may still fit your needs better in other areas).This tallies because compiled "C" program is 4 times faster than Java.
PHP is a very lightening fast object oriented scripting language.
PHP is not an OO language. PHP supports a few features of OO, but not the vast majority (public / private methods, inheritence etc). PHP Classes are more equivalent to namespaces than classes.
PHP is 100% written in "C" and there is no virtual machine as in Java.
PHP is an interpreted language (how many times do I have to say this?). There is a virtual machine, and it interprets the PHP script. The Java VM compiles the bytecode to native code at run time (and only once, when the JRE is started in server mode). <oversimplification>
Nothing can beat "C" language
This is the stupidest statement I have ever heard. C does nut support dynamic strings, so only a fool or a masochist would use it for simple text manipulation tasks (ever written a CGI script in C?). C has many advantages, it's a mature language so a lot of work has gone into making it fast. For this reason it is good for low level system work. It is not the best tool for every job. If the only tool you have is C, every problem looks like an operating system...
Java programmers will really "LOVE" PHP as PHP class is identical to Java's class keyword.
Java programmers will loath PHP. It doesn't properly support a large number of features found in Java, because it is not a general purpose language, and it isn't even an OO language. Web developers like PHP because it's simple. For a detailed criticism of PHP look at thi paper published at the UK Unix Users' Group last year. (And possibly read my reply to the criticisms made.
The aim of java was to abstract the OS and windowing system away from the developer, and in this it succeeds quite well (although it still has speed issues and the API is baroque in the extreme in places - try creating a non-blocking port in Java if you don't believe me). PHP is an interpreted scripting language aimed at web design, which has agregated, rather than being designed. Comparing the two is a crazy as saying Mozilla is far better than Linux.
I am TheRaven on Soylent News
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.
For server-side apps, it makes no difference whether Microsoft bundles the JRE or not--anybody putting together a bunch of servers is going to install the latest JRE directly from Sun anyway.
In fact, while Java is a decent language for server-side development (and that's pretty much the only thing it's really good at), it's ironic that its cross-platform features in particular are largely irrelevant there: for many other reasons, any reasonable place is going to have a homogeneous server environment for individual web apps, and re-compiling for that server environment is a tiny part of deployment.
So, something like GNU gcj, which requires recompilation for each target platform, may well be the better choice than Sun's bloated JRE: while you don't get universal byte code deployment, which you don't need, gcj binaries start up much faster and consume less resources, which may be more important on your server.
The note is certain to be used by Microsoft in their appeal against the Java injunction.
In particular the points about Java code being tied to a particular runtime completely negates Sun's claims about the need to distribute in the O/S base. Clearly that is not going to help much since Sun have no clue about dependency management.
Consider the following thought experiment. Microsoft distribute 30Mb of Java 1.3 with XP. Then Sun upgrade to 1.4, what does Microsoft do? Do they distribute 1.4 on the new O/S versions only, add it to the current release of XP or put it on instant update. None of these work. The instant update option will break existing java applets on the system. Mixed versions of java will mean that consumers buying a Java based progam will not be able to rely on the release number of XP to decide whether the program works on their machine. Waiting till the next O/S version is released will result in a lawsuit from sun.
The note shows clear similarities to the early articles on C# explaining the difference in approach between Java and dotNet. If the Java lobby was not so convinced that Java was the end of program language design they would have realised their significance.
To give one example, the version incompatibility problem is known to Windows developers as 'DLLHell'.
My company uses Java for a lot of projects. I would not be suprised however if we didn't end up on .NET server with the applications compiled down to native code through J# and IL.
Unfortunately Sun don't have a level 5 leader in charge. They have an egotistical idiot who is concentrated like a laser on another companies business instead of his own.Antics like those of McNeally and Ellison play well in the press but measured by the success of the companies stock price leaders like Jack Welch or Lee Iaccoca don't do as well as their PR would have it. Iaccoca may have saved Chrysler (it might also have been the government loans) but once he started concentrating his energies on being a folk hero Chrysler's performance went back down the tubes. Similarly Jack Welch's performance does not look that hot if you look at the growth in GE earnings rather than the stock price - which is certain to shrink as GE returns to its old P/E multiple.
One of the things a level 5 leader does is to encourage comment. The memo only says what others outside Sun have been saying for eight years.
My take on the Sun/Microsoft Java war is based on a lot of time working in standards groups with both groups of engineers. I think that the Microsoft engineers thought they could improve Java and got frustrated because the Sun engineers behaved - well like Microsoft engineers sometimes do.
Of course this will all be rationalised away. Of course it was all the fault of the Redmond club's evil schemes. Nobody outside Sun has any ideas of any value and Sun's JCM is genuinely open and not a proprietary farce.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
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.)
"The note is certain to be used by Microsoft in their appeal against the Java injunction."
Um, no.
First off, who knows if the note is even authentic.
Secondly, what will be MS's argument?:
"Judge, Sun feels they should improve their Java product. As you know, the law states that no company should be able to improve their products, unless they are us, and we can improve other people's products, but only for Windows. Thank you."
smd4985
I still work for Sun and have never seen anything like this memo. Java is still used daily for internal projects, still hyped strong and developed strong, and I've never seen a Sun person try and dissuade another from using it.
If the memo is real, then it's being kept in a very small group.
If it's fake, they did a good job with the language and examples.
It is more productive to voice thoughtful opinions (reply) than to judge (moderate) others.
InternalMemos is notorious for running hoax emails. This email is no exception. It includes a number of inaccuracies and curious references. The comparisons with Python are just amusing. Doing a quick search on the names, you'll note that there's no reference to the sender anywhere in Google, let alone associated with Sun. Most of the folks in the CC list do not have Sun email addresses. They're probably friends of the hoaxer. The Sun folks in the CC list include a JavaOne and a guy who has himself on the J2ME JSR. I wouldn't hold out for Sun switching to Python. haha
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.
Well... The Inquirer had a blurb about this about a week ago, before anyone heard about any "memo".
This article is a giant vat of uninformed bullshit.
I won't address Java 1.4x points because in general, java 1.4 sucks. (Handicapped threads, new io architecture forced on installed base, inept standard regex and logging facilities, bah)
Java on store shelves: The fast majority of companies use java to model internal business processes and integrate them into systems. Java is extremely useful for this because programmers don't have to worry about hardware. This is not the kind of software you shrinkwrap.
TogetherJ/TogetherSoft: The installer asks you if you want to install a JDK with the product, or use a separately installed one. It also will tell you if your installed JDK is sufficient.
Python: Python source is compiled into bytecode upon first interpreting. It has it's own VM, also mutable from native code. There are quite a number of differences between python and java, but your comparison is uninformed.
Java Minor releases: The differences between 1.2 and 1.3 is quite large. These are not minor releases, despite sun's versioning scheme.
JNI Stability: JNI isn't easy to produce correctly. But it's stability is a responsibility of the programmer. C programmers don't blame the OS when a program segfaults.
I guarantee had this article been about perl's deficiencies, it would've been scrutinized with a scope large enough to see Venus, and wouldn't have made it passed submission.
Really? Then who is Julian.Taylor@central.sun.com?
.
I found Julian here and here
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