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!
This smells bad. Sun have been forcing the monopoly thing down microsofts throat for so long, and now there they are victim of themselves again.
What took them so long to come out with this? It seems to have stayed nicely hidden while they could cause damage to microsoft. Looks like they're a lot more relaxed now it's 'home turf'
'home run' indeed. They're now able to disassemble java like they wished to for a while it seems, but wanted to get most leverage out of it against a competitor
Commercialism stinks
Read the article poeple, what their saying is that the JRE on solrais has huge significant bugs that need fixing!!
people spend far more time chattering about java than using software written with it...
maybe because talking about is the only field where java and c/c++ have the same performances.
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 damned langauge will go one of two ways:
they'll fix it,
or it'll die (phase out, dehype, become far too slow and filled with awkward design mechanisms that it cannot survive any longer).
-P
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?
Microsoft departments have to use their own beta products. Its internally called "dog fooding."
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.
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.
It has problems ON SOLARIS. These engineers do not complain about Java being broken as a language. They have a big problem with implementation of the JRE on one platform. They mention nothing about the linux dist, or the win32 dist.
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.
Not that I'm suggesting they are wrong, I have no way of knowing either way, I just think that producing memos like this - and getting them leaked - is probably not the smartest way of getting the declared objective.
Admission: I use Java. It isn't perfect. It uses too much memory. It isn't hugely fast. But the applications work and the amount of debugging we have had to do is a tiny fraction of what I would have expected with C++. Its suitability for a given project depends on a whole host of factors not considered in the memo, and it would not surprise me if, for some internal Sun projects, it was inappropriate in its present stage of development.
Panurge has posted for the last time. Thanks for the positive moderations.
The extension mechanism works well, they should allow it to do it's job.
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.
It was a joke! When you give me that look it was a joke.
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.
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!
This memo looks like a turf war to me. Somebody is ARC needs to justify his job, and has decided he can do it be getting his hooks into Java.
The memo says that the JRE implementation on Solaris (not the implementation of SOLARIS itself)is a cause of many java problems, including
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
Sigura Non Grata
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:
Anyway, regardless of the JVM, applets are only applets.
I hate to sound trite, but the fact that you place so much importance on applets (they are, after all, the only example of the technology that you imply exists) leads me to believe you're not really versed in the current trends in Java. The simple fact is that no one use's applets anymore; certainly there is no new development going on in that area. Most Java applications are written for the J2EE platform.
Even at that, those who do wish to write the modern equivalient of applets use Java Web Start, which is much more robust and doesn't operate within the confines of a browser.
Did you see the entry for C#?
"The gun fires just fine, but your foot can't figure out what the bullets are and ignores them."
Quite amusing.
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
How come I've not seen any comments questioning the authenticity of this memo? All we've got is the word of some site that this memo actually came from inside Sun. Presumably, they had it leaked to them by an anonymous source. Now, lets think about this for a second. What "anonymous source" has lots to gain (potentially billions of dollars) by disgracing Java? What "anonymous source" has a history of lies, deciet, astroturfing, libel, and other shady or illegal practices?
I'm not saying that Java doesn't have problems. But still, it pays to take this information with a grain of salt until its source is proven. Which means until Sun officially says "this is true", as there's few (or no) independant tech news sources that don't get loads of advertising from the "anonymous source".
It looks like to me like their problem is with the specific Java VM on Solaris, and the Java team's unwillingness to fix JRE bugs as opposed to adding new features. Not with the Java language itself and not with Solaris itself.
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.
Ubi dubium, ibi libertas.
First off, this "memo" is the complete opposite of Sun's Java stance. They believe that Java should be used for everything from running enterprise applications on E10K's to apps on your PDA. I don't think that Java should be used everywhere, and I'm a big fan of the language.
Second, these might have been arguments against Java a couple years ago, but they simlply aren't true any more. For enterprise-level applications, Java outperforms Perl or someother scripting language on every front (scalability, preformance, maintanability, etc.).
Finally, these bugs don't even exist! I seached for the bug id's in Sun's bug database, and didn't get anything.
As usual, the Slashdot community has formed a collective knee-jerk reaction against any technology that isn't open source and Perl.
The memo was talking about how much memory the program takes when it is running. You are on the right track, the original poster was wrong. I haven't tested it myself, but the numbers in the memo seem about right with my experience. The reason a "hello world" program takes up 9M is not because the program is inefficient, it is because Java requires a JIT compiler and other crap be loaded and running with the program. The actual "hello world" code and data were probably only a few kilobytes (if even that). The compiler, gc, &etc took up the remaining 8.9M--not to mention a bunch of processing time.
Java is only free if your memory and cpu aren't worth anything. ;-)
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.
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.
Ahem ...
socket_accept()
socket_bind()
socket_listen()
Taken from User Contributed Notes on php.net (author diogo at michelangelo dot edu dot br )
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.
Less is more !
Hey, folks, calm down. This is a memo from a couple of developers with their hair on fire, writing a purposefully inflammatory internal memo to get attention.
(Which they have done. I wouldn't be surprised if they're having a rather painful meeting when word gets back in Sun that this got published externally.)
I used to be a Sun Java Architect and I worked on both internal and external projects on both Solaris and Windows. I posted a lot of bug reports myself, and got some of those "will not fix" replies.
What these guys are primarily complaining about is not that Java isn't good for some things, but that Sun developers have a perpetual problem that they're almost always the cobbler's children that go barefoot. As someone else mentioned, the Windows implementation of Java seems to get priority for most things -- although, as I recall, the advanced Hot Spot optimizer was available for Solaris first (makes sense, the x86 instruction set architecture is such a pig.)
But there is a second thing going on here that you might not undderstand, which is that ever since Scott began to push Java, the old C/C++ programmers have been scrounging for reasons to us C instead of Java. Sometimes tht's appropriate, but a lot more often the difficulties are the result of someone trying to write C in Java.
In fact, this memo describes several problems that are clearly just such problems: for example, the notion that a Java-based shell should fork a new JVM for each command line execution. This is the natural way to handle the problem in C; fork()/exec() was invented for this. But it isn't the appropriate idiom in Java for exactly the reason they describe -- it means starting a whole new JVM, which is expensive. (The appropriate idiom, by the way, is class-load by name and invoke a method.) As I understand it the 1.5 JVM will have a extension that will make it easy to create virtual address spaces within the JVM for running sub-programs, which is probably a response to the issue.
The most important thing the memo is pointing out really is a problem: the freakin' language and evironment changes every time some propellor-head gets a slick idea. I posted a couple of days ago complaining about just this in the case of the for(String s: c) idiom and a couple of other such things in 1.5. This, and the way things break between Solaris and Windows, and among minor version changes, really is a problem that makes developing large-scale, multi-version applications in Java difficult.
I like Java a lot, and I like to see that Sun realizes the biggest problems of Java. It gives me confidence that they will work on the mentiones issues and fix them.
The bad side of the memo is that it will certainly be misused for marketing purposes by the Java bashers.
Signature deleted by lameness filter.
PHP is "the one" for me!
Now with the gtk extensions it does a mighty fine job on the server or on the client!
It has the ease of text manipulation of Perl without all the nasty hacks in syntax. It's cross platform, free, and performance is good. (Probably better than Java, since my own testing indicates it's considerably faster than Python)
It makes a good, all-around scripting language for sysadmining, UI management, etc. and it even makes a good case for fast web development!
Among other things, a web server (yes, a replacement for Apache!) has been written in PHP!
I figure that with all the noise of "web services" this, and "cross platform" that, there's a good chance that PHP could be the "next big thing"...
Yeah, I use PHP an awful lot.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
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.
We do not believe these flaws are inherent in the Java platform but that they relate to difficulties in our Solaris implementation.
Also, many of the stated problems are slated to be fixed in Java 1.5...we'll see.
In the meantime, support gcj or the IBM implementations...on other platforms. ;-)
Another snippet:
We all agree that the Java language offers many advantages over the alternatives. We would generally prefer to deploy our applications in Java but the implementation provided for Solaris is inadequate to the task of producing supportable and reliable products.
Don't throw out the baby with the bathwater.
And of course, now that I read some of the replies, I see it may well be a hoax regardless. Sigh. (Disclaimer: I've never used Java on Solaris, only Linux and Windows.)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
This is the same site that posted the fake id memo. Is their record besides that one mostly spotless? It seems no one here is doubting whether or not this is real.
Quotes from the article that show you didn't read the letter before posting it:
"these issues are not inherent to Java"
"We do not believe these flaws are inherent in the Java platform"
"We all agree that the Java language offers many advantages over the alternatives."
"The customer must locate that release and install it." That, IMHO, is complete BS. I never keep anything but the most recent version installed, on Windows or Unix. The only issue I have ever seen like this was with JHDL from Brigham Young, which used "assert" that was added as a keyword (due to customer requests) in 1.4 -- and it still works if you tell it to compile as 1.3 (javac command-line option). I personally would not support an outdated version when a version with bug-fixes is available for free.
"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.
"Each of these examples is simple, but they demonstrate the general problem that people cannot program for a particular release of Java and expect that their programs will continue to run." Again, BS. I have been coding Java since IBM released JDK 1.0.2 for Win3.11.... I have never had this problem with ANY code I have written.
And their overall request? "We strongly recommend that management require Java to conform to the Software Development Framework ".
If you would have read the letter before posting it, you might have realized that what they were really complaining about was Solaris 7 and 8. They even point out that Solaris 9 is fixed. The pieces of the letter that suggested other languages was specific to the Solaris implementation, as my comments above prove that their statistics are not valid outside of Solaris.
So, Solaris pre-9 is buggy. Big deal, that has nothing to do with how fit Java is as a language.
Malachi
http://www.google.com/profiles/malachid
My experience is that java is faster than Python, but that speed almost never matters for me.
A) The comments are cowmix's, not the editors. And certianly not the moderators.
B) A five-page email detailling how something is inadequate seems to indicate that it should not be used. In fact, the phrase "That our Java implementation is perceived as inappropriate for many uses is supported by internal documents and policies." is pretty indicative that java is not (and hould not) be used for seriou sprojects.
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.
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...
Yeah, it's a fake. I work at Sun, and a quick LDAP search lets us know that Sun doesn't employ a Julian S. Taylor. Geez, I wish f'dcompany.com would check this stuff out before they post it. Actually, I wish /. would check this stuff out first...
-Jon
"In a 32-bit world, you're a 2-bit user. You've got your own newsgroup, alt.total.loser." -Weird Al
The typo in the parent post confused me at first (spelled correctly the first time, wrong the second). Furthermore, there does not appear to be a psyco package in Debian.
To clarify:
psyco is the name of the Python specializing compiler. The Psyco project homepage is:
http://sourceforge.net/projects/psyco/
pysco, on the other hand, is a group of python modules for composing music. More information about pysco is available here:
http://www.slinkp.com/code/#pysco
I could not find a package for either of these in Debian.
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.
On the server side it's because companies like the idea of component based development, where they can employ programmers to concentrate on building good reusable application level components, but get the benefit of transactional support that the J2EE containers provide.
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.
catch (ModDownException mde) {post.modUp("Interesting")}
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.
Slow...
For the last couple years, Java has been more than fast enough, if you know what you're doing. The clunky performance of the JVM is a thing of the past, and programmer skill is what matters now.
heavy-handed controls on the reference implementation
That's the point: there's a much clearer path for a programmer to follow. If you're not reinventing the wheel, the path is much better marked than it is for a C/C++ coder.
sub standard culture-enforced methods of doing everything from builds to deployment
"Sub standard" is your opinion, but again, that's the point: it's a much more restrictive environment that limits what can go wrong. With garbage-collection, you don't have fine-grained control over the memory lifespan of your structures, but you get automatic memory management. That's a tradeoff people are willing to make when the circumstances warrant/allow. Java vs. C/C++ is all about the tradeoffs you want/are willing to make.
This depends on the coder's skill and experience. Java can be a much faster development platform. C development is as fast only when the development environment has been restricted in the same way by choice of libraries/code style, etc.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
Is it legitimate? I first saw a pointer to this a couple of days ago
on fuckedcompany.com. That's hardly a ringing endorsement of
legitimacy. Even if it real, is it significant? Not clear.
It looks to me like mostly an attempt to get attention. I have to
admit, somewhat reluctantly, that I used have to write memos along
these lines when I worked for a company that ships a prominent
application server. The fact was that there were only two ways to get
attention focused on problems that would keep us from shipping our own
product on this app server: 1) Find the developer responsible and
persuade him to fix it or 2) Get one of our executives to yell at one
of their executives. Often the second approach was the only one that
had a chance of working and it required memos like this (complete with
specific bug numbers, sweeping generalizations about the support
structure, dire warnings about the future and so on). This is
corporate politics at its "finest." Quite the technique for building a
close working relationship, eh?
Some of the points about application-specific JVM version requirements
and footprint have merit (even if they're overstated, in my
experience), but generalizing this to "Sun does not eat its own dog
food" seems difficult to justify based on the limited examples shown
here. How much of Sun's software is actually written in Java, for
example? And if Java is such a problem, why has the app server market
been growing so quickly?
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.
47% of all statistics are made up on the spot.
Obviously if the domain is "internalmemos.com" it must be an internal memo.
Otherwise, they would have called it "internalmemohoaxes.com". Try using this thing called "logic."
Note that the definition of "optimization" is "making small changes to make something that runs ok run faster". Optimization implies that without it, the app would still be at least marginally acceptable. "Better is the enemy of good enough" is a similar quote.
Architectural and design decisions are not optimizations. With the wrong architecture, performance can be so slow as to be impossible to adequately optimize. There is no such thing as "premature design".
First, there aren't 1000 platforms. There are probably 10 that anyone would ever have to worry about at any given time.
Second, if you write it in C or C++, you get the benefit of native code which is just as "run anywhere" as a VM. The VMs are written in C++, right - which indicates that C is already there - who needs the VM?
Third, you're correct. If you absolutely *have* to use a vm, use python. At least get value from your language choice, not C++ in an uglier box.
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
Why Java sucks , written in 1997, but some points still hold true.
Swing widgets themselves work reasonably well and are fairly easy to extend. The problems with Swing and Java are in areas like window management, focus, native LAF, drag-and-drop, and desktop integration. And for many of those problems, there are no easy workarounds because they involve native code.
This is a power grab by an internal Sun committee. It's riddled with scaremongering and concocted reasons why the ARC should control Java. It's a sign of deep malaise within Sun.
Just so you know... I think the problems that you mention were fixed in Java 1.4... In fact, they were the major concerns of the release other than NIO and the obvious stuff. Also, non-SUN JRE's preform much better as well on the whole. IBM makes the best, but SUN caught up a lot on 1.4, and surpassed IBM in a select few cases. IBM now has a 1.4 JDK for Linux on xSeries(x86). It's only free as in beer, but it's worth toying with to get a feel of where Java is headed in the next few years.
I'm fairly sure this is a hoax memo, but even if it's not, it only talks about the implementation of Java on Solaris.
The main reason I like Java is that I won't have to do anything, and my programs will magically get faster, support 64bit processors and other architectures. Java has the potential to be faster than C. Java libraries/classes can have functions inlined at run-time. C has to be recompiled. Java can optimize for whatever processor it is running on. C has to be compiled for the least common denominator of hardware it will be running on. Java programs have an extensively tested standard API of functions to ensure backwards compatibility. In C you may have to recompile or change code whenever a new version of Windows rolls out. Java is a very well structured object oriented language compared to C or C++. Java SQL database drivers must adhere to strict SQL standards to be considered for different levels of JDBC compliance. I can write SQL that is garaunteed by the JDBC driver to work on a database, thus having true database independance. In C, each vendor implements a different subset of SQL in different ways such that you have to pick up a third party abstraction layer, or write your own, or target one database (ODBC doesn't work, even Access runs queries locally).
The only downsides to Java is: all java programs will use more memory than C programs... always! Java programs will take longer to start until a shared VM is implemented(is a JSR right now). Java will be slightly slower than C until Java has had about half as much time to develop compiler(JITC) technology that C has. Java will be slower at floating point until an API for fast system-dependant/non-IEEE floating point math is supported (This is why people claim, and are accurate to a degree, that Java isn't as fast as C at raw number crunching... This is probably the only reason as well).
Of those, the only problem that will always plague Java is large memory footprint. That is because it comes with it's own libraries and must do garbage collection.
It's appearant to anyone (like g4dget) that SUN sinks more time into the Windows JRE than anything else. The second biggest, as of 1.4, I would have to say is Linux/Mac. Solaris is the lowest on the list really. Most people that use Solaris use it for Oracle. The Java market has always been on Windows and IBM machines. IBM rolls their own, and they do a great job. Maybe they will release theirs a bit more free if their agreement with SUN will let them. I don't think they are allowed to discuss their contract with SUN because of the contract itself. At least, that's the rumor about the Java contracts that was on the net about 5 years ago.
Karma Clown
This section of the memo was, for me, the most interesting:-
In earlier Java releases there were useful APIs that weren't available in the core, such as XML/XSLT, JNDI, Swing, etc.. but for application developers like me, it was straight-forward enough to distribute these extensions with applications that needed them. Sun's policy of bloating the core with all these Java extensions is actually harmful to Java. For example, Sun's official explanation for putting logging facilities that were inferior to Apache's log4j was that there was a JDK 1.4 Merlin release deadline to meet. Same goes for the stunted XML API's in JDK 1.4. Why can't these extensions grow, evolve and mature outside the Java core? As long as they're easy enough to distribute, do they need to be part of one big release?
What the Sun engineers are complaining about is that a change in one of what could be hundreds of extensions breaks the entire platform. To try to prevent this, Sun have imposed 'draconian binary-compatibility rules' which are a sure way of prohibiting refactoring and major improvements, bottom line: Java bloats and innovation effectively stops.
Either Java needs to use it's own extension mechanism more consistently, or to create one that is more flexible/usable and more open to third-party code. How many times have you needed a particular version of xerces, xalan or log4j in the classpath? (or found out your customer has a different version that the one you built with, and this is the cause of that subtle and evasive bug)
It's not just the Solaris performance/memory aspects of Java that are a problem, it's the very way that the technology is distributed and evolves. I've had a lot of fun/success with Java and want it to continue getting better. Congratulations to the insightful engineers behind this memo.