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."
It would be interesting to find... (Score:4, Funny)
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)
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)
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: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:Hypocrisy? (Score:5, Funny)
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."
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.
Re:Hypocrisy? (Score:3, Interesting)
$man "level 5 leader"
It is a term used by Jim Collins in his book 'Good to Great'.
What Collins did was to set up a bunch of objective standards for good-to-great companies based on their share price over two 15 year periods. Then he compared them with a bunch of other companies that were comparable in the 'good' phase but never managed the 'great' phase.
He noted that the good to great companies had a bunch of qualities in common. In particular the CEOs behaved in a particular way. Instead of using 'I' all the time they used the word 'we'. They did not spend their time in self promotion for the sake of it. One of them used the comparison 'I'm a plough horse, he [the competitor's CEO] was more of a show horse'.
The basic research for the book was done prior to the recent CEO perp-walks by the Enron, Worldcom, Haliburton, Harken etc. crowd. So now almost everyone is trying to be a level-5 type leader rather than a Jack Welch who is a 'level 4' - not quite as good.
Incidentally if you apply it to politics then Thatcher comes out as a level-4 leader rather than a level-5. Anyone who follows British politics will know the reason why, she failled to plan for succession. The Tory leaders who followed her have all been failures and the party poll numbers show the results.
Unfortunately the notable standout is the failure in the Whitehouse who is a level-2 leader if that. Bush meets none of Collin's leadership criteria. It is all do as I say, not do as I do. Prime example, you go off and fight a war, I dodged service in Vietnam by getting Daddy to pull strings, then went AWOL. Secondary examples you keep your treaty commitments, I will unilaterally break the test ban treaty, ignore the security council, withdraw from Kyoto and basically ignore any treaty I consider inconvenient.
Re:Hypocrisy? (Score:3, Interesting)
From their actions, it is clear they realize the future is in Windows and Linux. Not Solaris.
The evidence is their support of JRE on Solaris.
Re:Hypocrisy? (Score:4, Interesting)
I think the primary interest here is "server side Java", doing heavy lifting business applications. Currently Java/J2EE is in a competition with
This memo makes me a bit nervous. Right now, I'm a Java/Perl guy professionally, and this is horrendous publicity for Java, and could pontentially tarnish Unix as well, since Java is so popular for business apps there.
(Applets seem to have kind of fallen by the wayside, though they seem to show up in more places than you'd expect...I can't do applets at work, it pops up a message about the firewall config, and I see that dialog a heck of a lot.)
Re:Hypocrisy? (Score:4, Insightful)
Can you say, "hoax"? (Read the "memo")
Re:Hypocrisy? (Score:5, Informative)
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.
Sun employee: memo is on target (Score:5, Interesting)
I am a former Sun employee and I wrote these kinds of memos.
Specifically, I wrote that Java was unsuitable for Sun's own web development projects, and that this represented a serious problem in terms of missed opportunities to improve our software and for our public relations and marketing.
The memo may be a fake, but it's right on target. I especially agree with the problem of internal tech support for critical bug fixes.
I worked on several projects that were a nightmare due to subtle bugs in Java's HTML and XML classes. In each case, the bugs were easy to fix: a few lines of code, changing private methods to protected methods, etc.
The response from Sun support? "Will not fix."
So I had to rewrite the classes-- basically rederiving the entire Java HTML+XML parsing tree-- which stuck the customer using my custom code. Talk about a bad upgrade path!
There were many, many examples of this. As a result, I deployed many projects using Perl on Linux instead of Java on Solaris, and I wrote internal memos like the one in this article.
All that said, the Java engineers were some of the smartest, nicest people I've ever had the pleasure of working with. I have a lot of confidence in them, and each Java release gets substantially better and faster. The problem IMHO is not the engineers, but the corporate culture that misses opportunities to learn from employee projects.
The Sun engineers and internal developers can really do some amazing things, if McNealy and Zander could start prioritizing Java inside Sun, and start funding rapid-turnaround tech support for employee programmers.
Cheers,
Joel
Re: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: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:I also have experience (Score:3, Informative)
Swing widgets themselves work reasonably well and are fairly easy to extend. The problems with Swing and Java are in areas like window management, focus, native LAF, drag-and-drop, and desktop integration. And for many of those problems, there are no easy workarounds because they involve native code.
Applets? What year are you in? (Score:4, Informative)
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: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: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.
Not Java but the Solaris JRE (Score:5, Insightful)
Re:Not Java but the Solaris JRE (Score:5, Interesting)
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.
Comment removed (Score:5, Funny)
Re:Not Java but the Solaris JRE (Score:5, Funny)
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.
Smells of a Fake (Score:4, Interesting)
Anyone that compares a scripting languate (python) to a full programming language that also as a VM has no clue. a scripting language has minimal overhead memory requirements because it does not have much of a memory management job to do.
Complaining about 'will not fix' items on an older JRE is dumb as their must be SOME reason for the 1.4. If everything could have been fixed in 1.3.1, it would have been 1.3.2.
Further I personally was told not to rely on the "sun" classes as they change. The article writer suggest that each release of the JRE causes classes to be dropped and added. I have NEVER experienced this and its a violation of SUN's stated practice.
"4. It is not backward-compatible across minor releases." Then this fool goes and compares 1.3 to 1.4 or 1.1 to 1.2 as IF those are minor releases. (anyone that uses java knows the 3rd digit has been the minor one) The 2nd number has so far been treated majorly by Sun's releases and I would NEVER call 1.2 or 1.3 or 1.4 a minor release, they have years between them.
As for large footprints, I stopped complaining about even M$ abuse of memory after the price came down so much. Just go buy some more. Its a valid issue, but I wouldn't mark it as worth of writing a letter.
Finally I'd like to ask why none of his bug numbers appear in the Java BugDatabase on the javasoft website
http://developer.java.sun.com/developer/
I'm skeptical of this letters validity.
Re: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"?
Re:Smells of a Fake (Score:3, Informative)
It still uses RC to immediately finalize objects but will collect cyclical garbage as well when it periodically runs.
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:Smells of a Fake (Score:5, Informative)
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:all non-Windows JREs (Score:3, Informative)
I'm fairly sure this is a hoax memo, but even if it's not, it only talks about the implementation of Java on Solaris.
The main reason I like Java is that I won't have to do anything, and my programs will magically get faster, support 64bit processors and other architectures. Java has the potential to be faster than C. Java libraries/classes can have functions inlined at run-time. C has to be recompiled. Java can optimize for whatever processor it is running on. C has to be compiled for the least common denominator of hardware it will be running on. Java programs have an extensively tested standard API of functions to ensure backwards compatibility. In C you may have to recompile or change code whenever a new version of Windows rolls out. Java is a very well structured object oriented language compared to C or C++. Java SQL database drivers must adhere to strict SQL standards to be considered for different levels of JDBC compliance. I can write SQL that is garaunteed by the JDBC driver to work on a database, thus having true database independance. In C, each vendor implements a different subset of SQL in different ways such that you have to pick up a third party abstraction layer, or write your own, or target one database (ODBC doesn't work, even Access runs queries locally).
The only downsides to Java is: all java programs will use more memory than C programs... always! Java programs will take longer to start until a shared VM is implemented(is a JSR right now). Java will be slightly slower than C until Java has had about half as much time to develop compiler(JITC) technology that C has. Java will be slower at floating point until an API for fast system-dependant/non-IEEE floating point math is supported (This is why people claim, and are accurate to a degree, that Java isn't as fast as C at raw number crunching... This is probably the only reason as well).
Of those, the only problem that will always plague Java is large memory footprint. That is because it comes with it's own libraries and must do garbage collection.
It's appearant to anyone (like g4dget) that SUN sinks more time into the Windows JRE than anything else. The second biggest, as of 1.4, I would have to say is Linux/Mac. Solaris is the lowest on the list really. Most people that use Solaris use it for Oracle. The Java market has always been on Windows and IBM machines. IBM rolls their own, and they do a great job. Maybe they will release theirs a bit more free if their agreement with SUN will let them. I don't think they are allowed to discuss their contract with SUN because of the contract itself. At least, that's the rumor about the Java contracts that was on the net about 5 years ago.
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.
Not too surprised (Score:5, Interesting)
Re:case in point: Volume Manager and Netbackup (Score:3, Informative)
#1: No it isn't. VxVM is a Veritas product. Sun just resells it.
#2: Yes, the VMSA GUI (or VEA or whatever they call it today) is so stupidly broken it's not funny. That's why you have to learn the commandlines like vxvol, vxdg, vxmake, vxassist, vxdctl, vxdiskadm, vxedit, etc....
The GUI is worse-than-useless; it's counter-productive. Stick to the command-line and you'll be fine!
Damn shame they dropped the old vxva GUI.... _that_ thing rocked the house!
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:Not too surprised (Score:4, Interesting)
I would get worried about Java as a career yet though. I just recently switched workplaces as a J2EE architect. At least in my town (Jacksonville), and accorind to the recruiting firms I talked to, there is very little else going on except J2EE. I can definitely see Java being the COBOL: great now, but antiquated later.
More to the topic at hand, I don't see client side Java getting better anytime soon, because Sun already lost a lot on that side while gained a lot on the J2EE side. Future releases will be more geared towards long uptime high memory applications more than short small ones.
See what happens... (Score:3, Funny)
Hand the implementation to Microsoft, they can fix the problems this has...
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)
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.
Java vs Python (Score:3, Interesting)
My experience is that java is faster than Python, but that speed almost never matters for me.
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:What's the point? (Score:3, Interesting)
If you bothered reading the piece before clicking "Post a slaverng Java fanboi response", you';d notice the engineer is recommending Java is so bad at Sun it not be used BECAUSE THE JAVA ENGINEERING TEAM WILL NOT FIX IT. Because they regard features as more important than a stable API or bug-free runtime.
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?
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: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.
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)
Re:Java Implementation (Score:3, Informative)
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)
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: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.
I question the validity (Score:5, Interesting)
I have never directly worked for Sun, but I have worked with them in many ways and they have been using Java in production environments for a long time and I'm certain they will continue to.
They use it in Solaris 8 & 9. No one ever told me this, but it is not difficult to see this, login to a machine running that OS and start up their print manager, looks amazingly like the Java L&F.
If you've ever taken a training class from Sun, the survey that you fill out at the end of the class is a Java application. I worked at a training center for a while and we never had any problems with this application.
Friend of mine that work for Sun talk about where they are using Java internally and it is immense, there is no way that in the forseeable future any of this is going to change. I'm going to talk to them and see if this memo was really sent out.
My wife writes Java GUIs and actually has never ever had any of the problems that they are referring to in this memo. The GUIs she writes runs fine, and they are very complex GUIs, things that do tasks such as controlling telephone switches.
I'm not saying that Java doesn't have some performance problems by any means. I program in Java and I know a lot of peoplel who do and we've discussed these performance problems. I've also written hello world programs that don't take up 9M, but then again I question the validity of the programmer who wrote that program. I know if I write it bad enough, I could write a C program that would allocate 9M of memory and have the only functional thing it does is be to print out "Hello world."
So I guess this could be true, but as someone who has worked with Sun before, I find it very, very hard to believe.
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.
Resident (Score:3, Informative)
The memo was talking about how much memory the program takes when it is running. You are on the right track, the original poster was wrong. I haven't tested it myself, but the numbers in the memo seem about right with my experience. The reason a "hello world" program takes up 9M is not because the program is inefficient, it is because Java requires a JIT compiler and other crap be loaded and running with the program. The actual "hello world" code and data were probably only a few kilobytes (if even that). The compiler, gc, &etc took up the remaining 8.9M--not to mention a bunch of processing time.
Java is only free if your memory and cpu aren't worth anything. ;-)
Turf War (Score:3, Insightful)
Anonymous Inner Classes (Score:5, Interesting)
But what I've never needed to do with them is serialize them. Interesting.
Did you notice that of the 9 key bug/issues, 5 were AWT (GUI) related and 1 was Serializing Anonymous Inner classes.
Why would they bring those up, and then within a sentence or two, mention Python. From what I understand, Python is mainly used for server side scripting. I doubt anyone uses Python for serializing anonymous inner-classes!
The letter was put together hastily at best. It was an eclectic set of beefs.
The last sentence really sums it all up. It's politics to get some resources shifted in their favor for the next build:
Re:Anonymous Inner Classes (Score:5, Informative)
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)
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)
"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
Re:Perhaps you should read the letter b4 posting i (Score:3, Interesting)
Hrm. Looks like Solaris 9 still needs a little work. At least we can see that the PC implementations can get those pesky "hello, world" programs into something more reasonable - like only 5 megs of RAM...
But it's certainly not the language, nor the design, concepts, nor intent behind it... It must be the implementation. Heck, I'm sure any day now, there will be a JVM that runs even faster, even lighter than native code. Any day now...
Re:Perhaps you should read the letter b4 posting i (Score:3, Interesting)
With every release, Sun breaks something that worked in an older version. Swing in 1.4 blows up all over the place where 1.3 worked fine. If the failures in the latest JRE don't affect you, then you can use it. The place I work for runs into this with every release we make. We have to pick one version and say we only support that because other versions have bugs. We also don't have the QA resources to make sure we run on every single version. We're not the only ones. BEA WebLogic still does not support JDK 1.4, even though it's been out for over a year and is approaching the second minor version update.
"Typical resident set requirements for Java2 programs include: Hello World 9M" Again, BS. I have a TINI board running that only has 8M of memory total, AND I have an old Handspring (8M) that has Sun's JDK and IBM's JDK and Java3D on it.
Just because there's a Java implementation that runs on a small platform doesn't mean the one that runs on Windows or Solaris isn't grossly overweight. IIRC, running something not a lot larger than Hello World on 1.4 for Windows takes about 12M. That's a stupid-big footprint and there's a feature request in-process to fix it.
Article proves Sun should have spun off JavaSoft (Score:3, Interesting)
THERE IS NO JULIAN S. TAYLOR @ SUN!!! (Score:3, Informative)
-Jon
Re:THERE IS NO JULIAN S. TAYLOR @ SUN!!! (Score:5, Informative)
I found Julian here [auburn.edu] and here [google.com]
Re:THERE IS NO JULIAN S. TAYLOR @ SUN!!! (Score:4, Informative)
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)
Power Grab (Score:4, 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.
Re:Addressed? Hehehehe (Score:4, Funny)
Now it's "write once, run away"
graspee
Re:dog fooding is a microsoft phrase (Score:3, Informative)
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.
Re:shoot self in foot, then head ... (Score:3, Funny)
"The gun fires just fine, but your foot can't figure out what the bullets are and ignores them."
Quite amusing.
Re:Kiss and say goodbye to Java language!! (Score:5, Informative)
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:... nothing new under the sun (Score:4, Interesting)
Got the job.
Java is so much about a culture and not a technology that it's disgusting. And it's a pity too, because all the PRINCIPLES of Java (portability through the VM, objectification, etc.) are so good that Microsoft took them to build
Hell, I think Java is a great language. It concerns me that it takes seventeen steps to accomplish something as basic as opening a database connection, grabbing some results, and outputting them into an HTML stream (and seventeen may be generous). But, it's a very straightforward language, very teachable because it's so logical.
But too much of the culture is fluff. Why is it that Sun doesn't focus on point releases that improve performance but instead focuses on getin gthe newest buzzword, uh, "feature" out the door? Why did they invent something called Java2 which is, IIRC, just Java 1.3? Because they're more concerned about IMAGE than about getting their product - which is great in principle - in a usable state.
But let's talk substantively. I've developed large scale server-side applications in Java, C, C++, and - on the web-app side - PHP, Cold Fusion, and ASP.
The slowest of those was, almost without exception, Java. Java took the most coding to do a basic task, and Java was BY FAR the most difficult to package, deploy, and deliver to my customers. That's a real pity, because I was about 90% certain that our customer's architecture didn't really matter if we were playing with Java. Upgrading those old Dell NT servers to IBM? No problem. We'll just move the app over, and it should run without a hitch.
But, lord have mercy, it ran slowly.
To top it all off, here's some advice I received from a Java-guru at another company. I was griping about how slow Java was, and he said to me, "Oh, everybody knows it's slow. But why worry? Hardware's getting faster every day. True, 2ms is half the speed of 1ms, but who's gonna notice?"
I almost fell off my chair. It's that sort of laziness that makes my skin crawl.
Look, I love Java. I want it to succeed. It's a brilliant idea: an utterly cross-platform language whose apps run without regard to the hardware and OS under them.
But it's a seriously flawed masterpiece.
(The funny thing is, I was just going to write "Why was this modded troll? But then my post bloated... kinda like how you go to write "Hello World" in Java and... ok, ok, nevermind.)
Re:Hey wait a minute ! (Score:3, Interesting)
However, most of problems mentioned in the article are the same on all other platforms. For example the size of "Hello world" program (including RE) and how it grows with complexivity is a real Java problems. Check you memory for even small real-world (10 users, shopping cart with a catalog in SQL) application with EJB (JBoss), no EJB (just Tomcat servlets) and Zope. 250MB vs 75MB vs 15MB.
Java has been developed at time when CEOs/CTOs/COOs/CFOs have been counting fundings, not expenses and profits. When the buzzword had more priority than real features and problems in any technology choices. The time of "golder rush" is over, cool down. Now it's time to think. Sun begins to think. I hope it's not too late.
Re:PHP is the destination (Score:3, Informative)
Now with the gtk extensions [php.net] it does a mighty fine job on the server or on the client!
It has the ease of text manipulation of Perl [php.net] without all the nasty hacks in syntax. It's cross platform [php.net], free [php.net], and performance is good [linuxplanet.com]. (Probably better than Java, since my own testing indicates it's considerably faster than Python)
It makes a good, all-around scripting language for sysadmining, UI management, etc. and it even makes a good case for fast web development!
Among other things, a web server [freshmeat.net] (yes, a replacement for Apache!) has been written in PHP!
I figure that with all the noise of "web services" this, and "cross platform" that, there's a good chance that PHP could be the "next big thing"...
Yeah, I use PHP an awful lot.
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.
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.
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:the Java Myth part Deux (Score:3, Interesting)
I got a tip from someone about some command line arguments which did wonders to speed up Java apps. Why did I have to hear about those as word of mouth, why aren't they the defaults? Why did I have to hunt for them unsuccesfully this last time I had to reinstall the JRE?
When I type in "java.sun.com" why do I not see an incredible collection of high power java apps which I can download that do all sorts of wonderful things? Getting Microsoft to bundle a JRE isn't going to change very much. Sun is the one who has got to convince end users to keep their JREs up to date and to do that they have to keep end users happy.