Even Sun Can't Use Java 833
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."
Not too surprised (Score:5, Interesting)
Unfortunately, I am not surprised (Score:5, Interesting)
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?
dog fooding is a microsoft phrase (Score:2, Interesting)
Do you find it just a little curious that the story contributor used that particular phrase? Methinks a Microsofty at work here. Nice job, cowmix.
Re:Hypocrisy? (Score:4, Interesting)
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.)
Re:Not Java but the Solaris JRE (Score:5, Interesting)
Re:"viva la resistance" (Score:2, Interesting)
amazing how Microsoft just decides to implement a language, and it outperforms the original by logorithmic factors.
Java Implementation (Score:5, Interesting)
Gotta agree with you on that one. (Score:2, Interesting)
There are two core problems here: One is that Sun's implementation of the JRE for Solaris is an even bigger hog than Java is naturally. The second is that the JRE in general has got too damn many built-in libraries. It's very convenient for me as a developer who uses many of the extensions anyway, but it's making the language much more intimidating to approach.
I question the validity (Score:5, Interesting)
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.
Ahh, Taco (Score:2, Interesting)
Please. Try to communicate the essence of the article in your summary.
The essence is, Sun has a buggy implementation of Java on Solaris that is scaring off internal developers.
The essence of your summary is, Java isn't usable, and Solaris is a problem. Duh, you missed the connection! It's Sun's *implementation* of Java on Solaris that's inadequate. The memo stresses that nothing's wrong with Java, and it doesn't suggest that anything's wrong with Solaris.
Why would you write such misleading over-generalizations? What's the motivation? C'mon, Taco!
*please* read the f**king memo before posting (Score:2, Interesting)
1) Large memory usage (cites an example of a "hello world" program using up 9MB)
and
2) Long startup times
the memo blames these problems in the SOLARIS implementation of java VM on the "fact" that that project doesnt seem to have prority. The memo states in passing that the win32 vm doesnt seem to suffer from these problems as much. So the memo specifically restricts itself to the solaris jvm.
It also talks about how the java vm doesnt confirm to the sun SDF, and thus the versioning is incomaptible with it. There is no support for patching an installed java vm, thus requiring an entire new install of the latest version of the jvm if a bug is discovered. This means either having multiple jvm installed and running if different java applications on a system need different java releases, or breaking a whole set of applications, which may not run with the latest release. Again, cites examples of these.
The memo makes a case for:
1)introducing a patch system for java vm, so there need not a a new install everytime a bug is discovered.
2) stict backward compatibility, so that an application written for the older version of JVM works with all later minor revisions
3) consideration of a new mechenism for "bsoleting" and interface replacing/in addition to deprecation.
4) priority for solaris jvm development, with claims (by comparing it with python!!) that the memory footprint of the java resident set (the code bloat added by the garbage collector and co to each running java program) maybe reducible to a fifth of its current size.
read the memo. its a very intelligently argued writeup, and has been completely misrepresented in the slashdot post.
very interesting read.
Ghoul2
Anonymous Inner Classes (Score:5, Interesting)
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:
Re:I question the validity (Score:5, Interesting)
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,
Re:Java No Cocoa Yes (Score:1, Interesting)
WebObjects went from number one to has-been, and these same two factors were a large part of the reason. You get these admittedy elegant abstractions, and then discover they've (deliberately) failed to expose one crucial thing and you get lost in Kafkaesque world of trying to work around their arrogance. All the time the wonderful elegant frameworks would've saved you is out the window.
Half the webobjects world (now a tiny insignificant fraction of the web application universe due to Apples ineptitude) have pitched the development tools on the midden heap where they belong and switched to Eclipse + Ant.
WebObjects was ported to Java four fscking years ago and ProjectBuilder still has no concept of packages. Can you believe that BS???? How can an IDE that targets java not know packages? only from Apple.
"The Java Problem" (Score:2, Interesting)
Furthermore, they don't advocate abandoning Java in favor of Python; the theoretical performance of the two languages is the same, so they compare the actual performance to show that the JRE is unnecessarily slowing Java apps down.
I think the poster was much too eager to bash Sun to actually bother reading the memo.
Re:It would be interesting to find... (Score:5, Interesting)
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.
Smells of a Fake (Score:4, Interesting)
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.
Re:... nothing new under the sun (Score:4, Interesting)
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.)
This is why one reason IBM build their own JDKs (Score:2, Interesting)
the Java Myth part Deux (Score:2, Interesting)
Re:Hey wait a minute ! (Score:3, Interesting)
However, most of problems mentioned in the article are the same on all other platforms. For example the size of "Hello world" program (including RE) and how it grows with complexivity is a real Java problems. Check you memory for even small real-world (10 users, shopping cart with a catalog in SQL) application with EJB (JBoss), no EJB (just Tomcat servlets) and Zope. 250MB vs 75MB vs 15MB.
Java has been developed at time when CEOs/CTOs/COOs/CFOs have been counting fundings, not expenses and profits. When the buzzword had more priority than real features and problems in any technology choices. The time of "golder rush" is over, cool down. Now it's time to think. Sun begins to think. I hope it's not too late.
Re:the Java Myth part Deux (Score:1, Interesting)
Re:I question the validity (Score:5, Interesting)
I have worked at Sun and this smells very real to me. I have a friend at Sun who wrote an application in his spare time (in Java) which was officially adopted for internal use - he spent a month working with the internal applications gestapo having it re-written from scratch "to official standards". I agree with much of what the document says. Writing a complex Java application means targeting a specific JRE version, it is not at all unusual for Sun software products to install the particular JRE which they were written against (look at SunMC and the SunRay server software) - it's easier to keep patched without breaking other things.
Until the Java developers use Solaris as their tier one development platform and API changes are controlled in the same was Solaris itself (PSARC) this will continue to be a problem.
Re:*please* read the f**king memo before posting (Score:2, Interesting)
This was written by some engineers who want to run the program through a slow (and I'm sure costly), corporate QC program. I've written memos like this myself when it seemed my supervisor didn't have the wherewithal to resolve an issue on his own, sometimes at my supervisor's request. I can't help but think that it's a possible start to SUN addressing the stated problems responsibly. (Memory usage, version clash, and poor performance on the "native" (Solaris) platforms are all huge issues). Alternatively, SUN could just decide the extra cost for QC will make the JAVA project prohibitively expensive and take another direction. Either way, it seems like this document is not some screed on the viability of JAVA but a plea for funding to make it better.
Re:Hypocrisy? (Score:3, Interesting)
From their actions, it is clear they realize the future is in Windows and Linux. Not Solaris.
The evidence is their support of JRE on Solaris.
Re:But there is still GCJ (Score:2, Interesting)
I have tinkered in both Python and Java, and I just like Python better; the learning curve didn't seem to be as steep. So that's my bias. Just wanted to get that out of the way. :)
The article points out that, when roughly equivalent tasks are performed in Python and Java, the Python process uses about one fifth the memory resources of the Java process. Is Python more memory efficient because of better initial design, or because the source for Python is available, and developers that didn't like excessive resource usage could do something about it (and submit their fixes)? Or is it a combination of both?
In the past, I have worked on several projects that used closed-source components, and about every year or so we would encounter some obscure problem in the closed-source stuff. In some cases we could get a fix from the component developer, but it was on their schedule, not ours. Sometimes we got brushed off, because we were the only customer that was affected, and it wasn't worth their while to fix the problem. So we were stuck. That really sucks.
I am in the beginning phase of what (I hope) will become a large commercial project, and at the moment I intend to use Python wherever it is practical. Even though I have never taken the time to dig into the Python source, I know that I can if I have to (as a last resort). That alone is a big reason for me to prefer Python over Java - if Sun's own internal developers are ignored when they request fixes in the JVM, why should I expect to get them?
And then, of course, there's the legal issue that bockman brings up: will the GCJ implementation be crushed or stunted by Sun? I think I'll just stick with things that I have complete freedom to use.
Re:Applets? What year are you in? (Score:2, Interesting)
You have avoided my central point that applets are for the most part historical relics.
I think the point of Sun's case against Microsoft is that they have essentially killed Java on the desktop primarily through the deployment of an incompatible thus making applets historical relics.
The question is would that had happened if Microsoft hadn't done the things it did. If the case shows that Microsoft directly contributed to the decline of Java on the desktop through illegal monopoly behaviour then some remedy must implemented. An appropriate remedy would be to force Microsoft itself to be the one to correct the damage they did by delivering a Sun JVM with every copy of Windows and Windows updates.
This smells like a fake (Score:5, Interesting)
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.
Won't eat it's own dog Fud? (Score:1, Interesting)
1) "We believe that our Java implementation is inappropriate for a large number of categories of software application"
- the categories are never listed.
- having a server run 500 client applications will obviously chew up memory.
2) "Bugs against base Java aren't fixed" (paraphrased slightly)
- all products have maintenance lifecycles and a lot of problems are not worth fixing in a (for example) 1.1.8 VM. This is why you test your application properly before deploying it...
3) "The support model seems flawed" (Java apps depend on the JRE).
- Most commercial Java apps will ship their own JRE. Some even ship with a JDK. Software shops with half a brain realize there are going to be incompatibilities and as such pick a VM to work with early on. If they have to switch late in the development cycle it requires significant QA. This isn't rocket science - you'd have the same problems if you depended on some 3rd party library, regardless of language.
4) "It is impractical for a project based on Java to correct bugs in the Java implementation"
- true, but it has proven itself stable and effective in many environments. Especially for server development...
5) Why are the shelves at CompUSA not crammed with
- because it's not cost effective to distribute software in stores when most people interested in your product can grab a copy directly from you, the manufacturer.
- because people don't go to CompUSA to buy an application server or a web application.
6) "The JRE is very large"
- it depends on what you're doing with it. No, it doesn't make sense to rewrite binutils in java. If this is your goal, you'd be better off keeping a JavaScript engine in memory, or going with a persistent reuseable VM like what IBM does with CICS. Sorry, I don't think IBM builds one for Sparc at this time...
- a 64 bit VM will be bigger than a 32 bit VM. It isn't clear which versions are being compared, nor is it clear what applications are doing to generate heap sizes of 900MB. It would be more interesting to compare the ratio of Java heap and process size.
7) "Imagine what happens if...all 150 users on a SunRay server were running one Java program"
- imagine poorly architecting a solution and blaming the hardware for your lack of foresight! Should this letter not be a hoax, I have sympathy for the individual -- clearly there are PHBs at work here...
8) "It is not backward-compatible across minor releases".
- examples cited were from 1.1 VMs to 1.2, 1.2 to 1.3, and 1.3 to 1.4. These are *not* minor releases. I'm sure there are examples of incompatibility between a 1.3.1_03 and 1.3.1_07 VM, but anyone upgrading or switching VMs for their application should be paying attention to the bugs fixed (see point #3).
Re:This smells like a fake (Score:2, Interesting)
No, it would be like Ford recommending not to drive a ford car to work because they are to unstable to ensure that people come in time.
>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.
Yes but their point is that the solaris version of jre is far worse then the windows version. The solaris version of jre require twice the memory of the windows version to run the "Hello world" program. And the fact that I know about the memory usage of java does NOT make it less of a problem.
>Eclipse provides one of the best, cleanest, well designed Java IDEs out there, and starts up into around 25M on my system
Eclipse might take 25MB to startup, but try to use it for a few hours and se you memory usage go to atleast 100MB. But Eclipse is worth the memory so I just bought an other 256MB ram and are a happy Eclipse user
But Eclipse just confirm the point of the memo.
After testing awt and swing, they(The developers of Eclipse) came to the same conclusion as this memo: That awt and swing are unuseable for big projects. I really think sun should think about replacing awt and swing with swt.
>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.
Well the Sun release manager don't know about.
Remember a version number is Major.Minor.Revision so if
1.4 is a major to 1.3 it should have been called 2.0 AND there should have been an easy way to ensure that an application could pick between jre 1.3 and 2.0
I am developing an application(Primary target windows and Mac) which currently run fine in jre 1.3 but got problems running with jre 1.4 due to changes in Swing. The best solution would be just to keep the jdk 1.3 alongside 1.4 but that's not really posible with windows, so now I have to change the app to work with 1.4 and then include(and install) jre1.4 and then hope that our customers don't have any applications that only work with 1.3. Oh what I would pay just to be able to include a version of swing with our application allowing us to run with both 1.3 and 1.4 using the same swing library no matter if the user were using 1.3 or 1.4.
It is correct that JSSE has been integrated into the JavaTM 2 SDK, Standard Edition, v 1.4 but with 1.3 and early versions it was an external module, so the author might just not have noticed they included it with 1.4. Which remind me: Does anyone know why jsse use >5 seconds on a 800Mhz pentium just to create an ssl connection to a webserver? This is really a big problem for us -((
I don't know if this memo is valid, but it really does sum up the problems with using java for client side applications.
Java vs Python (Score:3, Interesting)
My experience is that java is faster than Python, but that speed almost never matters for me.
Article proves Sun should have spun off JavaSoft (Score:3, Interesting)
Re:Perhaps you should read the letter b4 posting i (Score:3, Interesting)
Hrm. Looks like Solaris 9 still needs a little work. At least we can see that the PC implementations can get those pesky "hello, world" programs into something more reasonable - like only 5 megs of RAM...
But it's certainly not the language, nor the design, concepts, nor intent behind it... It must be the implementation. Heck, I'm sure any day now, there will be a JVM that runs even faster, even lighter than native code. Any day now...
Looks like bullshit (Score:2, Interesting)
Not that it doesn't contain a lot of truth - I just think it's a fake.
Re:What's the point? (Score:3, Interesting)
If you bothered reading the piece before clicking "Post a slaverng Java fanboi response", you';d notice the engineer is recommending Java is so bad at Sun it not be used BECAUSE THE JAVA ENGINEERING TEAM WILL NOT FIX IT. Because they regard features as more important than a stable API or bug-free runtime.
Re:Hypocrisy? (Score:3, Interesting)
$man "level 5 leader"
It is a term used by Jim Collins in his book 'Good to Great'.
What Collins did was to set up a bunch of objective standards for good-to-great companies based on their share price over two 15 year periods. Then he compared them with a bunch of other companies that were comparable in the 'good' phase but never managed the 'great' phase.
He noted that the good to great companies had a bunch of qualities in common. In particular the CEOs behaved in a particular way. Instead of using 'I' all the time they used the word 'we'. They did not spend their time in self promotion for the sake of it. One of them used the comparison 'I'm a plough horse, he [the competitor's CEO] was more of a show horse'.
The basic research for the book was done prior to the recent CEO perp-walks by the Enron, Worldcom, Haliburton, Harken etc. crowd. So now almost everyone is trying to be a level-5 type leader rather than a Jack Welch who is a 'level 4' - not quite as good.
Incidentally if you apply it to politics then Thatcher comes out as a level-4 leader rather than a level-5. Anyone who follows British politics will know the reason why, she failled to plan for succession. The Tory leaders who followed her have all been failures and the party poll numbers show the results.
Unfortunately the notable standout is the failure in the Whitehouse who is a level-2 leader if that. Bush meets none of Collin's leadership criteria. It is all do as I say, not do as I do. Prime example, you go off and fight a war, I dodged service in Vietnam by getting Daddy to pull strings, then went AWOL. Secondary examples you keep your treaty commitments, I will unilaterally break the test ban treaty, ignore the security council, withdraw from Kyoto and basically ignore any treaty I consider inconvenient.
Re:Can someone explain "The Java allure" to me? (Score:2, Interesting)
The thing is, CORBA is tricky for remote objects, whereas J2EE has provided a whole eco system in short timeescale to do this stuff - right from IDEs through to the J2EE servers themselves. And the best bit for the real world is that there is a high degree of OS and Architecture independance. Not total I'd agree, but enough to make people who were once locked into SNA networking etc. a lot happier about the future.
Sun: please stop the Java madness! (Score:3, Interesting)
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.
Re:Smells of a Fake (Score:4, Interesting)
No, scripting languages typically have significanlty more difficult memory management requirements. Memory managers in low-level languages are simple because the programmer does everything. Since Java lies somewhere between simple C/C++ and complex Perl/Python, why is its memory management slower and more complex than all the above?
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.
When everything is fixed in version 1.3.1, it does get called 1.3.2. You call it 1.4 when you add features. Refusing to release a 1.3.2 is the same as refusing to fix bugs.
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.
Then you either haven't been programming Java very long, or you don't do much in it. Sun documented the proper way to do GUI programming, date conversion, and a whole bunch of other things in Java 1.1, then deprecated it ALL in 1.2. Haven't you noticed that most Java 1.1 programs won't compile under Java 1.4 without massive deprecation warnings? Most of these programs were 100% legal java programs when written, following Sun's documentation to the letter.
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.
Go back and read his examples to see why Java is very bad in this resepct, even on today's hardware. It takes my Athlon 1800+/512MB machine 4 seconds to start a stupid command-line utility. Why? It has to reserve 26Mb of memory (and the classloader takes forever). The same program takes less than 1Mb in C and requires next to no time to start up.
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/
Because he works for Sun and uses the internal bug database? Did you READ this memo?
Re:Perhaps you should read the letter b4 posting i (Score:3, Interesting)
With every release, Sun breaks something that worked in an older version. Swing in 1.4 blows up all over the place where 1.3 worked fine. If the failures in the latest JRE don't affect you, then you can use it. The place I work for runs into this with every release we make. We have to pick one version and say we only support that because other versions have bugs. We also don't have the QA resources to make sure we run on every single version. We're not the only ones. BEA WebLogic still does not support JDK 1.4, even though it's been out for over a year and is approaching the second minor version update.
"Typical resident set requirements for Java2 programs include: Hello World 9M" Again, BS. I have a TINI board running that only has 8M of memory total, AND I have an old Handspring (8M) that has Sun's JDK and IBM's JDK and Java3D on it.
Just because there's a Java implementation that runs on a small platform doesn't mean the one that runs on Windows or Solaris isn't grossly overweight. IIRC, running something not a lot larger than Hello World on 1.4 for Windows takes about 12M. That's a stupid-big footprint and there's a feature request in-process to fix it.
Re:the Java Myth part Deux (Score:3, Interesting)
I got a tip from someone about some command line arguments which did wonders to speed up Java apps. Why did I have to hear about those as word of mouth, why aren't they the defaults? Why did I have to hunt for them unsuccesfully this last time I had to reinstall the JRE?
When I type in "java.sun.com" why do I not see an incredible collection of high power java apps which I can download that do all sorts of wonderful things? Getting Microsoft to bundle a JRE isn't going to change very much. Sun is the one who has got to convince end users to keep their JREs up to date and to do that they have to keep end users happy.
Sun employee: memo is on target (Score:5, Interesting)
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
Re:Not too surprised (Score:4, Interesting)
I would get worried about Java as a career yet though. I just recently switched workplaces as a J2EE architect. At least in my town (Jacksonville), and accorind to the recruiting firms I talked to, there is very little else going on except J2EE. I can definitely see Java being the COBOL: great now, but antiquated later.
More to the topic at hand, I don't see client side Java getting better anytime soon, because Sun already lost a lot on that side while gained a lot on the J2EE side. Future releases will be more geared towards long uptime high memory applications more than short small ones.