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."
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!!
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
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.
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 was especially interested in the part of the memo that talked about extensions being rolled into the main product. But, apart from backwards compatibility, I think it just makes learning the language more difficult.
I learned the language back in 1.3, and I'm amazed at how much more has been added to the 1.4 release. Sifting through the javadocs has become a bit more of a pain, but nothing someone already familiar with the language can't handle.
My concern is people who are learning the language. I think the API is becoming more and more overwhelming to future Java developers. Look how much fatter O'Reilly's Learning Java book has become!
A smaller J2SE with standard extensions to be downloaded as necessary makes better conceptual sense.
quiquid id est, timeo puellas et oscula dantes.
Reads to me like a memo that has intentionally leaked out into the open, trying to force Sun Management to act. Software Development Dept is clearly unhappy with the Solaris implementation of JRE and therefore stops all use of it, until is has been fixed. While the Java Dept does not seem to have too much hurry to do that (majority of cases closed - "will not fix".
What would you do in your own line organization, when you are the boss of one department and the boss of the other department just gives you the finger? And your superior is unable/unwilling to solve the conflict? You write a flaming mail to your superior's superior, threaten to withdraw any support for the platform your company is famous for and leak the memo into the open to get public support. This, of course, has to be done nicely so that no-one can blame you directly for it.
Excellence: Moderate (mostly affected by comments on your karma)
How do we know this is even a real internal memo? I mean, this is comming froma site *named* internalmemos.com. Come on! There's a submission form. I could just send any old thing in if I wanted. The only difficult part is making it look convincing. That only takes a few hours of effort.
Anyone that has an axe to grind with Sun could have sent this in. That could be some big company or (far more realistic) some random slob that just wants to be mean.
Or it could be real. But who cares? As the Score 5 AC pointed out, this is about bugs in the JRE on Solrais, not necessarily about Java in general.
Does anyone on slashdot remember what FUD is?
Furry cows moo and decompress.
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.
Purported internal memo. There's nothing there that suggests it is genuine and a few things that suggest it isn't.
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".
- Jython 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 is a Javascript engine for Java.
- Jacl is a TCL engine for Java.
- Bean Sripting Framework 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") 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?
--Be human.
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.
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"?
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
"It turns out that Sun does not eat its own dog food."
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.
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.
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.
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.
Have you got your LWN subscription yet?
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, 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, 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 lists of incompatibilities 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.
What he means is: "I don't know anything about Python other than it doesn't have a separate compile phase. That must make it less of a programming language. It doesn't matter if you can write programs in it, doing anything you could in Java. It only matters if you can compile it into something other than the text file you write. If you can do that, it's a full programming language, and we all know those take more resources than mere scripting languages."
--
Promoting critical thinking since 1994.
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
Joe Batt Solid Design
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
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'm one of those people that hasn't bought into the hype yet... Someone try to sell me.
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?
It sounds like what's happening here is that Sun's Java people, realizing how many more people are using Java on Linux and Windows, aren't putting as much effort into support for Solaris.
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.
I think Python is a good example. Consider this. Startup times for Java are suppose to be improved by compiling into bytecode and using that as the executable. I mean, they wanted platform dependent code, but they already had one(The English Language).
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
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.
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?
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.
Less is more !
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".
By product developer, do you mean Microsoft making their J++ environment, or J.Random programmer making a corporate data-entry form? The latter is dependent on the former, as the ability of random "Java" programmers to create platform-specific software was enabled by incompatible features inserted by Microsoft.
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).
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.
they do! here is why.
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.
-pyrrho
Considering that compiling Java into a native executable would seriously improve its performance
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.
-no broken link
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.
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.