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."
Hypocrisy? (Score:3, Insightful)
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
Not Java but the Solaris JRE (Score:5, Insightful)
Good this is being adressed (Score:2, Insightful)
Not *really* big news, but interesting (Score:3, Insightful)
Customers and Field Engineers Are Noticing the Problem
"Customer said they have something like 450+ container servers and 80+ automator server for the Vitria system. So the estimation for the hardware RAM is around 9GB for USII machine and 14-15GB for the USIII machine."
Eep.
"Within Sun, Java is not viewed as a satisfactory language for the construction of commercial applications."
Ouch.
Re:Hypocrisy? (Score:2, Insightful)
Anyway, regardless of the JVM, applets are only applets. Its security model prevents it from doing anything useful than pretty animation and fancy UIs. But for fancy UIs, we have Flash, which is definitely faster and easier to program.
Sun's Internal Argument (Score:5, Insightful)
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
"viva la resistance" (Score:2, Insightful)
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).
What's the point? (Score:4, Insightful)
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.
Re:Not Java but the Solaris JRE (Score:2, Insightful)
Read the memo (Score:2, Insightful)
Re:Good this is being adressed (Score:5, Insightful)
Addressed! You must never have worked for a large corporation. The
memo was written out of frustration because the problem has not, is
not and will not be addressed by Sun out of their typical beaureacratic
inertia. Even worse now that Sun has had layoffs. There is little
glamor in fixing things. People who want to keep their jobs will
be the ones adding new features and new bugs and making the
problem worse.
---
Lady Mondegreen, dead at age 54.
J2SE is becoming bloated (Score:5, Insightful)
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.
Re:Not *really* big news, but interesting (Score:2, Insightful)
So they are running 530+ copies of the JVM?! That's a bit like running a copy of Apache for every web page on your site. Seems like a design issue to me.
Desperate measure (Score:5, Insightful)
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.
Where's the proof? (Score:5, Insightful)
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?
Re:Read the memo (Score:3, Insightful)
"Java has too large a footprint (both memory and disk image) and may not be installed on the customer's host."
And regarding if the Java itself is broken, they mention this, for example:
"Bug ID 4526853 describes a bug in Core Java which used to be an external module called JSSE."
I guess it depends how you interpret it, but it's written quite sloppily if they actually only talk about the Solaris JRE.
Turf War (Score:3, Insightful)
Hoax? Nothing verified (Score:4, Insightful)
Purported internal memo. There's nothing there that suggests it is genuine and a few things that suggest it isn't.
Authenticity? (Score:4, Insightful)
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".
Re:Hypocrisy? (Score:4, Insightful)
Can you say, "hoax"? (Read the "memo")
Re:Not Java but the Solaris JRE (Score:2, Insightful)
It seems like we didn't read the same memo. The backwards compatibility problems, versioning, etc were not intrinsic to Solaris. And anyone who programs Java on Windows notices bad performance there too.
It was a very diplomatic letter. Sun's comparative advantage does not lie with Windows, so I don't think it makes much sense for the memo's author to make a big deal of it.
Re:Not Java but the Solaris JRE (Score:2, Insightful)
HelloWorld on Win2K using Sun's 1.4 JRE (1.4.1_01) takes up 4856K - little over a half of the memory required to run a similar app on Solaris (according to the memo.) I'm not claiming that this is spectacular, but the situation on Windows doesn't seem to be nearly as bad as it appears to be on Solaris. (Doing a quick test, the situation on Linux appears to be the same as on Solaris.)
The memo even states that things aren't as bad on Windows:
"5. Customers and Field Engineers Are Noticing the Problem
Following is an excerpt from Kevin Tay's e-mail to three Java aliases regarding a customer installation of a third-party product written in Java called Vitria. We see typical very large RSS numbers compared to a WinNT implementation combined with increased resource usage from Solaris7 to Solaris8:"
Sure, the JRE could use some improvements (maybe more than some.) However, the breadth of Java's standard and third-party APIs, especially in the web app space, combined with ease of development make it worth the performance and memory disadvantages to some (apparently quite a few) organizations.
Disclaimer: I code Java at work on Win32 and play around with PHP and Python at home.
-Aaron
Re:Where's the proof? (Score:3, Insightful)
Pud has a good reputation. I mean, it could sound funny but if you think even NY Times has to quote fuckedcompany.com like f****company.com sometimes on market pages, it may give a clue.
Editors, do some editing, please! (Score:3, Insightful)
This is a great example of spreading misinformation, starting in the headline and continuing to quote someone who gives a completely wrong summary of the memo. A memo which on its surface looks like a hoax (but may not be).
A correct summary to this memo would be: Sun is having problems with its Java implementation on the Solaris platform (it is emphasized in the memo that the problems are not inherent in Java) and also that some problems stem from different versions of Java (have you ever had problems changing g++ versions? Probably, only in Java 'going native' is done on the client machine and not on the developer's).
Re:Hypocrisy? (Score:5, Insightful)
For server-side apps, it makes no difference whether Microsoft bundles the JRE or not--anybody putting together a bunch of servers is going to install the latest JRE directly from Sun anyway.
In fact, while Java is a decent language for server-side development (and that's pretty much the only thing it's really good at), it's ironic that its cross-platform features in particular are largely irrelevant there: for many other reasons, any reasonable place is going to have a homogeneous server environment for individual web apps, and re-compiling for that server environment is a tiny part of deployment.
So, something like GNU gcj, which requires recompilation for each target platform, may well be the better choice than Sun's bloated JRE: while you don't get universal byte code deployment, which you don't need, gcj binaries start up much faster and consume less resources, which may be more important on your server.
Re:Hypocrisy? (Score:5, Insightful)
The note is certain to be used by Microsoft in their appeal against the Java injunction.
In particular the points about Java code being tied to a particular runtime completely negates Sun's claims about the need to distribute in the O/S base. Clearly that is not going to help much since Sun have no clue about dependency management.
Consider the following thought experiment. Microsoft distribute 30Mb of Java 1.3 with XP. Then Sun upgrade to 1.4, what does Microsoft do? Do they distribute 1.4 on the new O/S versions only, add it to the current release of XP or put it on instant update. None of these work. The instant update option will break existing java applets on the system. Mixed versions of java will mean that consumers buying a Java based progam will not be able to rely on the release number of XP to decide whether the program works on their machine. Waiting till the next O/S version is released will result in a lawsuit from sun.
The note shows clear similarities to the early articles on C# explaining the difference in approach between Java and dotNet. If the Java lobby was not so convinced that Java was the end of program language design they would have realised their significance.
To give one example, the version incompatibility problem is known to Windows developers as 'DLLHell'.
My company uses Java for a lot of projects. I would not be suprised however if we didn't end up on .NET server with the applications compiled down to native code through J# and IL.
Unfortunately Sun don't have a level 5 leader in charge. They have an egotistical idiot who is concentrated like a laser on another companies business instead of his own.Antics like those of McNeally and Ellison play well in the press but measured by the success of the companies stock price leaders like Jack Welch or Lee Iaccoca don't do as well as their PR would have it. Iaccoca may have saved Chrysler (it might also have been the government loans) but once he started concentrating his energies on being a folk hero Chrysler's performance went back down the tubes. Similarly Jack Welch's performance does not look that hot if you look at the growth in GE earnings rather than the stock price - which is certain to shrink as GE returns to its old P/E multiple.
One of the things a level 5 leader does is to encourage comment. The memo only says what others outside Sun have been saying for eight years.
My take on the Sun/Microsoft Java war is based on a lot of time working in standards groups with both groups of engineers. I think that the Microsoft engineers thought they could improve Java and got frustrated because the Sun engineers behaved - well like Microsoft engineers sometimes do.
Of course this will all be rationalised away. Of course it was all the fault of the Redmond club's evil schemes. Nobody outside Sun has any ideas of any value and Sun's JCM is genuinely open and not a proprietary farce.
Re:From the article... (Score:5, Insightful)
- Jython [jython.org] is a Python scripting engine for Java. There, now you can use Python within the JVM! <sarcasm>Get the worst of both worlds!</sarcasm\>
- Rhino [mozilla.org] is a Javascript engine for Java.
- Jacl [sourceforge.net] is a TCL engine for Java.
- Bean Sripting Framework [ibm.com] is a generic wrapper for including scripting languages within your application. It's from IBM, and is intended to abstract away the implementation of the scripting language. It supports Jython, Jacl, and Rhino now. It seems like I remember IBM releasing something for REXX as well.
My point here is that saying that Java doesn't include an interpreter is a downfall to Java is like saying that Perl not having a JVM is Perl's downfall. It's not their design goal. Java is a bytecode-interpreted language, not an interpreter. If you want an interpreter you can easily add one. And many are available.Performance isn't great, but reports have indicated that Jython is about 75% of the performance (near the end of the article...search for the word "performance") [oreilly.com] of CPython. It's slower than Java code of the same type. But, hey, if you wanted speed you wouldn't be using interpreted code (or byte-code interpreted code, for that matter), right?
Re:Smells of a Fake (Score:5, Insightful)
I don't see how that makes any sense. Python also has bytecode and a VM, and it does the same job in less memory with equivalent or better performence. It's object-oriented and performs garbage collection, as does java. What do you mean, "it does not have much of a memory management job to do"?
But there is still GCJ (Score:4, Insightful)
They are not there yet( AWT not yet complete, for instance), but it looks like they will be.
BTW: can Java specs and API be reproduced legally without SUN permission?
Re:Not too surprised (Score:2, Insightful)
Re:Hypocrisy? (Score:3, Insightful)
"On nearly every system I've used Sun's Java on, the Microsoft has taken up less ram, run faster, crashed less often, and basically been a smaller pain in the ass. There will be people who will scream that Microsoft has sabotaged Sun, but I don't think it has anything to do with that. And even if it does, at this point forcing end users to use Sun's Java is just going to deter people from wanting to use it at all."
Erm, the JVM you use is roughly 3-4 years old. Its 1.0 , while Sun is serving 2.0 for 1-2 years.
So, its like running Quake 1 on a machine and bitching about how slow quake 3 is, compared to quake 1.
Story Teaser More Buggy Than "Java" (Score:1, Insightful)
It turns out CmdrTaco doesn't eat his own dog food, or read the posted articles...
"Specifically, this internal memo from Sun strongly suggests that Java should not be used for Sun's internal projects."
They are not talking about Java per se, but about the JRE implementation on Solaris specifically, as anyone who even read the first four paragraphs would notice. I quote:
"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 [...]"
"More interesting still, they go on to state which other languages fullfil Java's goals better than Java does itself.
They use several Java and non-Java JVMs on various platforms for comparing memory footprints. All of the non-Java languages mentioned in the memo address a different goal set and "target market" from Java.
"Finally, the memo states Sun's own Solaris is the cause of many of Java's woes."
Aargh. Solaris is fine, it's about the JRE implementation on Solaris that they complain. Read the article, maybe?
"Yikes."
Four out of four sentences in the summary substantially wrong: FUD, FUD, FUD, FUD.
"Yikes" indeed.
Good for Java (Score:2, Insightful)
The bad side of the memo is that it will certainly be misused for marketing purposes by the Java bashers.
Re:From the article... (Score:5, Insightful)
I did a little benchmarking recently, and I can confirm that for typical algorithmic benchmarks (not heavily library or IO oriented) Python is more than 100 times slower than C/C++. There's a Python "specializing compiler" called Psyco that produces significant speedup, running my little fibonacci test around half the speed of C, very impressive.
Java on the other hand has had huge amounts of effort and money put into making it run faster, and to my surprise, I found it now runs my fibonacci benchmark faster than gcc-compiled C. Overall, Java performance has improved from horrible to tolerable. Programs are still taking a long time to start, even on a beefy machine, but to be fair, I've seen some long startup times on some C++ programs as well.
Python really beats Java in startup time, with the result that Python gets used here and Java doesn't.
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.
I see Pysco has made it into Debian Sid, this is a good sign.
Re:Hypocrisy? (Score:4, Insightful)
If the memo is real, then it's being kept in a very small group.
If it's fake, they did a good job with the language and examples.
Re:Hypocrisy? (Score:3, Insightful)
Can you say "duh"? As if even strong engineers could actually keep their jobs after telling everyone that Bill Joy's (yes, I know Bill didn't write it, but he sponsored it) baby is not just ugly, but hideously deformed? Keep it small, build support, when you have some safety in numbers, THEN come forward to a wider audience. Seems eminently politically practical.
Re:Not Java but the Solaris JRE (Score:3, Insightful)
Or Else!
Like, say Disney, AOL, Amazon and their lovely patents, etc. Not to mention the accounting bs that goes on; you can't convince me that Enron et. al. were just a couple of bad apples. They just had the misfortune to be poster children to let the rest of the corporate world know they better shape up enough to squeak by in the short run.
Re:Smells of a Fake (Score:1, Insightful)
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.
There's a difference between postponing a bug to a later release and classifying it as "will not fix". "Will not fix" implies that it will never be fixed.
Further I personally was told not to rely on the "sun" classes as they change.
True, [sun.com] but this has nothing to do with the linked atricle.
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.
No, what he actually says is that minor releases make non-backwards-compatible changes. While removing a class would be one example of this, there are more sublte changes that can break programs. The example they give is "In JDK 1.1 Class.fields() returns only public variables. In 1.2, protected and private variables are returned." This would break applications that use that method.
"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)
Not true. The first digit is the major number, the second is the minor, the third is the patch. According to Sun's own compatibility guidelines [sun.com], patch releases should not break compatibility at all. Minor releases should be compatible with old applications, and major releases (e.g. if Sun ever makes a JDK 2.0.0) don't have to be compatible at all. However, Sun break these rules, and there are long [sun.com] lists [sun.com] of incompatibilities [sun.com] between old apps and new Java versions. They usually suggest ways to fix the applications that don't break compatibility with old Java VMs, but that doesn't help vendors who have already shipped applications.
This is one of the reasons why Java applications have to be tested on every VM they may need to run on - not just every brand of VM, but every version and platform too. "Write once, run everywhere" is a nice marketing myth.
Re:Smells of a Fake (Score:2, Insightful)
Re:Unfortunately, I am not surprised (Score:3, Insightful)
Uhm... The JVM is a library, like libm is a library. Removing the JVM is like removing lib libgnome*. If you want to run program that use the features of gnome, you have to install the libraries. If you want to use the features of the JVM, it needs to be installed. If you want those features in another language, you'd need to install some other libraries (gc, gui, etc.), so it should be considered unreasonable.
Would it be better to link the apps statically?
Joe
Re:Hypocrisy? (Score:3, Insightful)
We will soon find out. However Microsoft will certainly get the ability to subpoena etc. regardless of whether it is eventually proved to be a fraud.
Judge, Sun feels they should improve their Java product
No, that would be Sun like Microsoft recognises that Java is broken and needs fixing. Furthermore it recognises that the monolithic architecture of the JVM makes it seriously broken.
If Java was not a 30Mb lump it would not need to be deployed with the O/S. It would be possible to download the support libraries required together with the code. It would be possible to download the versions of the libraries that the code was compiled against - exactly what dotNET does.
Of course this would also mean that the distinction Sun has attempted to enforce between Sun approved modules and other modules would go away. It would be possible to develop a version of dotNET that ran J2EE programs optimised for the native processor.
Sun's legal manipulations have been aimed at forcing Microsoft to support a platform while denying Microsoft and the rest of the community any say in the development of that platform. In every other standards process the vendors always reserve the right to not support the outcome if they don't like it. So there is a compromise between the positions of the parties, usually one that is aligned to the interests of the users. In the case of Java Sun has opposed any changes by Microsoft and in fact any other party that it belives are counter to Sun's interests
I am not a Microsoft employee but I would be happy to testify for them.
"Even Sun Can't Use Java" - sure (Score:3, Insightful)
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.)
Re:Did CmdrTaco even read the memo? (Score:3, Insightful)
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.
Can someone explain "The Java allure" to me? (Score:1, Insightful)
I've disliked Java since I first met it. What's the attraction, beyond the billions that Sun has poured into marketing it?
I've been called in as a consultant on three different jobs in the last year that wanted to know if I could impliment a project in java. I said "Sure, but why?", and every time, they stared at me like I was swearing in church. But no one could explain why. And they all took hours to convince that a C implementation was going to be faster, cheaper to develop, and use less resources, both development and runtime.
Slow, with heavy-handed controls on the reference implementation, non-native binaries, and sub standard culture-enforced methods of doing everything from builds to deployment... What's the draw?
Re:Don't worry... (Score:2, Insightful)
Huh!? Which of the following key points of the memo are specific to Solaris, again?
1. The [Java] support model seems flawed
2. The JRE is very large
3. Extensions do not support modularity
4. [Java] is not backward-compatible across minor releases.
Re:Smells of a Fake (Score:1, Insightful)
Python provides the same type of portability as Java in a different way. My Python code can run anywhere there is a python executable(barring api changes from 1.X to 2.X).
And Python does actually generate bytecode. If you have ever used modules before you would know that the first time a module gets run it generates a bytecode file). I think that is smooth, it means that the first time you run it... it takes a little while to startup, but after that it speeds its self up.
Sure the GC is a big difference, but it inspired Java programmers to write sloppy code. I have seen this in the workplace. Garbage collection was suppose to prevent a bunch of bugs by keeping track of those lost pointers:-), but this trick is overcome by sloppy code(ie lets make a Vector with 50,000 elements, when we only need 3).
Eventhough the entire article should be modded as flamebait(look at what it did for Java vs Python). I think it is very unfair to say Python is not a worthy comparision. I have an idea lets compare it to C++ and see how it does:-P
Java FUD (Score:4, Insightful)
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.
Re:Not too surprised (Score:3, Insightful)
Time to change that while you still can. You really shouldn't bet your career on any language. Instead, learn the essentials that transcend language bounderies: algorithms, OO design, etc. Not only will that make you a better C#, Smalltalk, Python, etc. programmer, but it will make you a better Java programmer. That's the paradox about programming languages: the truly good Java programmers aren't really bound to Java at all.
Re:Can someone explain "The Java allure" to me? (Score:3, Insightful)
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.
I've got my doubts about this memo as well... (Score:2, Insightful)
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?
Re:Smells of a Fake (Score:5, Insightful)
I would just add two states.
If you have to run handreds of calculations on an array with millions of records then neither Java or Python are good - you better do it in some database system, b/c you need just memory management (which is good today in both Python and Java, Python's results are just more compact) - in that case you'll need data management and thus you need DBMS.
But if your calculations (even simple, like Hello+World) are from separate OS processes, then Java is out of picture. As many people noticed, startup time of JVM is long and class loading is very slow. Python is still ok. Although my tests show TCL has the best performance for such class of tests. Among scripting languages - there are resons to write fork-based listeners on C.
Re:Why? (Score:3, Insightful)
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".
Re:Applets? What year are you in? (Score:3, Insightful)
Legally, Microsoft's goals for the product should've been the same as Sun's. They signed a contract stating they would ship "Java (tm)" with Windows. The trademark on "Java" belongs to Sun. Therefore they get to decide what Java is and isn't.
Adding new, incompatible features is inconsistent with what Sun had defined Java to be. Therefore Microsoft violated a contract, and the court is making them pay for it. Rather than trying to come up with a dollar value for Sun's loss, they're looking about simply enforcing the original terms.
This case is a fairly "simple" matter of contract law, not world-shaking antitrust violation. (Sun lawyers like to suggest monopoly abuse as a way to angle for more damages, but that's not the core of the complaint). As a contract matter, the court must aim for a solution that is fair for Sun, not "good for software users everywhere" (as was suggested far up this thread [slashdot.org]).
Re:p-code (Score:3, Insightful)
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.
Re:Java Implementation (Score:2, Insightful)
Basically, they can, at best, hope to assymptotically approach the performance of traditional compiled code, so they will always be worse in performance, all other things being equal.
Furthermore the technique by which VMs get fast is cheating the question... that is, it's to optimize bottleneck operations by coding them in a regular compiled language.
Example: years back I worked in SCI, Sierra-Online's language for making the old interactive fiction games, like Space Quest. It ran pretty fast even though it did complex (for the time) graphical applications. Well, this was, of course, because the graphical operations were optimized. You feel like you are programming this graphical operation in SCI, but the reality is that the intense part is executed in sizeable chunks of C code. Essentially you just inform the underlying C/C++ (etc.) program of what you the VM based program want, and it's handed off to a program that can actually handle the work.
So as a comparitive matter, yes, VM do always have to be pigs. There are many things SCI was still a pig at, of course, things it wasn't optimized for. That's the thing. VMs can be good, and not-piggy when they are special purpose languages, when the problems they all have can be solved by proper understanding of a specific problem frame that they intended to work within.
Java Servlets, for example, is an idiom in which use of Java is efficient, and an good argument can be had for all of Java's benefits, even WORA. You keep a VM up, you send applets to it.
In fact, there are a lot of distributed computing environments, which central servers dole out java code and use them as a plug-in language, in which Java will likely survive as by far the best solution.
Stand-alone applications and servers? I'm not convinced.
Re:Unfortunately, I am not surprised (Score:3, Insightful)
People often say this, without realizing that in 1996 there was a native code compiler by Assymetrix (part of SuperCede for Java) which didn't do well in the market dispite being the only native compiler for Java. Currently there is gcj, which I don't know of any projects that use it, but I think may have a subset of the Java API.
For whatever reason, people say they want native compilation, but it's never really proven out as a need.
I think a more significant speed improvement in Java would be to remove the += operator for Strings. You wouldn't believe how badly one of those in a loop can tank an app's performance.
Power Grab (Score:4, Insightful)
'Extensions do not support modularity' (Score:2, Insightful)
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.