Slashdot Log In
Even Sun Can't Use Java
Posted by
CmdrTaco
on Sun Feb 09, 2003 08:46 AM
from the frighteningly-honest dept.
from the frighteningly-honest dept.
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 discussion has been archived.
No new comments can be posted.
Even Sun Can't Use Java
|
Log In/Create an Account
| Top
| 833 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
|
2
(1)
|
2
It would be interesting to find... (Score:4, Funny)
(http://ii-0-ii.com/parodycheck)
Re:It would be interesting to find... (Score:5, Funny)
(Blah... blah... Mono... Free... chasing a moving wall in order to pound your head against it...)
Re:It would be interesting to find... (Score:5, Interesting)
It boggles the mind that after half a dozen years of Java, Sun has not yet moved their default desktop over to Java GUI apps. And Sun has missed lots of great opportunities popularizing Java by failing to deliver desktop apps and utilities that would motivate Windows, UNIX, Linux, and Mac users to download the JRE.
Re:It would be interesting to find... (Score:5, Funny)
How many times do you have to visit a web site that gives you 15 popup windows complaining about script errors in IE?
You do know that that's Javascript which is nothing to do with Java, right?
Who here hasn't had to download an older version of the JRE because you've found a program that doesn't work on the newer versions.
Yes, inter-version compatibility is a big problem, as mentioned in the Sun memo.
Yeah, it was cool back in the days before DHTML, Flash, and XML. But now it offers very little additional functionality.
Oh for chrissake! The memo is talking about large applications. As in, not java applets. Read the damn memo. And get a clue. "Java was cool back in the days before ... XML. But now it offers very little additional functionality"? What does that even mean? It sounds like you're just throwing buzzwords around. I suppose C offers little functionality over ASCII, and C# just isn't cool now we have WordPerfect and ISO9660?
InternalMemos is notorious for hoaxes (Score:5, Informative)
Re:InternalMemos is notorious for hoaxes (Score:5, Informative)
(http://kavlon.org/ | Last Journal: Friday March 21 2003, @02:10PM)
Since when are memos technically correct? You must work at a lot geekier place than I have. Not that I think InternalMemos isn't notorious for hoaxes.
I wouldn't hold out for Sun to switch from Java to Python either but I really wish they would. Java blows. Python is easier to develop (fewer required tools etc) and runs a lot better under both Linux and Windows. Python (with wxPython) produces nicer looking more functional gui programs to.
Hypocrisy? (Score:3, Insightful)
(Last Journal: Thursday February 13 2003, @10:38PM)
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
Re:Hypocrisy? (Score:4, Interesting)
(http://kisrael.com/)
I think the primary interest here is "server side Java", doing heavy lifting business applications. Currently Java/J2EE is in a competition with
This memo makes me a bit nervous. Right now, I'm a Java/Perl guy professionally, and this is horrendous publicity for Java, and could pontentially tarnish Unix as well, since Java is so popular for business apps there.
(Applets seem to have kind of fallen by the wayside, though they seem to show up in more places than you'd expect...I can't do applets at work, it pops up a message about the firewall config, and I see that dialog a heck of a lot.)
Re:Hypocrisy? (Score:4, Insightful)
Can you say, "hoax"? (Read the "memo")
Re:Hypocrisy? (Score:4, Insightful)
(Last Journal: Tuesday September 18, @11:59PM)
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.
Sun employee: memo is on target (Score:5, Interesting)
(http://www.school.net/)
I am a former Sun employee and I wrote these kinds of memos.
Specifically, I wrote that Java was unsuitable for Sun's own web development projects, and that this represented a serious problem in terms of missed opportunities to improve our software and for our public relations and marketing.
The memo may be a fake, but it's right on target. I especially agree with the problem of internal tech support for critical bug fixes.
I worked on several projects that were a nightmare due to subtle bugs in Java's HTML and XML classes. In each case, the bugs were easy to fix: a few lines of code, changing private methods to protected methods, etc.
The response from Sun support? "Will not fix."
So I had to rewrite the classes-- basically rederiving the entire Java HTML+XML parsing tree-- which stuck the customer using my custom code. Talk about a bad upgrade path!
There were many, many examples of this. As a result, I deployed many projects using Perl on Linux instead of Java on Solaris, and I wrote internal memos like the one in this article.
All that said, the Java engineers were some of the smartest, nicest people I've ever had the pleasure of working with. I have a lot of confidence in them, and each Java release gets substantially better and faster. The problem IMHO is not the engineers, but the corporate culture that misses opportunities to learn from employee projects.
The Sun engineers and internal developers can really do some amazing things, if McNealy and Zander could start prioritizing Java inside Sun, and start funding rapid-turnaround tech support for employee programmers.
Cheers,
Joel
Re:Hypocrisy? (Score:5, Informative)
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.
Applets? What year are you in? (Score:4, Informative)
(Last Journal: Friday May 21 2004, @12:42PM)
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 [sun.com], which is much more robust and doesn't operate within the confines of a browser.
Re:Hypocrisy? (Score:5, Insightful)
(http://dotfuturemanifesto.blogspot.com/)
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:Hypocrisy? (Score:5, Funny)
(http://www.susheeldaswani.com/)
Um, no.
First off, who knows if the note is even authentic.
Secondly, what will be MS's argument?:
"Judge, Sun feels they should improve their Java product. As you know, the law states that no company should be able to improve their products, unless they are us, and we can improve other people's products, but only for Windows. Thank you."
Not Java but the Solaris JRE (Score:5, Insightful)
Re:Not Java but the Solaris JRE (Score:5, Interesting)
(Last Journal: Monday February 13 2006, @07:11PM)
Desperate measure (Score:5, Insightful)
(Last Journal: Sunday February 16 2003, @02:39PM)
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.
Re:Not Java but the Solaris JRE (Score:5, Funny)
(Last Journal: Sunday November 05 2006, @05:31AM)
And communism doesn't suck, it's just all the implementations!
-jcr
Re:Not Java but the Solaris JRE (Score:5, Funny)
(http://www.geocities.com/bgtrio | Last Journal: Thursday April 24 2003, @10:32AM)
Smells of a Fake (Score:4, Interesting)
(http://www.rigidsoftware.com/ | Last Journal: Saturday September 24 2005, @11:58PM)
Anyone that compares a scripting languate (python) to a full programming language that also as a VM has no clue. a scripting language has minimal overhead memory requirements because it does not have much of a memory management job to do.
Complaining about 'will not fix' items on an older JRE is dumb as their must be SOME reason for the 1.4. If everything could have been fixed in 1.3.1, it would have been 1.3.2.
Further I personally was told not to rely on the "sun" classes as they change. The article writer suggest that each release of the JRE causes classes to be dropped and added. I have NEVER experienced this and its a violation of SUN's stated practice.
"4. It is not backward-compatible across minor releases." Then this fool goes and compares 1.3 to 1.4 or 1.1 to 1.2 as IF those are minor releases. (anyone that uses java knows the 3rd digit has been the minor one) The 2nd number has so far been treated majorly by Sun's releases and I would NEVER call 1.2 or 1.3 or 1.4 a minor release, they have years between them.
As for large footprints, I stopped complaining about even M$ abuse of memory after the price came down so much. Just go buy some more. Its a valid issue, but I wouldn't mark it as worth of writing a letter.
Finally I'd like to ask why none of his bug numbers appear in the Java BugDatabase on the javasoft website
http://developer.java.sun.com/developer/
I'm skeptical of this letters validity.
Re:Smells of a Fake (Score:5, Insightful)
(http://google.com/)
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"?
Re:Smells of a Fake (Score:5, Insightful)
(http://www.plone.org/ | Last Journal: Monday January 05 2004, @04:45PM)
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:Smells of a Fake (Score:5, Informative)
(http://slashdot.org/)
First, you make it sound like, in some sense, scripting languages are not as complete as "real" programming languages. And your comments about memory management make even less sense-- any language with OO features (and many without) are going to have to do dynamic allocation-- how else are object references going to be dealt with?-- and that means that they're going to have to deal with memory-management issues. And if you think that all scripts are like little baby shellscripts, you haven't been around much.
I've developed medium-sized apps in Python and in Perl (on the order of 50K lines of executable code), and much bigger apps in Java. Python is semantically rich enough, and in most instances fast enough, to do anything that Java can do, and almost always with shorter, more readable code. The same can be said for Perl (though it requires more discipline to achieve the readability), and probably also Ruby and Scheme. From a software engineering point of view, I'd be happiest coding the whole app in Jython (the Python variant that compiles down to Java bytecodes), then recoding the hotspots in Java, or in some even lower-level language. Developers, even smart ones, usually guess wrong about what to optimize, so deferring tuning until you observe the working system is usually a good idea. Exceptions would be embedded and hard-realtime systems. Almost every business app I've seen is neither of these.
This in no way eliminates the need to design your app before coding it, BTW, contrary to what some bozos who once read the blurb on the back of an XP how-to book might have you believe.
When I did a demo of one Python-based app that I developed, my client was willing to accept a performance hit for the sake of better maintainability. When I benched its performance on one content-mangement task, it clocked in at 100 times faster than its C++ predecessor. Now obviously, a very clever C++ crew could have done a lot better than that. But in the real world, everyone's in a hurry and don't always choose the cleanest implementation. And when language features are too low-level, developers waste a lot of time reinventing "infrastructure." In this instance, they not only reinvented, but did it much more poorly than the developers of Python did.
Re:Smells of a Fake (Score:4, Interesting)
No, scripting languages typically have significanlty more difficult memory management requirements. Memory managers in low-level languages are simple because the programmer does everything. Since Java lies somewhere between simple C/C++ and complex Perl/Python, why is its memory management slower and more complex than all the above?
Complaining about 'will not fix' items on an older JRE is dumb as their must be SOME reason for the 1.4. If everything could have been fixed in 1.3.1, it would have been 1.3.2.
When everything is fixed in version 1.3.1, it does get called 1.3.2. You call it 1.4 when you add features. Refusing to release a 1.3.2 is the same as refusing to fix bugs.
The article writer suggest that each release of the JRE causes classes to be dropped and added. I have NEVER experienced this and its a violation of SUN's stated practice.
Then you either haven't been programming Java very long, or you don't do much in it. Sun documented the proper way to do GUI programming, date conversion, and a whole bunch of other things in Java 1.1, then deprecated it ALL in 1.2. Haven't you noticed that most Java 1.1 programs won't compile under Java 1.4 without massive deprecation warnings? Most of these programs were 100% legal java programs when written, following Sun's documentation to the letter.
As for large footprints, I stopped complaining about even M$ abuse of memory after the price came down so much. Just go buy some more. Its a valid issue, but I wouldn't mark it as worth of writing a letter.
Go back and read his examples to see why Java is very bad in this resepct, even on today's hardware. It takes my Athlon 1800+/512MB machine 4 seconds to start a stupid command-line utility. Why? It has to reserve 26Mb of memory (and the classloader takes forever). The same program takes less than 1Mb in C and requires next to no time to start up.
Finally I'd like to ask why none of his bug numbers appear in the Java BugDatabase on the javasoft website
http://developer.java.sun.com/developer/
Because he works for Sun and uses the internal bug database? Did you READ this memo?
Re:Good this is being adressed (Score:5, Insightful)
(http://users.rcn.com/smallpond1/ | Last Journal: Wednesday April 30 2003, @11:25PM)
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.
Re:Addressed? Hehehehe (Score:4, Funny)
(http://www.ps2emu.com/ | Last Journal: Saturday July 05 2003, @05:18PM)
Now it's "write once, run away"
graspee
Not *really* big news, but interesting (Score:3, Insightful)
(Last Journal: Monday February 13 2006, @07:11PM)
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.
Not too surprised (Score:5, Interesting)
(http://www.solariscentral.org/)
Re:Not too surprised (Score:4, Interesting)
(http://slashdot.org/ | Last Journal: Tuesday December 16 2003, @05:30PM)
I would get worried about Java as a career yet though. I just recently switched workplaces as a J2EE architect. At least in my town (Jacksonville), and accorind to the recruiting firms I talked to, there is very little else going on except J2EE. I can definitely see Java being the COBOL: great now, but antiquated later.
More to the topic at hand, I don't see client side Java getting better anytime soon, because Sun already lost a lot on that side while gained a lot on the J2EE side. Future releases will be more geared towards long uptime high memory applications more than short small ones.
See what happens... (Score:3, Funny)
(Last Journal: Friday January 04 2002, @11:58PM)
Hand the implementation to Microsoft, they can fix the problems this has...
Re:... nothing new under the sun (Score:4, Interesting)
(Last Journal: Tuesday February 04 2003, @08:22PM)
Got the job.
Java is so much about a culture and not a technology that it's disgusting. And it's a pity too, because all the PRINCIPLES of Java (portability through the VM, objectification, etc.) are so good that Microsoft took them to build
Hell, I think Java is a great language. It concerns me that it takes seventeen steps to accomplish something as basic as opening a database connection, grabbing some results, and outputting them into an HTML stream (and seventeen may be generous). But, it's a very straightforward language, very teachable because it's so logical.
But too much of the culture is fluff. Why is it that Sun doesn't focus on point releases that improve performance but instead focuses on getin gthe newest buzzword, uh, "feature" out the door? Why did they invent something called Java2 which is, IIRC, just Java 1.3? Because they're more concerned about IMAGE than about getting their product - which is great in principle - in a usable state.
But let's talk substantively. I've developed large scale server-side applications in Java, C, C++, and - on the web-app side - PHP, Cold Fusion, and ASP.
The slowest of those was, almost without exception, Java. Java took the most coding to do a basic task, and Java was BY FAR the most difficult to package, deploy, and deliver to my customers. That's a real pity, because I was about 90% certain that our customer's architecture didn't really matter if we were playing with Java. Upgrading those old Dell NT servers to IBM? No problem. We'll just move the app over, and it should run without a hitch.
But, lord have mercy, it ran slowly.
To top it all off, here's some advice I received from a Java-guru at another company. I was griping about how slow Java was, and he said to me, "Oh, everybody knows it's slow. But why worry? Hardware's getting faster every day. True, 2ms is half the speed of 1ms, but who's gonna notice?"
I almost fell off my chair. It's that sort of laziness that makes my skin crawl.
Look, I love Java. I want it to succeed. It's a brilliant idea: an utterly cross-platform language whose apps run without regard to the hardware and OS under them.
But it's a seriously flawed masterpiece.
(The funny thing is, I was just going to write "Why was this modded troll? But then my post bloated... kinda like how you go to write "Hello World" in Java and... ok, ok, nevermind.)
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
From the article... (Score:5, Informative)
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.
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:From the article... (Score:4, Informative)
(http://severinghaus.org/)
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.
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.
Unfortunately, I am not surprised (Score:5, Interesting)
The memo agrees with me and lists the huge memory requirements as the number 2 problem (number 1 is that Java programs require the JVM to run).
Considering that compiling Java into a native executable would seriously improve its performance (and remove the JVM requirement), I wonder why the memo doesn't discuss that possibility?
Read the Article (Score:5, Informative)
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.
Java Implementation (Score:5, Interesting)
(http://slashdot.org/)
It's a hoax (Score:5, Informative)
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
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.
Political memos (Score:4, Informative)
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.
Where's the proof? (Score:5, Insightful)
(Last Journal: Saturday September 17 2005, @08:51PM)
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?
I question the validity (Score:5, Interesting)
(http://slashdot.org/ | Last Journal: Friday August 13 2004, @09:53PM)
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.
Re:I question the validity (Score:5, Interesting)
I have written complex GUIs, which actually overwrite the paint() methods of Components, and Swing is slow on Windows and Unix. Also, I've used Swing apps, and guess what, they're slow memory hogs too.
Inevitably someone proclaims that Swing runs fast if you program well enough. (I'm not referring to you but to Sun's party line.) BULLSHIT. It's slow. It trades memory for speed, and still isn't that speedy. Run Jext or Borland JBuilder and you'll see what I mean.
Now,
Re:I question the validity (Score:5, Interesting)
I have worked at Sun and this smells very real to me. I have a friend at Sun who wrote an application in his spare time (in Java) which was officially adopted for internal use - he spent a month working with the internal applications gestapo having it re-written from scratch "to official standards". I agree with much of what the document says. Writing a complex Java application means targeting a specific JRE version, it is not at all unusual for Sun software products to install the particular JRE which they were written against (look at SunMC and the SunRay server software) - it's easier to keep patched without breaking other things.
Until the Java developers use Solaris as their tier one development platform and API changes are controlled in the same was Solaris itself (PSARC) this will continue to be a problem.
Turf War (Score:3, Insightful)
Anonymous Inner Classes (Score:5, Interesting)
(http://www.babe-test.com/ | Last Journal: Wednesday September 17 2003, @11:59AM)
But what I've never needed to do with them is serialize them. Interesting.
Did you notice that of the 9 key bug/issues, 5 were AWT (GUI) related and 1 was Serializing Anonymous Inner classes.
Why would they bring those up, and then within a sentence or two, mention Python. From what I understand, Python is mainly used for server side scripting. I doubt anyone uses Python for serializing anonymous inner-classes!
The letter was put together hastily at best. It was an eclectic set of beefs.
The last sentence really sums it all up. It's politics to get some resources shifted in their favor for the next build:
Re:Anonymous Inner Classes (Score:5, Informative)
(Last Journal: Saturday August 18 2001, @11:04AM)
No, Python is used for everything that a general-purpose language is used for, except anything best done in C is stuffed into C extensions. The exceptions are of course the standard exceptions for C, which basically owns systems programming. (The need for fast, tight code in Python is done by embedding C; see the Numeric extension which provides many very fast number operations comparable to anything else, because the operations are in C.)
In general, Python has no need for anonymous inner-classes; anonymous inner-classes are a worthless hack in Java to provide things that should be provided through any number of other good mechanisms, and even then they only partially and frustratingly succeed. Don't take my word for it, take jwz's word for it [jwz.org] (do a find for "mind-blowing worthlessness of inner classes", for instance, though it comes up several times as he mentions the lack of several better solutions).
Inner classes, as implemented in Java, are an atrocious idea and I know of no other language, including specifically Python, that doesn't have at least one inherently superior mechanism for doing that stuff, and most have multiple. (Even Perl has closures!) Thus, they have no need for what Java means by 'anonymous inner classes'. (Inner classes can exist in Python, but they have so many more capabilities that it's not even close to comparable, and I only need them when I'm dynamically generating classes anyhow.)
On the one hand, I'd say have a look at some of these other languages and use them enough to understand the idiomatic uses of the capabilities in those languages. On the other hand, I don't suggest it, as you may find it very difficult to program in Java again after you are done. Java is not a language designed to empower the developer.
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".
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).
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?
This smells like a fake (Score:5, Interesting)
(http://www.headius.com | Last Journal: Tuesday February 11 2003, @02:49PM)
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.
"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.)
Is this real? (Score:3, Informative)
Perhaps you should read the letter b4 posting it. (Score:4, Informative)
(http://eoti.org/~malachi)
"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
Article proves Sun should have spun off JavaSoft (Score:3, Interesting)
(http://www.agilegraphics.com/)
THERE IS NO JULIAN S. TAYLOR @ SUN!!! (Score:3, Informative)
(Last Journal: Thursday January 10 2002, @04:30PM)
-Jon
Re:THERE IS NO JULIAN S. TAYLOR @ SUN!!! (Score:5, Informative)
(http://www.rsvpair.com/)
I found Julian here [auburn.edu] and here [google.com]
Re:THERE IS NO JULIAN S. TAYLOR @ SUN!!! (Score:4, Informative)
(Last Journal: Thursday January 10 2002, @04:30PM)
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.
Sun: please stop the Java madness! (Score:3, Interesting)
Examples: the SunScreen 3.2 commandline. Takes ages to load or do anything, especially viewing your firewall logs. Sun Managment Center: It does not perform. It becomes completely laughable when you try to display the screen on another Xserver. This is how Sun was demo-ing it at Lisa2001, and although the lead developers over there agreed that it didn't perform, they blamed this on Swing but had this scary religious fervor when it came to doing things in Java.
The new patch-managment tools from Sun? Nice idea, very flawed implementation. Sloooooow, and so buggy that we ditched it, prefering to keep our Suns up to date by hand.
Java installers are another fun item. Sun has a very nice packaging system, which makes it possible to jumpstart machines with identical software configurations etc. But more and more software becomes 'java installed'. It does not add any functionality apart from a badly drawn gui, but it breaks all the convenience of having one standard packaging tool for the os.
Please stop this madness.
Obligatory jwz reference (Score:3, Informative)
(Last Journal: Monday October 23 2006, @12:44PM)
Power Grab (Score:4, Insightful)
Re:Kiss and say goodbye to Java language!! (Score:5, Informative)
(http://theravensnest.org/ | Last Journal: Tuesday November 27, @07:07AM)
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 [ukuug.org] published at the UK Unix Users' Group last year. (And possibly read my reply [sucs.org] 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.
Re:Did CmdrTaco even read the memo? (Score:3, Insightful)
(http://www.rsvpair.com/)
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.