Slashdot Mirror
Even Sun Can't Use Java
cowmix writes "It turns out that Sun does not eat its own dog food. Specifically, this
internal memo from Sun strongly
suggests that Java should not be used for Sun's internal projects.
More interesting still, they go on to state which other languages
fullfil Java's goals better than Java does itself. Finally, the
memo states Sun's own Solaris is the cause of many of Java's woes. Yikes."
... a memo which says that Sun has standardized on C# and Microsoft .NET.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
This smells bad. Sun have been forcing the monopoly thing down microsofts throat for so long, and now there they are victim of themselves again.
What took them so long to come out with this? It seems to have stayed nicely hidden while they could cause damage to microsoft. Looks like they're a lot more relaxed now it's 'home turf'
'home run' indeed. They're now able to disassemble java like they wished to for a while it seems, but wanted to get most leverage out of it against a competitor
Commercialism stinks
Read the article poeple, what their saying is that the JRE on solrais has huge significant bugs that need fixing!!
people spend far more time chattering about java than using software written with it...
maybe because talking about is the only field where java and c/c++ have the same performances.
While java encapsulates many features not found in standard C/C++ it is still bloated and slow.
We will remain committed to selling large Sun Enterprise servers to power these applications, however we should be more practical internally.
To me, this report seems to be the manifestation of a battle going on with Sun between the Java Engineers and the folks who integrate Java with Sun's other products. They went to the Engineers initially to explain the problems, but it didn't change anything. So they wrote a damning memo to management to force them to deal with the situation.
This isn't Sun saying to the world that Java sucks, its simply two groups within Sun saying that their official implementation needs to have a few bugs worked out.
-jrod5000
Assuming the memo is for real, this is a real boon for the Python community, even though it gets the bit about bytecode compilation wrong (Python DOES compile to bytecode and one CAN take the bytecode and ship without source). The point about Python carrying its compiler with it is true but IMHO it is a feature, not a bug. It always bugged me that Java had no good mechanism to compile simple expressions on-the-fly.
I am, however, a little leary on the performance parity bit. Don't get me wrong, I love programming in Python, but I know from experience that it still costs a good bit to create all the dictionaries that are used for frame construction, global maniuplation, and object management.
Python is, however, fast enough for a great many applications. I'm just a little skeptical about it being quite as fast in certain aspects.
Maybe within IBM talking about OS/2? Is nice to hire people to dig our own grave.
This damned langauge will go one of two ways:
they'll fix it,
or it'll die (phase out, dehype, become far too slow and filled with awkward design mechanisms that it cannot survive any longer).
-P
This memo states that Sun believes their Solaris implementation of Java to be flawed.
It states the flaws; ie. which flaws should be fixed.
So?
A REAL "shocking memo" would be one in which the company goes out of it's way to not criticize it's own product.
Did you "read" this, it says the problem is
"Solaris" not java itself !.
I always thought Sun made a mistake by not working with Microsoft when it came to Java -- especially with regards to Sun's . Some of the weaknesses I read in the article are exactly what Microsoft aimed at with their
On a lighter note, "Mean Dean's Semi-Definitive Guide to Selecting a Programming Language" describes the process of shooting yourself in the foot with Java as "The gun fires just fine, but your foot can't figure out what the bullets are and ignores them."
--- have you healed your church website?
When people ask me about using Java, I always give them a simple answer: it is much nicer to program in then any other language that I use (except for API changes over different versions), but it takes way too much memory and is too slow for programs that I would use regularly.
The memo agrees with me and lists the huge memory requirements as the number 2 problem (number 1 is that Java programs require the JVM to run).
Considering that compiling Java into a native executable would seriously improve its performance (and remove the JVM requirement), I wonder why the memo doesn't discuss that possibility?
Microsoft departments have to use their own beta products. Its internally called "dog fooding."
Do you find it just a little curious that the story contributor used that particular phrase? Methinks a Microsofty at work here. Nice job, cowmix.
Every language erver made has had OO shoehorned in at some point. Look how many are successful.
PHP is a language for people who are too dumb to program. Most PHP programmers I know use it because the cannot program well enough to use a real language (with strong typing, etc).
In the rush to bash Java, the summary here was totally off the mark. From the article:
A review of the problem indicates that these issues are not inherent to Java but instead represent implementation oversights and inconsistencies common to projects which do not communicate effectively with partners and users.
And it goes on to mention issues with Solaris. Nothing about Java itself being inherently problematic, just issues with certain implementation.
It has problems ON SOLARIS. These engineers do not complain about Java being broken as a language. They have a big problem with implementation of the JRE on one platform. They mention nothing about the linux dist, or the win32 dist.
But that's the least of my concerns as a Java developer. Where I'm doing most of my work is on back-end data access systems, running on J2EE servers. Access my stuff with Java, with PHP, or with a .NET client, I really don't care...
So the speed issue for PHP vs. JSP doesn't matter to me. What I care about is how big the VM gets, and whether or not I'm going to have backward compatability when my app. servers get upgraded. Give me a PHP-based application server, and yeah, I'll be happy as a clam. But I haven't got the time or the inclination (or the skill) to go and build one myself.
It was a joke! When you give me that look it was a joke.
I wish people would read articles before the start flaming. Sun is not saying that Java is flawed!
What Sun is saying is that the Java Runtime Engine, as implemented on Solaris (whether its Solaris on SPARC or Solaris on Intel) is seriously flawed. In fact they go on to point out how the memory foot print for Windows is so much smaller than for Solaris.
What they are doing is asking their engineers to fix the Solaris implementation.
If any of you want to see an implementation of Java that rocks look no further than Mac OS X or perhaps even Linux!
see above
I've been using PHP for web development for three years now and I must say it is the only way to fly. I can't believe how people still wrangle with ASP and Java when PHP is so easy and fast.
--- witty signature
There's a lot more to Java than JSP. That's like saying, "Don't use Java, Flash is much better for building applets."
My development team uses Java for large-scale web applications and web services. For that, along with several other technologies, Java is indispensable. Using a single servlet entry point, we've built our own application server framework based on XSL page templates, XML page configuration files, reflection, and JDBC.
Granted, we had to do a lot of performance optimization to get it to run on the inefficient Solaris Sun JVM, it is quite fast on servers running other OSs with IBM's JVM. And I don't need to remind you of the experiment used to show that the number of Java development positions open is still strongest out of the major languages, even given our current economic climate.
I'll second the idea that PHP is much more productive than Java for developing web apps, at least smaller ones.
I'm a long time WebObjects developer, and I recently did a couple projects in PHP. Although I was learning the language from scratch as I was implementing the project, development still went substantially faster than it would have using Java/WebObjects. And developing in WebObjects is generally faster than developing servelet apps. I've decided that database abstraction layers are annoying and result in frustrating workarounds at least as often as they save time and bugs. So it cancels out. The cross-tab reporting I implemented in a day in php would have been very annoying to accomplish in WebObjects.
The only caveat is you have to have the experience and the discipline to impose good organization/structure with PHP, or you may get bit hard with large projects that must be maintained. But then I've seen people build unmaintainable messes with WebObjects too.
I haven't had a chance to find out how PHP performs as the first project I did only gets a half million or so hits per day. I did some load testing and was pleasantly surprised, though. And that was using MySql on the same machine, and with a search engine also running on the same machine. Using an oracle tier I think it would do very very well.
this is more microsoft FUD. . . oh wait...
ok so its more SUN FUD. Sun is trying to kill java because its open source! hacker freedom!
I'd be interested in finding out what are the causes of the problems with Java. Virtual machines don't have to be pigs. When the IBM PC was first introduced, I wrote a lot of software in Pascal using the UCSD p-System. The applications ran comfortably on machines with a 4.77 Mhz 8088, 8087 FPU and 512KB RAM. Most of the applications and operating system were compiled into p-code, which is similar to Java byte codes. The p-machine interpreter was a small resident module written in 8086 assembly language. The p-code was actually more memory efficient than the machine code produced by conventional compilers.
Mea navis aericumbens anguillis abundat
InternalMemos is notorious for running hoax emails. This email is no exception. It includes a number of inaccuracies and curious references. The comparisons with Python are just amusing.
Doing a quick search on the names, you'll note that there's no reference to the sender anywhere in Google, let alone associated with Sun. Most of the folks in the CC list do not have Sun email addresses. They're probably friends of the hoaxer. The Sun folks in the CC list include a JavaOne and a guy who has himself on the J2ME JSR.
I wouldn't hold out for Sun switching to Python. haha
I was especially interested in the part of the memo that talked about extensions being rolled into the main product. But, apart from backwards compatibility, I think it just makes learning the language more difficult.
I learned the language back in 1.3, and I'm amazed at how much more has been added to the 1.4 release. Sifting through the javadocs has become a bit more of a pain, but nothing someone already familiar with the language can't handle.
My concern is people who are learning the language. I think the API is becoming more and more overwhelming to future Java developers. Look how much fatter O'Reilly's Learning Java book has become!
A smaller J2SE with standard extensions to be downloaded as necessary makes better conceptual sense.
quiquid id est, timeo puellas et oscula dantes.
LOL
;-)
Can you imagine that there are people who do a little more than just generate HTML with their programs? But what does a web developer know - most of them are proud to have mastered the extensive MySQL command set anyway... there is no room left for advanced programming knowledge
Not that I'm suggesting they are wrong, I have no way of knowing either way, I just think that producing memos like this - and getting them leaked - is probably not the smartest way of getting the declared objective.
Admission: I use Java. It isn't perfect. It uses too much memory. It isn't hugely fast. But the applications work and the amount of debugging we have had to do is a tiny fraction of what I would have expected with C++. Its suitability for a given project depends on a whole host of factors not considered in the memo, and it would not surprise me if, for some internal Sun projects, it was inappropriate in its present stage of development.
Panurge has posted for the last time. Thanks for the positive moderations.
The extension mechanism works well, they should allow it to do it's job.
There are two core problems here: One is that Sun's implementation of the JRE for Solaris is an even bigger hog than Java is naturally. The second is that the JRE in general has got too damn many built-in libraries. It's very convenient for me as a developer who uses many of the extensions anyway, but it's making the language much more intimidating to approach.
It was a joke! When you give me that look it was a joke.
Sun has chosen to make graphical tools in Solaris use Java over straight X/Motif binaries. An example is Solaris Management Console, the replacement for AdminTool. If you run AdminTool on Solaris 9 you get a warning (every time you run it) that it will be replaced. So you start SMC (which requires Web Based Enterprise Management to be running) and wait, and wait. SMC is a pig in both performance and memory utilization! Unfortunately for those who prefer a GUI for managing disks (Solstice DiskSuite), it is being replaced by Solaris Volume Manager (Solaris 9), which runs under SMC! Most of Sun's enterprise level management products extensively use Java and you would think somebody would have taken a look at how slow their products perform (unless they tested them on "the latest and greatest" and found the performance OK. I would like to know what their definition of OK is! Java works for some things, but it doesn't work for everything! It almost seems like management said "We created it, let's use it!" without realizing the performance hit, or just simply ignored it.
You are seriously misguided if you think the real usefulness of Java is applets. The most prevalent useage of Java is on the server for enterprise level applications and development tools. This is not something you will ever use PHP for.
The point the memo was making is that there are issues with the JRE implementation on Solaris and that due to these limitations Java is not the wonder language which solves all development issues as some of the SUN marketing drones would have us believe, or PHP as the parent would have us believe. Having come across several of the issues mentioned in the memo I think its good to see an internal drive for resolution of known problems. Hopefully SUN might actually channel resources to address them now.
This is by no means the end of Java
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
While some of their points are somewhat valid (ie, the Class.getFields() returning first all the public and then later the public, protoected and private fields), but I tend to think that changes to other classes are done not to make the developers' life more difficult, but to enhance flexibility or act as work-arounds for other either very subtle or very infrequent issues. No language is perfect, and Java is still a relatively young langauge.. Once Java has aged as long as languages like C has, I'd be one to bet most of these "incoveniences" will have been resolved.. As far as Sun developers not using it, that seems highly defeatist.. If you make a product that the world has practically adopted unconditionally, and it's activly used the world around, the only way to make it better is to use it, and find and fix the issues. 'Ya can't fix what you don't know is broken... Much of Java's bloat is due to the fact that at VM statrtup, it has no idea what you're going to do with your program, either Hello World or TogetherJ, so it needs to be ready for the worst-case. There's really no avoiding this. As mentioned, Java is interpreted bytecode. The threads are tied to the system to be real system threads -- this takes some time and resources to do and do right. True, a new version of the JRE over-writes the previous versions upon install. But isn't having a backup version on the system just good sys-admining? It's just a symlink, for petes sake...
Reads to me like a memo that has intentionally leaked out into the open, trying to force Sun Management to act. Software Development Dept is clearly unhappy with the Solaris implementation of JRE and therefore stops all use of it, until is has been fixed. While the Java Dept does not seem to have too much hurry to do that (majority of cases closed - "will not fix".
What would you do in your own line organization, when you are the boss of one department and the boss of the other department just gives you the finger? And your superior is unable/unwilling to solve the conflict? You write a flaming mail to your superior's superior, threaten to withdraw any support for the platform your company is famous for and leak the memo into the open to get public support. This, of course, has to be done nicely so that no-one can blame you directly for it.
Excellence: Moderate (mostly affected by comments on your karma)
The report itself points to the correct solution: switch to Python, since Python is implemented so much better than Java.
-russ
Don't piss off The Angry Economist
If they were at all aware that the memo would be leaked, it sounds like they're trying to sabotage Java. Perhaps they've realized that IBM is doing a better job of implementing Java and Java solutions.
At any rate, it sounds more like the death knell of Solaris.
How do we know this is even a real internal memo? I mean, this is comming froma site *named* internalmemos.com. Come on! There's a submission form. I could just send any old thing in if I wanted. The only difficult part is making it look convincing. That only takes a few hours of effort.
Anyone that has an axe to grind with Sun could have sent this in. That could be some big company or (far more realistic) some random slob that just wants to be mean.
Or it could be real. But who cares? As the Score 5 AC pointed out, this is about bugs in the JRE on Solrais, not necessarily about Java in general.
Does anyone on slashdot remember what FUD is?
Furry cows moo and decompress.
Although it is well known that Java is a performance hog, and these bugs they talk about are real. And it is well know for anyone who has done extensive Java programming that the people who write Java have always put more emphasis on delivering the JDK and JRE's faster and more bug free for windows, I really do not believe that this memo has been sent or will be taken serisously if it has.
I have never directly worked for Sun, but I have worked with them in many ways and they have been using Java in production environments for a long time and I'm certain they will continue to.
They use it in Solaris 8 & 9. No one ever told me this, but it is not difficult to see this, login to a machine running that OS and start up their print manager, looks amazingly like the Java L&F.
If you've ever taken a training class from Sun, the survey that you fill out at the end of the class is a Java application. I worked at a training center for a while and we never had any problems with this application.
Friend of mine that work for Sun talk about where they are using Java internally and it is immense, there is no way that in the forseeable future any of this is going to change. I'm going to talk to them and see if this memo was really sent out.
My wife writes Java GUIs and actually has never ever had any of the problems that they are referring to in this memo. The GUIs she writes runs fine, and they are very complex GUIs, things that do tasks such as controlling telephone switches.
I'm not saying that Java doesn't have some performance problems by any means. I program in Java and I know a lot of peoplel who do and we've discussed these performance problems. I've also written hello world programs that don't take up 9M, but then again I question the validity of the programmer who wrote that program. I know if I write it bad enough, I could write a C program that would allocate 9M of memory and have the only functional thing it does is be to print out "Hello world."
So I guess this could be true, but as someone who has worked with Sun before, I find it very, very hard to believe.
"Everybody knows the moon's made of cheese," Wallace.
PHP is good for its ubiquity...
Many servers already run it or can be convinced to run it with no problems.
But if you have the opportunity to roll your own server then you really should be using Zope.
Based on Python, the functionality of zope and the elegance of its implementation, really blows PHP away.
PHP will never fill the application server market the way that JSP does and
that Zope will.
If you want to see why PHP is good for quick and dirty little sites that want to be run cheaply on commodity hardware, but why JSP really rock - then check out the article on aceshardware about the rationale of setting up a java based sytem.
PHP is great but after you use Zope you won't want to go back to PHP ever again.
It may be easier to get started in PHP than java, sure, but to say it's only "a language for people who are too dumb to program" just reveals you for what you are -- nooobie.
If you really think a language is better because it's paradigms are more difficult to understand and take longer to work with, I won't be hiring you any time soon.
Java hasn't payed off on it's promises. The few minutes of time it saves by preventing an aliasing or typing error here and there aren't worth the awkwardness and verbosity.
If you'd read the article, you could see this applies to problems with the Solaris JRE, not Java itself.
Solaris 9 for x86 was delayed for quite a while to address some of these issues.
Please. Try to communicate the essence of the article in your summary.
The essence is, Sun has a buggy implementation of Java on Solaris that is scaring off internal developers.
The essence of your summary is, Java isn't usable, and Solaris is a problem. Duh, you missed the connection! It's Sun's *implementation* of Java on Solaris that's inadequate. The memo stresses that nothing's wrong with Java, and it doesn't suggest that anything's wrong with Solaris.
Why would you write such misleading over-generalizations? What's the motivation? C'mon, Taco!
PHP is 4 times faster than Java technology 'JSP' (Java server pages).
Yeah, it crashed when they ran it at 5x Java-speed....
This memo looks like a turf war to me. Somebody is ARC needs to justify his job, and has decided he can do it be getting his hooks into Java.
"Java is not the wonder language which solves all development issues as some of the SUN marketing drones would have us believe"
:-P At least not in Solaris systems, depending on how you interpret the memo.
No, they don't even think it should be used in commercial apps.
Beware: In C++, your friends can see your privates!
PHP is good for its ubiquity...
Many servers already run it or can be convinced to run it with no problems.
But if you have the opportunity to roll your own server then you really should be using Zope.
Based on Python, the functionality of zope and the elegance of its implementation, really blows PHP away.
PHP will never fill the application server market the way that JSP does and
that Zope will.
If you want to see why PHP is good for quick and dirty little sites that want to be run cheaply on commodity hardware, but why JSP really rock - then check out the article on aceshardware about the rationale of setting up a java based sytem.
PHP is great but after you use Zope you won't want to go back to PHP ever again.
The memo says that the JRE implementation on Solaris (not the implementation of SOLARIS itself)is a cause of many java problems, including
1) Large memory usage (cites an example of a "hello world" program using up 9MB)
and
2) Long startup times
the memo blames these problems in the SOLARIS implementation of java VM on the "fact" that that project doesnt seem to have prority. The memo states in passing that the win32 vm doesnt seem to suffer from these problems as much. So the memo specifically restricts itself to the solaris jvm.
It also talks about how the java vm doesnt confirm to the sun SDF, and thus the versioning is incomaptible with it. There is no support for patching an installed java vm, thus requiring an entire new install of the latest version of the jvm if a bug is discovered. This means either having multiple jvm installed and running if different java applications on a system need different java releases, or breaking a whole set of applications, which may not run with the latest release. Again, cites examples of these.
The memo makes a case for:
1)introducing a patch system for java vm, so there need not a a new install everytime a bug is discovered.
2) stict backward compatibility, so that an application written for the older version of JVM works with all later minor revisions
3) consideration of a new mechenism for "bsoleting" and interface replacing/in addition to deprecation.
4) priority for solaris jvm development, with claims (by comparing it with python!!) that the memory footprint of the java resident set (the code bloat added by the garbage collector and co to each running java program) maybe reducible to a fifth of its current size.
read the memo. its a very intelligently argued writeup, and has been completely misrepresented in the slashdot post.
very interesting read.
Ghoul2
Sigura Non Grata
It's about time that the whistle was blown on this situation. Ironically, only Sun had the credibility to do so.
.Net. You decide. Java is simply not competitive. It's garbage and it's a dead end.
Java is a fine language with an great set of ready-to-use out-of-the-box classes . Unfortunately, the VM crisis and minor release incompaabilities render it USELESS for all but the most tightly controlled deployment situations. It is nearly impossible to support commerical apps on Java without torturing yourself and your customers.
What to do? Simple. Apple needs to open and get Cocoa running on Windbloze and Linux and we need to once and for all put a bullet in the head of Java as a desktop development platform.
There are so many corporate fiefdoms built on Java, of course, that this train wreck will go on for years before the final collapse. Make no mistake, however, it will collapse.
Cocoa or
Glin
PHP is years behind java .... it cannot scale, does not use threads and the connection pooling is a joke.
... Java requires a new thread... guess which is quicker to create, and requires less memory?
.. so not really stopping XSS attacks).
- Java can share resources across threads, e.g. one tomcat thread can share a cache with another, so saving many hits on the database. The only caching available in PHP is using the user's session - no where near as good as one central cache for the entire application accessible by all clients.
- PHP's database connection pooling is fairly pointless.. the persistance only lasts as long as a single request.
- PHP's database api is terrible. To convert from using one database to another all database related function calls need renaming. In Java it is just a case of changing the connection url.
- Java is type checked, so you know when you've made typos/passed in the wrong sort of arguments to a function. PHP will just carry on (sometimes without even giving you an error). This makes your life as a developer much harder as you need to undertake a lot more testing.
- Error reporting under PHP is a joke.... Exceptions are far more powerful.
- Java can be just as quick as a C program as it is able to use run time optimisations etc.
- PHP has no real OO features - it's inheritance structure can only go one level deep - i.e. parent and child. It has no protection on class attributes, so you rely on the programmer to use your get/set methods, rather than just accessing the variable directly.
- PHP cannot scale as far as Java, as it requires a new process for every additional request
The only thing PHP has in it's favour is a friendlier API for web development - e.g. addSlashes or htmlEntities, but then these aren't exactly all they are advertised as, due to the global configuration potentially being different on each deployment. (htmlentities doesn't even remove ( and )
Lie down there Boy, for the cows to run over you.
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 comunicate effectively with partners and users.
this is talking about a problem with the solaris JRE
Can't imagine what the problem is - in my experience java on solaris is very fast.But its well known that most of the dev resources go into getting the Windows version to fly
i know sun have been angling Java for use in telecomunications for a while and keep running into problems there because they require consistant QoS (no pauses for garbage collection), less memory overhead, and scaling to handle huge numbers of threads. From what i've read a lot of these problems have been addressed with 1.4 (certainly incredible improvements in GC). improvements between major new JRE versions are bound to mean some programs need to be reworked to fully take advantage - but i have never once seen a program that wouldn't run on a newer version of the JRE ie no backword compatiblity issues whatsoever. EVER. As for grid line behaviour changing in the Jtable I mean for f*^% sake is this guy on crack? swing programmers should never be worrying about absolute stuff like that good Swing programs are are lot like good HTML - they assume very little (but yeah they do use a load of memory)
i don't know what this guys ploblem is. The source code to 99% of the J2RE and J2SDK is available. (the bits that are closed source are stuff to do with fonts and imaging codecs that Sun doesn't own i believe) so what is to stop these guys fixing the problems in the solaris implementation? they work for Sun for christs sake! they could be more proactive than just whining and submiting bug reports.
'Be the change you want to see in the world' - Al Gore
And I thought I was the only one actually using them. I use them all over. They're a great way to intimidate the other developers, plus I needed them to pass Sun's Cert.
...namely Java. By bringing the Sun Java implementation through ARC, these issues can be resolved.
But what I've never needed to do with them is serialize them. Interesting.
Did you notice that of the 9 key bug/issues, 5 were AWT (GUI) related and 1 was Serializing Anonymous Inner classes.
Why would they bring those up, and then within a sentence or two, mention Python. From what I understand, Python is mainly used for server side scripting. I doubt anyone uses Python for serializing anonymous inner-classes!
The letter was put together hastily at best. It was an eclectic set of beefs.
The last sentence really sums it all up. It's politics to get some resources shifted in their favor for the next build:
Anyway, regardless of the JVM, applets are only applets.
I hate to sound trite, but the fact that you place so much importance on applets (they are, after all, the only example of the technology that you imply exists) leads me to believe you're not really versed in the current trends in Java. The simple fact is that no one use's applets anymore; certainly there is no new development going on in that area. Most Java applications are written for the J2EE platform.
Even at that, those who do wish to write the modern equivalient of applets use Java Web Start, which is much more robust and doesn't operate within the confines of a browser.
uhm, i dont know if you understand what 'monopoly' is, but 'shitty product that doesnt work' is not the same thing as a 'monopoly', jesus christ.
What's the selling point of Java? Write once, run any/everywhere?
I know something else that's like that. C/C++ source code, Makefiles, configure scripts.
If you write something, distribute it this way. Unix manufacturers should write a source-build tool/script that does all the
This leaves out Windows users (who on the whole don't have a C compiler to hand), but that's a tar.gz sourceball, and a setup.exe. Voila, you have all your bases covered, and it's "universal".
Get your own free personal location tracker
Purported internal memo. There's nothing there that suggests it is genuine and a few things that suggest it isn't.
Yes, the PEAR project has to crawl before it can walk, but the ability to do both object oriented code and procedural hacks (whichever makes most sense for your project) makes the PHP environment for web applications the better choice. Ever tried finding the location of a JSP bug?
http://tinyurl.com/4ny52
is give Java a burial. So Sun is finally admitting something end users knew from the git-go.
Gaaaaaaaaaawd, I hate Java and Java Script.
I hope this illiterate drivel was intended as a troll, but just in case it was not:
Forget Java man and go to PHP!
Java is a general purpose programming language, PHP is not. PHP is a scripting language designed for server side web scripting. Ever tried writting a server in PHP? You can't, it doesn't let you accept incomming socket connections.
PHP is 4 times faster than Java technology 'JSP' (Java server pages).
I'm not sure where you get your numbers from (the link you post is to a non-existent howto in the LDP), but I doubt that they are accurate. PHP is an interpreted language, C is a compiled language, Java is a hybrid (Just-In-Time compiled). C is likely to be faster than both (although a JIT language can make use of run-time profiling for optimisation, so in theory Java could run faster than compiled C code, but this is new technology so it doesn't - yet). Primitives in C are typed, in PHP they are not. This means that PHP has a lot of type checking to do even for simple variable assignments. PHP is unlikely to be faster than Java (although it may still fit your needs better in other areas).This tallies because compiled "C" program is 4 times faster than Java.
PHP is a very lightening fast object oriented scripting language.
PHP is not an OO language. PHP supports a few features of OO, but not the vast majority (public / private methods, inheritence etc). PHP Classes are more equivalent to namespaces than classes.
PHP is 100% written in "C" and there is no virtual machine as in Java.
PHP is an interpreted language (how many times do I have to say this?). There is a virtual machine, and it interprets the PHP script. The Java VM compiles the bytecode to native code at run time (and only once, when the JRE is started in server mode). <oversimplification>
Nothing can beat "C" language
This is the stupidest statement I have ever heard. C does nut support dynamic strings, so only a fool or a masochist would use it for simple text manipulation tasks (ever written a CGI script in C?). C has many advantages, it's a mature language so a lot of work has gone into making it fast. For this reason it is good for low level system work. It is not the best tool for every job. If the only tool you have is C, every problem looks like an operating system...
Java programmers will really "LOVE" PHP as PHP class is identical to Java's class keyword.
Java programmers will loath PHP. It doesn't properly support a large number of features found in Java, because it is not a general purpose language, and it isn't even an OO language. Web developers like PHP because it's simple. For a detailed criticism of PHP look at thi paper published at the UK Unix Users' Group last year. (And possibly read my reply to the criticisms made.
The aim of java was to abstract the OS and windowing system away from the developer, and in this it succeeds quite well (although it still has speed issues and the API is baroque in the extreme in places - try creating a non-blocking port in Java if you don't believe me). PHP is an interpreted scripting language aimed at web design, which has agregated, rather than being designed. Comparing the two is a crazy as saying Mozilla is far better than Linux.
I am TheRaven on Soylent News
How come I've not seen any comments questioning the authenticity of this memo? All we've got is the word of some site that this memo actually came from inside Sun. Presumably, they had it leaked to them by an anonymous source. Now, lets think about this for a second. What "anonymous source" has lots to gain (potentially billions of dollars) by disgracing Java? What "anonymous source" has a history of lies, deciet, astroturfing, libel, and other shady or illegal practices?
I'm not saying that Java doesn't have problems. But still, it pays to take this information with a grain of salt until its source is proven. Which means until Sun officially says "this is true", as there's few (or no) independant tech news sources that don't get loads of advertising from the "anonymous source".
Seems that Java might not be Sun's cup of tea anymore... err...
*hides*
It looks like to me like their problem is with the specific Java VM on Solaris, and the Java team's unwillingness to fix JRE bugs as opposed to adding new features. Not with the Java language itself and not with Solaris itself.
Furthermore, they don't advocate abandoning Java in favor of Python; the theoretical performance of the two languages is the same, so they compare the actual performance to show that the JRE is unnecessarily slowing Java apps down.
I think the poster was much too eager to bash Sun to actually bother reading the memo.
Ubi dubium, ibi libertas.
The other thing PHP has in it's favor is that the developers have spent time debugging it. PHP features actually work.
Java, on the other hand is a crash prone mess. It has more bugs than MS Active Server pages. It's just unusable.
So cool it, Sun Butt Boy, until after you've put in some serious debugging time on Java.
First off, this "memo" is the complete opposite of Sun's Java stance. They believe that Java should be used for everything from running enterprise applications on E10K's to apps on your PDA. I don't think that Java should be used everywhere, and I'm a big fan of the language.
Second, these might have been arguments against Java a couple years ago, but they simlply aren't true any more. For enterprise-level applications, Java outperforms Perl or someother scripting language on every front (scalability, preformance, maintanability, etc.).
Finally, these bugs don't even exist! I seached for the bug id's in Sun's bug database, and didn't get anything.
As usual, the Slashdot community has formed a collective knee-jerk reaction against any technology that isn't open source and Perl.
I really hope to see Java dead.
Good software is not built around layers and layers of redundant code needed to adapt the program to any possibly existing architecture in the known universe because the company behind it doesn't want to adapt its code. When I write for speed I use C, when I write for portability I use scripting languages; if I need both I use again use C and stick to something called the ISO standard, the same standard that makes most software run on so many architectures Java can only dream about.
Hating the Microsoft way shouldn't hide the fact that Java is an obsolete thing, a platform fully oriented to the business side of the programming art, a crap that should have died from the very first day.
'nuff said. Flames on.
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. ;-)
IE they could've been 2 Arab-Americans at Langley talking into microphones, not 2 Iraqis
I remember this story from long time ago. While Sun needed a accounting system back in the 80s, they went for the best solution: IBM S/390. It's also during the same time, Sun was marketing very aggressively against main frame and want everyone to go to client/server solution.
I really respect Sun in this regard. It knows the limitation of its own technologies and would try to choose the best one their won.
Just like in the 80s, Sun has seen the future to be client/server but it choose S/390 to run their accounting. Right now, Sun won't bet its own mission critical data center type system with the toy language call Java.
Java is good for build small/middle scale application that replacing ASP or VB. However, it's not really a proven technologies for large backend mission critical system. Sun's engineers are doing what's best for their work and not falling for the hype Sun's own marketing is creating.
Sun is delivering a cross-platform environment that targets primarily Windows, and they are doing the other platforms as an afterthought. But Windows developers aren't going to switch to Java in droves no matter how good Sun makes it. What Sun should be focusing on is making the absolute best UNIX/Linux programming and then making it easy to deliver those applications on Windows as well. In different words, Sun's strategy is wrong: they are going after the biggest market, but what they should be doing is going of the market that is most inclined to actually adopt Java.
That is, curiously, the strategy that Mono is adopting: you get excellent Linux support (through Gtk+), but you can also deliver your software on Windows (through the Win32 version of Gtk+). Seems like a more attractive proposition to me.
After all, Motorola standardised on Intel and Windows NT.
Government of the people, by corporate executives, for corporate profits.
Kiss your ass and say goodbye to PHP as well.
Of all the projects that grew out of someone's basement, this is the harriest by far (nasty shit).
I refuse to do more than fiddle with php
until PHP5 (perl4 sucked. perl5 is great)
What's with the general disdain for Java here? It seems as though some Slashdotters are always looking for a reason to slam Java (FYI, Java != Sun's implementation of Java).
Ok, maybe Java's not totally free, but neither are you and I. It's free enough, and an excellent platform for enterprise application development. I can't think of another language that gives me the productivity and yet preserves flexibility of platform and vendor (well, except maybe Perl).
As other posters have said, this is a blow to Solaris more than one to Java. IBM seems to have taken the lead with Java and are making it a part of their core strategy (along with Linux). Sun has become irrelevant to Java for the most part.
The internal memo was from an idiot.
b ugParade/ index.jshtml
Anyone that compares a scripting languate (python) to a full programming language that also as a VM has no clue. a scripting language has minimal overhead memory requirements because it does not have much of a memory management job to do.
Complaining about 'will not fix' items on an older JRE is dumb as their must be SOME reason for the 1.4. If everything could have been fixed in 1.3.1, it would have been 1.3.2.
Further I personally was told not to rely on the "sun" classes as they change. The article writer suggest that each release of the JRE causes classes to be dropped and added. I have NEVER experienced this and its a violation of SUN's stated practice.
"4. It is not backward-compatible across minor releases." Then this fool goes and compares 1.3 to 1.4 or 1.1 to 1.2 as IF those are minor releases. (anyone that uses java knows the 3rd digit has been the minor one) The 2nd number has so far been treated majorly by Sun's releases and I would NEVER call 1.2 or 1.3 or 1.4 a minor release, they have years between them.
As for large footprints, I stopped complaining about even M$ abuse of memory after the price came down so much. Just go buy some more. Its a valid issue, but I wouldn't mark it as worth of writing a letter.
Finally I'd like to ask why none of his bug numbers appear in the Java BugDatabase on the javasoft website
http://developer.java.sun.com/developer/
I'm skeptical of this letters validity.
but our top geek's are working on this really cool feature.......
(Iam not a troll)While you are correct about the power usage of Java, I believe that you are wrong about php. Yahoo has stated that they are going to start migrating to php. I can't think of anyplace else to describe enterprise web apps that would be bigger than Yahoo.
http://news.com.com/2100-1023-963937.html?tag=lh
http://slashdot.org/article.pl?sid=02/10/29/205223 9
http://www.techweb.com/wire/story/TWB20021030S0009
I know nothing about Java, except that, like perl (and perhaps python), I hate the sprawl.
As a system administrator, I'll use /bin/sh first, and php-cli if I need greater functionality. Preparing php is not trivial, but once it is prepared, it is a single binary that I can place (and replace) in /usr/local/bin.
In any case, whoever submitted this memo knew a great deal about the Sun development hierarchy, the Solaris bug tracking system and the Java bugs within it, Solaris development committees, etc.
But we cannot discount the possibility that Microsoft obtained this information through low-level corporate espionage, and posted the memo for reasons of their own (perhaps to impact one of the many legal issues that they face).
Granted, this probability is low, but it is not zero.
Java isn't primarily a web scripting language like PHP. In fact, the less Java I see on the web the happier I'll be.
Applets are dead. They never lived. Java is an application language, not a scripting-hack (much unlike PHP which is very web-centered. Do they even ship a stand-alone interpreter on win32 anymore?).
I'll also have to disagree with another poster who felt that applets were "everywhere". I as good as never see applets on the web.
I'm not a java fanboy or anything, but come on, applets and the web is 2% of what Java really is.
Belief is the currency of delusion.
Comment removed based on user account deletion
Java is a general purpose programming language, PHP is not. PHP is a scripting language designed for server side web scripting. Ever tried writting a server in PHP? You can't, it doesn't let you accept incomming socket connections.
Ahem ...
socket_accept()
socket_bind()
socket_listen()
Taken from User Contributed Notes on php.net (author diogo at michelangelo dot edu dot br )
Who in the world thinks they need to learn all the libraries before they can start programming in Java??
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
How many business experience points does that ake?
Why won't Bush just tell the UN to go fuck itself and start killing brown people? It costs me $50 to fill up my SUV! We need to go get our oil that those godless iraqis are holding under their worthless mudman country.
the facts of the message are indisputable.
Shrinkwrap Java applications are extremely difficult to deploy when the client is already relying on some other Java version.
Client commonly balk at downloading a 40 Meg "patch" release.
Please provide a countercase if you do not believe this.
Facts are the only things that matter.
Conspiracy theories are for idiots with too much time on their hands.
Thatnk you, this has been added since I last read PHP docs (4.0). I notice that this is still marked as 'Experimental' though...
I am TheRaven on Soylent News
as other posters have said: its clever & subtle, but almost certainly a hoax.
/.
the real question is who made the hoax and what were their motives? The timing of this may have been designed to hurt Sun especially since Sun is making big PR noises tomorrow according to the banners on
'Be the change you want to see in the world' - Al Gore
The memo has nothing to do with Java. It is typical of how software development takes place in large organisations. One team is having problems using another teams tools. They believe the tools problems with the tools can be better addressed if the tool team works within the same software development framework as all the rest of the teams. (Every organisation gets a pet team/project at one time or another, that does not play by the rules. In these cases the project is eventually brought back in to the fold, it is killed or people see the value of it and change the rules for the better/worse)
I think you are right... just look at the recomendations:
We strongly recommend that management require Java to conform to the Software Development Framework especially from the standpoint of ARCreview. Both PSARC and LSARC have dealt with the Java issues peripherally, recognizing numerous problems but unable to effect change in the underlying source of the difficulties - namely Java. By bringing the Sun Java implementation through ARC, these issues can be resolved.The question is, will this solve Java's problems?!
I am all for open developement. But I don't think that what aiming for.
GNUstep is the answer to a cross-platform Cocoa. That's the whole point of it. In fact, already there are programs (GNUmail.app) that compile "out of the box" on both Linux and Mac OS X thanks to GNUstep.
Unfortunately, everyone "forgot" about the less-glamourous GNUstep when GNOME & KDE got going. Pity, since GNUstep really is the better way to go.
Hey, folks, calm down. This is a memo from a couple of developers with their hair on fire, writing a purposefully inflammatory internal memo to get attention.
(Which they have done. I wouldn't be surprised if they're having a rather painful meeting when word gets back in Sun that this got published externally.)
I used to be a Sun Java Architect and I worked on both internal and external projects on both Solaris and Windows. I posted a lot of bug reports myself, and got some of those "will not fix" replies.
What these guys are primarily complaining about is not that Java isn't good for some things, but that Sun developers have a perpetual problem that they're almost always the cobbler's children that go barefoot. As someone else mentioned, the Windows implementation of Java seems to get priority for most things -- although, as I recall, the advanced Hot Spot optimizer was available for Solaris first (makes sense, the x86 instruction set architecture is such a pig.)
But there is a second thing going on here that you might not undderstand, which is that ever since Scott began to push Java, the old C/C++ programmers have been scrounging for reasons to us C instead of Java. Sometimes tht's appropriate, but a lot more often the difficulties are the result of someone trying to write C in Java.
In fact, this memo describes several problems that are clearly just such problems: for example, the notion that a Java-based shell should fork a new JVM for each command line execution. This is the natural way to handle the problem in C; fork()/exec() was invented for this. But it isn't the appropriate idiom in Java for exactly the reason they describe -- it means starting a whole new JVM, which is expensive. (The appropriate idiom, by the way, is class-load by name and invoke a method.) As I understand it the 1.5 JVM will have a extension that will make it easy to create virtual address spaces within the JVM for running sub-programs, which is probably a response to the issue.
The most important thing the memo is pointing out really is a problem: the freakin' language and evironment changes every time some propellor-head gets a slick idea. I posted a couple of days ago complaining about just this in the case of the for(String s: c) idiom and a couple of other such things in 1.5. This, and the way things break between Solaris and Windows, and among minor version changes, really is a problem that makes developing large-scale, multi-version applications in Java difficult.
"It turns out that Sun does not eat its own dog food."
It turns out CmdrTaco doesn't eat his own dog food, or read the posted articles...
"Specifically, this internal memo from Sun strongly suggests that Java should not be used for Sun's internal projects."
They are not talking about Java per se, but about the JRE implementation on Solaris specifically, as anyone who even read the first four paragraphs would notice. I quote:
"We all agree that the Java language offers many advantages over the alternatives. We would generally prefer to deploy our applications in Java but the implementation provided for Solaris is inadequate to the task [...]"
"More interesting still, they go on to state which other languages fullfil Java's goals better than Java does itself.
They use several Java and non-Java JVMs on various platforms for comparing memory footprints. All of the non-Java languages mentioned in the memo address a different goal set and "target market" from Java.
"Finally, the memo states Sun's own Solaris is the cause of many of Java's woes."
Aargh. Solaris is fine, it's about the JRE implementation on Solaris that they complain. Read the article, maybe?
"Yikes."
Four out of four sentences in the summary substantially wrong: FUD, FUD, FUD, FUD.
"Yikes" indeed.
Sadly it would appear our illustrious leader is having an off day. whats that your saying? Whoa there "Gullible Moron" is a bit harsh surely... but wait .....
if he is constantly posting dupes => he doesn't even read his own site => he probably didn't scrutinise the story......
;)
so i guess my real question is "CmdrTaco; can you read?"
'Be the change you want to see in the world' - Al Gore
Has got it all wrong again. Sometimes I wonder if this guy actually reads the articles he summarizes.
The article has nothing to do with the implementation of Java, or its viability.
HELLO???...people, some of the largest sites on the internet is built with Java.
The point of proving Java's viability happened A LONG TIME AGO...and it passed with flying colors.
Java is widely used in a large number of very sites both in public and internal use.
The reason why it is used is because it works, and works very well, which is why it is so popular.
The article however, does point to the fact that since Java is so portable, it has different problems on different platforms, all of them TRIVIAL, which can be easily fixed.
Where Taco got the idea that Java isn't viable, or to make a sweeping statement that Sun "doesn't use Java" and has said Java isn't viable, is simply not true.
-Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
Read about it here.
It seems that CEOs who spend all of their time beating their own drums are far less effective than ones who spend their time focussed on their business while they beat on everyone else's drum.
In short, visibility and effectiveness are opposed.
Cheers,
Ben
I like Java a lot, and I like to see that Sun realizes the biggest problems of Java. It gives me confidence that they will work on the mentiones issues and fix them.
The bad side of the memo is that it will certainly be misused for marketing purposes by the Java bashers.
Signature deleted by lameness filter.
One other point from the article:
Hello World written in Java2 requires 9M for this most basic support infrastructure. By comparison, this is slightly larger than automountd on Solaris8. The Python runtime required to execute Hello World is roughly 1.6M.
I found this interesting because this is a key reason why I personally favor Python over Java for my own projects.
I'm also curious as to how the IEEE article came up with a "rough parity in performance". Java > 1.3 seems to be more on par with compiled-to-machine-code languages in terms of speed.
One consideration with Python is that a lot of the computationally intensive operations are implemented in the underlying C code - for example, I did one benchmark once that showed massive amounts of string concatenations to be much faster under Python.
This concept is applicable for lots of python code - essentially, we do "manual hot-spot optimization" by rewriting the heavy stuff in C.
I "sniff" two main arguments out of this article:
...but based on something less proprietary). Heck we have graphics cards dont we!
1. is that java is not reliable: eg: inherently unstable (understandable b/c its a complex problem), AND this memo exposes some of the design issues over the progressing releases of java (which they actually classify as bugs (not in runtime or anythiing, but in usability and maintainability).
2. is the performance aspect that they are whining about. (both timewise, and memorywise).
Well....for the amount of garbage collection and optimization that goes on in a JRE (like the HotSpot (tm) and what not...)its not wonder that its "big". Sheesh, it took 30 years to figure out primes in P http://www.cse.iitk.ac.in/news/primality.html , and what? its been less than 10 years since gosling has managed to convince sun that java is worth it.
Anyway, theres a reason python and eiffel are more stable...they do less optimization. Please don't argue that python is anywhere near as fast as java. The computer language shootout, OR just experience with both languages can tell you this.
Anyway, I think that ultimately, computers should have something like a co-processor for bytecoded languages. Everyone needs to get together (like the now-dying parrot project), make a SOLID standard for a bytecode and for a hardware implementation, and sit back and enjoy the ride (eg http://www.ajile.com/
Finally,if sun is bailing, im sure a CS department/thinktank will pick up a grant and continue with java in a completely non-proprietary fashion (java *is* open source, just too proprietary to conflict with GNU and what not... (not like im a gnuru or anything).
Im sure theres something im forgetting. thank ya.
-- -- --
Help my mini cause: My journal
I've programmed for a few years in Java and for a few years in C and C++ and in my opinion, Java is just not worth the effort.
Sure, it'll enable feeble-minded programmers to write code and help them not worry about nasty things like memory and pointers, but in fact, if you ARE an accomplished programmer, you don't need that kind of a crutch anyway.
I know it's very politically-correct to keep lowering the bar for everyone, but I seriously believe that there are a huge number of programmers out there who should be working as plumbers or opticians, and who basically jumped onto the IT bandwagon when it was hot in the 90s or because it was cool in our present decade.
Software quality is NOT going up, it is going DOWN. Why? Because many no-too-gifted developers are jumping into computer science as a career, and Java is just the very embodiment of that; a poorly thought-out language with glaring engineering and architectural lacunae.
I don't know the meaning of the word 'don't' - J
How do we know this is even a real internal memo? I mean, this is comming froma site *named* internalmemos.com. Come on! There's a submission form. I could just send any old thing in if I wanted. The only difficult part is making it look convincing. That only takes a few hours of effort. Anyone that has an axe to grind with Sun could have sent this in. That could be some big company or (far more realistic) some random slob that just wants to be mean. Or it could be real. But who cares? As the Score 5 AC pointed out, this is about bugs in the JRE on Solrais, not necessarily about Java in general. Does anyone on slashdot remember what FUD is?
please
I first saw this story on the inquirer - See:
The article and
my letter in response
-- Thorin sits down and starts singing about gold.
InternalMemos is notorious for running hoax emails. This email is no exception. It includes a number of inaccuracies and curious references. The comparisons with Python are just amusing. Doing a quick search on the names, you'll note that there's no reference to the sender anywhere in Google, let alone associated with Sun. Most of the folks in the CC list do not have Sun email addresses. They're probably friends of the hoaxer. The Sun folks in the CC list include a JavaOne and a guy who has himself on the J2ME JSR. I wouldn't hold out for Sun switching to Python. haha
Just imagine a stack machine with huffman-ish operators
Everything about this memo sounds as fake as can be. For example:
Sun complaining about the JRE support model for internal projects...THEY ARE THEY JRE SUPPORT MODEL. It would be a bit like Ford recommending people don't use Ford parts for internal work because they'd have to go to Ford to get support for them. Eh?
Listing off the memory footprint of various "demo" applications. The "Hello World" reference gives this away as totally bogus. Anyone who's used Java knows about its memory consumption. From day one people understand that it is not recommended for smaller applications. That's not the intention of Java, and it's not a recommendation or warning Sun would ever make internally. Java is excellent, perhaps better than anything else, for interoperable, server-side, cross-platform development. The claim that there are "better languages for that" is totally bogus. Show me another single language that packages object communication, database-independent persistance, compile once, reliable threading, and hundreds of other Java features, while being available on every major (and most minor) operating systems and platforms available. An external user trying to take Java down a notch (perhaps a disgruntled C++ developer?) would almost certainly point at the size of a "Hello World" application. BTW, guess what: Hello World compiles to a couple kB of Java code. If the platform uses 9M for a small program, that's not part of Hello World's memory footprint. How much memory does a compiled C program take (including all external libraries and the kernel itself) compared to its compiled size? The holistic difference is striking.
The numbers about startup time and third-party application time. Why on earth would Solaris care if TogetherJ takes a long time to start up? If TogetherJ is written badly enough that it consumes 900MB of memory, then it's a failing of Togethersoft, not of Java. Too many Java developers have fallen into the trap of "memory is cheap, objects are garbage collected" and use truly gross algorithms in their software. A little common sense would reduce the footprint of some of these applications down to much more manageable levels. One should look at Java applications that do extremely well with regards to memory management, for example JBoss 3 and Eclipse. Eclipse provides one of the best, cleanest, well designed Java IDEs out there, and starts up into around 25M on my system. JBoss is a fully J2EE-compliant container, and starts up into about 32M on my machine. Compare that with other offerings.
Backward compatibility across minor releases. Everyone familiar with Java knows that 1.2, 1.3, 1.4, are as far from "minor releases" as they could possibly be. There's absolutely nothing "minor" about them. The small compatibility issues that are listed in this document are almost certainly issues someone would face if they move from one level to the next and use deeper features of the JVM. The concern about Class.fields() is ludicrous. It changed after 1.1 (about FIVE YEARS AGO, PEOPLE) and hasn't changed since. The other two complaints are about UI behavior changing across major versions (1.3 to 1.4 and 1.2.2 to 1.3.1). Guess what...they're going to introduce improvements into UI behavior to improve the performance of the platform's UI as a whole. The interfaces did not change. The contracts between classes did not change. If someone's tables ended up looking a little different (boo-hoo, perhaps this is a Java UI developer who's out of his league) then you either recommend one major revision or another, or you format your UI in such a way as to prevent problems (not a difficult thing to do with Java's UI support). These gripes more than any others point to this being a fake: Everyone outside of Sun knows that 1.2->1.3->1.4 are not "minor revisions" and would never treat them as such. There's NO WAY Sun would refer to them in that way.
Other issues are also well known to Java developers, and are easiliy avoided:
JNI is unstable: Well duh...anytime you link out of the JVM you are dependent on external code for reliability. If the external code bloze or doesn't behave, guess what...you crash. Sun recommends not using JNI unless there's no other way to solve a problem, and wouldn't list this as a fault.
Vitria: 450+ containers? What in holy hell are they doing with 450+ containers? Running a single component in each one? No reasonable architecture would EVER use this many JVMs on a single machine. The person who recommended this should be shot, and the person who wrote this obviously fake memo is looking for worst case scenarios to support their arguments. Regardless of Sun's marketing, companies with alternative languages and platforms would not be buying on if the platform itself wasn't so powerful. Would IBM have blown $1B+ developing Eclipse if they thought Java had unsolvable issues? Not bloody likely.
JSSE referred to like a distant cousin: JSSE is Java's Security Extensions, and although the article is correct (it was formerly a plugin, now included in J2EE) it is referred to as "an external module called JSSE" and never once listed as a security extension. Does the author of this "memo" not know a primary, core technology that Java uses for security? Someone is extremely ill-informed, or has nothing whatsoever to do with Java.
Ultimately, even if this does turn out to be an internal memo, I'd wager it's from a lower-level developer on the C++ side of the company that is angry (or worried) about the push towards Java-based applications over native languages. You can bet your ass this isn't a company-wide, high-level memo, because it's simply not true. How about this scenario:
1. Internal Sun employee NOT involved in Java becomes disgruntled about getting fewer new projects and more maintenance and support work.
2. Employee starts to monkey around with Java, either to nitpick well-known faults and flaws or to gain a better understanding, hopefully to get an "in" on new Java-based projects
3. Employee finds enough nitpicking details to write an "internal memo" recommending Java not be used, or get frustrated that they can't learn the entire language in a day and does the same.
4. Employee writes said "internal memo", hoping to stir up some discussion
5. After the employee's claims are shot down, much like I did above, the employee gets even more frustrated
6. Employee "leaks" the memo to stir up bad press for employer. Since the memo appears on a site where "accidentally" leaked memos appear, employee can feign ignorance.
Everyone jumps to conclusions on these things. Don't believe everything you read. Java is a spectular language...anyone who has used it for any length of time knows that. The people who have never used it on a real-world project are routinely its biggest critics.
Quote from the internal memo:
"Executive Summary
While the Java language provides many advantages over C and C++, its implementation on Solaris presents barriers to the delivery of reliable applications. These barriers prevent general acceptance of Java for production software within Sun. 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.
Within Sun, the institutional mechanism for promoting this sort of communication between partners is the System Architecture Council codified in the Software Development Framework (SDF). We propose that the process of releasing our Java implementation will benefit from conformance with the SDF."
Let's assume for a moment that this is a true internal memo. If it is, then it actually points to a good thing. I would rather have a company take a hard look at it's own problems than pretend they don't exist.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lost Sheep to Shepard, you got your ears on?
please mod this up
Confidential to Sun developers: You must not use our software!
Paint me confused.
When u have a gig of memory and no other programs running in the background..why doesnt sun work harder, they love to point fingers for all their problems, they never say, "whoops WE made a mistake we should've worked harder on the JRE, made it less of a memory hog, we will now try and fix that, if not lets make it open source so other people can try and correct it"
For The Best Jazz/Hip-hop fusion > COlD DUCK
I think it has been overlooked that the memo only refers to Sun's implementation of the JRE. For my Java development I've always preffered IBM's implementation which is considerabely faster (several comparisons have been made in the past) and IMHO more stable.
There are, of course, other good implementations of the JRE which work better than Sun's. To me, Sun's JRE is just another option, and does not imply anything about Java in general.
- encrypted calendar components (so you don't have to trust your ISP or our servers).
- free client and server
- multiple simultaneous color views of calendars for instant conflict resolution
- multiple language support (Hindi, Japanese, Chinese screenshots available)
- It renders fast enough even on my slow 400MHz Celeron (though the 3D works best on faster CPUs)
- It includes real-time 3D graphics animation
What's really important is that the application is secure and is updated with compressed diffs via Java Web Start. A link on its unbeatable security (with lots of Slashdot links embedded) can be found here: http://www.ScheduleWorld.com/itsYourLife.htmlSchedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ (Java Web Startable)
One ofthe problems the article talks about is having to make the choice of which java runtime to have on your system to run all of your applications. .NET supports side-by-side execution of the framework. Machines will have the .NET 1.0 and when 1.1 will come out both can be installed on the machine. If you have a 1.0 applicaiton it will use 1.0. If 1.1 is on the machine it will try to run in 1.1. You guys can go to MS's site and view how this works...
Is it just me, or does anyone else think that Sun could have sampled opinions from 100 Solaris administrators and used the results to produce this report about two or three years ago? Most obvious is the long section about Java's horrible performance, something that Solaris users have been complaining about for a very long time.
On the upside, Sun has given Python a real boost with this memo. Perhaps they should switch all their admin tools from Java to PyTK, it would definately be faster than waiting for SMC to start, which takes too long on any Sun box, even the fully-loaded Blade 2000s I use at the office.
Just as the article states...one only needs to look at python as a vm implementation done right. I am not a perl dude but I would say that perl is a good implementation also, the syntax is ugly but it is efficent..
Got Code?
I have been working on a project since 1998 that implementes a "Thick" Java client and uses a J2EE (WebLogic) server implementation on Solaris. As for the client you can check it out for yourself at http://sirtf.caltech.edu/SSC/propkit/spot/
You can see from the download page that the client runs on 3 platforms (Mac will be available as soon as OS X gets its act together) and does an excellent job of it. As for the server running on Solaris, BEA spent time optimizing the JVM to improve its performance on Solaris. An interesting note: The client JVM is 1.4 and the server JVM is 1.3.1 (with WebLogic mods) and there is a shared code base between the two. We compile all of the code with 1.4 and run it on Solaris with 1.3.1 and have not seen any problems with execution or client/server communication.
Use the right tool for the problem, not the same to for every problem.
you can't convince me that Enron et. al. were just a couple of bad apples.
I can be convinced that the sky is green and grass is blue if you give me sufficient evidence and a valid argument. What you are admitting to here is closed-mindedness.
Answer me this: how many corporations are there in the United States? Be sure to account for Schedule C, Schedule S, and LLC-type corporations.
I don't make the rules. I just make fun of them.
This document appears to come from a group of frustrated Solaris developers in Sun corporate, and "sounds like" it would be used in convincing upper management to put more pressure on "the Java group" to fix items that are real performance killers.
I think from the sound of it, it should turn heads within Sun and cause the Java to be improved on Solaris.
As someone else said, this isn't a move to another platform, this is a plea for improvement based on a well-stated set of concise problems.
I think this is a hoax as well -- it isn't terribly well written, and the author mixes up complaints and example 'failed implementations'. To summarize: there is no silver bullet when programming.
...offerings written in Java?
...sigh... I don't think I've read a more contrived piece of fluff in a while.
1) "We believe that our Java implementation is inappropriate for a large number of categories of software application"
- the categories are never listed.
- having a server run 500 client applications will obviously chew up memory.
2) "Bugs against base Java aren't fixed" (paraphrased slightly)
- all products have maintenance lifecycles and a lot of problems are not worth fixing in a (for example) 1.1.8 VM. This is why you test your application properly before deploying it...
3) "The support model seems flawed" (Java apps depend on the JRE).
- Most commercial Java apps will ship their own JRE. Some even ship with a JDK. Software shops with half a brain realize there are going to be incompatibilities and as such pick a VM to work with early on. If they have to switch late in the development cycle it requires significant QA. This isn't rocket science - you'd have the same problems if you depended on some 3rd party library, regardless of language.
4) "It is impractical for a project based on Java to correct bugs in the Java implementation"
- true, but it has proven itself stable and effective in many environments. Especially for server development...
5) Why are the shelves at CompUSA not crammed with
- because it's not cost effective to distribute software in stores when most people interested in your product can grab a copy directly from you, the manufacturer.
- because people don't go to CompUSA to buy an application server or a web application.
6) "The JRE is very large"
- it depends on what you're doing with it. No, it doesn't make sense to rewrite binutils in java. If this is your goal, you'd be better off keeping a JavaScript engine in memory, or going with a persistent reuseable VM like what IBM does with CICS. Sorry, I don't think IBM builds one for Sparc at this time...
- a 64 bit VM will be bigger than a 32 bit VM. It isn't clear which versions are being compared, nor is it clear what applications are doing to generate heap sizes of 900MB. It would be more interesting to compare the ratio of Java heap and process size.
7) "Imagine what happens if...all 150 users on a SunRay server were running one Java program"
- imagine poorly architecting a solution and blaming the hardware for your lack of foresight! Should this letter not be a hoax, I have sympathy for the individual -- clearly there are PHBs at work here...
8) "It is not backward-compatible across minor releases".
- examples cited were from 1.1 VMs to 1.2, 1.2 to 1.3, and 1.3 to 1.4. These are *not* minor releases. I'm sure there are examples of incompatibility between a 1.3.1_03 and 1.3.1_07 VM, but anyone upgrading or switching VMs for their application should be paying attention to the bugs fixed (see point #3).
the two projects, WXWINDOWS and the SDL both add the functionality to c++ that had me previously using java, and have it be fast. Another big downer for java has always been how it is strictly controlled by one company.
Won't you be my my neighbor?
We do not believe these flaws are inherent in the Java platform but that they relate to difficulties in our Solaris implementation.
Also, many of the stated problems are slated to be fixed in Java 1.5...we'll see.
In the meantime, support gcj or the IBM implementations...on other platforms. ;-)
Another snippet:
We all agree that the Java language offers many advantages over the alternatives. We would generally prefer to deploy our applications in Java but the implementation provided for Solaris is inadequate to the task of producing supportable and reliable products.
Don't throw out the baby with the bathwater.
And of course, now that I read some of the replies, I see it may well be a hoax regardless. Sigh. (Disclaimer: I've never used Java on Solaris, only Linux and Windows.)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
but not on Solaris afaik. Maybe someday IBM will release a Solaris version of its JVM, (which is faster and more stable than the Sun JVM.)
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.
Not sure about memory usage, but gcj, despite being a native-code compiler, produces programs that run significantly slower than Java-bytecode programs running in IBM's JVM.
May we never see th
This memo is clearly indicating that the problem isn't a fundamental flaw in the JVM, but rather a flaw in Sun's development process for the Solaris platform. It sounds like what's happening here is that Sun's Java people, realizing how many more people are using Java on Linux and Windows, aren't putting as much effort into support for Solaris. Since upgrades of Java are released simultaneously accross all platforms, there's no opportunity to make minor bug fixes for OS specific problems.
My read of this suggests that they have a very simple solution to their problem. Release their iron grip of the product and open source it. They could reduce their internal development costs and people could support patches for the multiple OS versions that are out there. Let anybody develop JVM's, and then they could make money off a certification process. They could develop new versions of the API, hand those to the community, and then certify the implementations when complete. That process would still allow for each implementation to do it's own bug fixes without substantially disturbing the consistentce between JVM's.
This sig has been temporarily disconnected or is no longer in service
PHP's database connection pooling is fairly pointless.. the persistance only lasts as long as a single request.
Completely false. The connections persist for the life of the server thread. Go RTFM.
- Java is type checked, so you know when you've made typos/passed in the wrong sort of arguments to a function. PHP will just carry on (sometimes without even giving you an error). This makes your life as a developer much harder as you need to undertake a lot more testing.
PHP has types, and is optionally type-checked. Use the type-equality operators (exactly like Perl's eq/==). It's a text-processing language, so it interpolates to text by default.
- Java can be just as quick as a C program as it is able to use run time optimisations etc.
Prove it. Would this be the same Sun JRE that mmap()s over 1GB for each of its threads on startup?
- PHP's database api is terrible. To convert from using one database to another all database related function calls need renaming. In Java it is just a case of changing the connection url.
Sure, if you're an awful programmer. Use the DBI from PEAR, or roll your own. Not all databases have identical functionality; PHP gives you the freedom to use non-portable features, like Postgres' lo_* functions.
- PHP has no real OO features - it's inheritance structure can only go one level deep
PHP has n-level inheritance. Try:Maybe you meant nesting one class definition directly in another. That would have been a valid point; it's addressed in PHP 5.
- PHP cannot scale as far as Java, as it requires a new process for every additional request
PHP runs in the threading model of the web server. Zend is completely thread-safe. Moreover - if you're on any sane OS, the difference between process and thread creation is a small amount of VM overhead to switch the memory map.
As for the OO/Exception features, they're both in PHP 5 CVS, and I'm using them right now.
Your post is as bad as its parent. You're an uninformed language bigot who really needs crawl out of the basement and try to get laid. I'd rather have you embarassing yourself in private than out here.
Maybe they should switch to Micosoft's "implementation"...
Your post was excellent, but your effort was in response to a blatant troll. Next time, post it on its own.
This is the same site that posted the fake id memo. Is their record besides that one mostly spotless? It seems no one here is doubting whether or not this is real.
Class.forName(/*Database driver class name*/);
If you haven't done this explicitly, your frameworks certainly have.
- I don't need to go outside, my CRT tan'll do me just fine.
Proof less, mean less, ....
.net ? Are you kidding ... what i can assure you is that MS do use Java internally even if is strictly forbidden by internal rules.
.net clone that they can erect as their good-will wishes to. .net at this time is not such a big success, and if within the next month MS do not stop Java they will have a major trouble ! Because .net could became a FLOP ...
What is sure is that MS fear Java and try to massivelly FUD the Java platform !
Sound fun to see misterious contributors pushing such ideas ! Sun using MS stuff
MS knows that Java can at middle-term damage his OS monopolism by providing an intermediale platform they can not control !
That's the reason they quit the Java project to build the
Time is ticking !
More managaement, process and bureaucracy will not make a better jvm for solaris. Anyone who thinks so is a manager, process bufoon or high priced management concultant. In this case, it is a power hunger process bufoon.
I have no sympathy for the java team at Sun. Sun always has and always will produce shitty software. The number of open bugs on the java platform is a joke. Personally I have seen thousands of dollars wasted on bugs that have been open for over a year. The refusual of sun to devote resources to fix these bugs is a clear indication the company is broken.
It is widely known that many java resources left sun and joined IBM a few years ago. Sun is not known for being able to keep good engineers happy. The creator of bitkeeper, verdisoft, nexsi are just a few of the well known examples.
Sun's inability to produce software can be seen in the failure of iplanet, primitive and buggy tools in the jdk, ant failure of forte for C++ and Java to eclipse.
Regarding runtime size:
Hello World written in Java2 requires 9M for this most basic support infrastructure [...] The Python runtime required to execute Hello World is roughly 1.6M.
Ouch!
The JRE is significantly larger than comparable runtime environments... For example, on an Ultra10 "Together" requires 5 minutes to load and start.
That's basically the problem. Sun's Java implementation is buggy, huge, and slow.
This isn't an inherent problem with the Java language. It's primarily a library problem. Java comes with an immense and growing library, too much of which is loaded for simple programs.
Java ought to have a small, rock-solid basic library at the bottom, with additional, optional, packages. That's not what they've got. When "Core Java" grew to two volumes, it was clear Sun had lost control.
Much of the trouble seems to be in the user-interface end. The painful transition to Swing made Java programs bigger and slower. It's no accident that the most successful uses of Java are in the servelet area, where Java's GUI code is not used.
It's sad. The beginnings of Java looked really good.
I read the memo and its completely different than the Slashdot synopsis.
Saying "that Java should not be used for Sun's internal projects" is not anywhere in the memo. Apparently the implementation on Solaris is just bad.
What a drag when the moderators put their own spin on an article discrediting a technology unfairly.
Quotes from the article that show you didn't read the letter before posting it:
"these issues are not inherent to Java"
"We do not believe these flaws are inherent in the Java platform"
"We all agree that the Java language offers many advantages over the alternatives."
"The customer must locate that release and install it." That, IMHO, is complete BS. I never keep anything but the most recent version installed, on Windows or Unix. The only issue I have ever seen like this was with JHDL from Brigham Young, which used "assert" that was added as a keyword (due to customer requests) in 1.4 -- and it still works if you tell it to compile as 1.3 (javac command-line option). I personally would not support an outdated version when a version with bug-fixes is available for free.
"Typical resident set requirements for Java2 programs include: Hello World 9M" Again, BS. I have a TINI board running that only has 8M of memory total, AND I have an old Handspring (8M) that has Sun's JDK and IBM's JDK and Java3D on it.
"Each of these examples is simple, but they demonstrate the general problem that people cannot program for a particular release of Java and expect that their programs will continue to run." Again, BS. I have been coding Java since IBM released JDK 1.0.2 for Win3.11.... I have never had this problem with ANY code I have written.
And their overall request? "We strongly recommend that management require Java to conform to the Software Development Framework ".
If you would have read the letter before posting it, you might have realized that what they were really complaining about was Solaris 7 and 8. They even point out that Solaris 9 is fixed. The pieces of the letter that suggested other languages was specific to the Solaris implementation, as my comments above prove that their statistics are not valid outside of Solaris.
So, Solaris pre-9 is buggy. Big deal, that has nothing to do with how fit Java is as a language.
Malachi
http://www.google.com/profiles/malachid
My experience is that java is faster than Python, but that speed almost never matters for me.
Don't kid yourself -- PHP and ASP are the same dogshit with a different wrapper.
This is the first time in the history of Slashdot where I would like to moderate a whole story, Mr. Taco !
/. !
It puts the linked article in a completely wrong perspective. Who says it is not a hoax ? and it has only to do with the Solaris implementation!
Better read things more accurately to avoid incorrect stories on
I'm one of those people that hasn't bought into the hype yet... Someone try to sell me.
I've disliked Java since I first met it. What's the attraction, beyond the billions that Sun has poured into marketing it?
I've been called in as a consultant on three different jobs in the last year that wanted to know if I could impliment a project in java. I said "Sure, but why?", and every time, they stared at me like I was swearing in church. But no one could explain why. And they all took hours to convince that a C implementation was going to be faster, cheaper to develop, and use less resources, both development and runtime.
Slow, with heavy-handed controls on the reference implementation, non-native binaries, and sub standard culture-enforced methods of doing everything from builds to deployment... What's the draw?
I've long believed that Sun, a hardware company, should have taken their Java team and spun it off completely as JavaSoft Inc., as was contemplated in the mid 90s. The consulting and development teams would have one objective: furthering the Java platform. Doing so would have made this memo, if it is legit, a non-issue from a PR perspective. JavaSoft probably would have made the same decision on where to focus their efforts: on making the Win32 JVM implementation the best, and supporting other OSes secondarily. That's what this memo is about: pissed off Solaris admins who are tired of sitting in the back of the bus when it comes to Java. Before the advent of the web applications as the platform of choice for developing new applicattion, and even since, Win32 is where the money is because of the wide install base. (I won't go into whether monopolistic forces caused it; for a software company, you just have to accept this as the current lay of the land.) Obvioiusly the Win32 JVMs get the most development resources, and rightfully so (with Linux probably a close second, thanks to IBM, who wrote their own JVM). Unfortunately, Sun didn't do the spinoff completely, and now people want to see this as a "rift from within" and "Sun not eating its own dog food." I want to reiterate the point that others have made, because some of the early posters missed it: the problem highlighted in this article is with the specific JVM implementation for the Solaris OS. It is not about the failings of Java as a language, J2EE as a specification, nor interpreted vs. compiled applications. Java will be around for a long time to come, particularly in large environments, as evidenced by most major application vendors supporting it (Oracle, Siebel, SAP, PeopleSoft, JD Edwards, etc.) and by the fact that most academic programs are switching to it. In fact, this year for the first time, the high school AP test for programming will be in Java, not C++. It is here to stay because it is a decent enough OO language.
By the way, python is legendary for it's bad performance, only Tcl has an even worse reputation. If Java really is outperformed by python, that would be a reason to kill the whole project and shoot the guilty party.
About memory footprint: here is the memory footprint of tcc, which is a tiny C compiler for x86, so you might call it an x86 JIT for C. tcc can also be used to create object files and link them to binaries if you want, so in that respect it actually does more than that Java JRE. It does not have garbage collection or a security manager, but it can do bounds checking.This includes a C parser, a code generator, and a JIT. And it's still just over 600k for a hello world style program.
Also, just because Sun chooses to redefine "minor version" in their newspeak, that does not become the new meaning of the term in English.
Java is a toy language, and always has been. It is a shame to see so much good talent being wasted on in at universities and colleges all over the world. Other languages are also toy languages, but at least they aren't so pretentious.
Comparing the two is a crazy as saying Mozilla is far better than Linux.
But it *is*!
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...
Not that it doesn't contain a lot of truth - I just think it's a fake.
pr0n - keeping monitor glass spotless since 1981.
Their primary concerns may be about Solaris 7 or 8, but they certainly have more fundamental concerns regarding Java. For example, about modules:
I am tempted to quote the rest of item #3 of "Defining the Java Problem" for you here, but that would merely annoy those who have actually read the article rather than skimming it. These are not Solaris-only issues, are they?
Their fundamental reasoning for writing this memo may have been concerns with the Solaris implementation of Java, but I think they raise some very good points w.r.t. Java in general, and whether or not you wish to debate virtue of their complaints, statements such as "The Java system for evolving the interface (deprecation) does not serve production software very well" clearly are not Solaris-only issues.
It would seem to me that they talk mostly about Solaris because they are Sun employees primarily concerned with the success of Sun and its Solaris platform. That makes sense. Clearly they also suggest that the Solaris JVMs in particular have had inexcusable problems and a lack of support and responsible managment, but your statement that "what they were really complaining about was Solaris 7 and 8" is a rather broad generalization, wouldn't you say?
As I have been programming primarily in C for the last year, I have not struggled much with the idiosyncracies of Java for a while. Don't get me wrong. I love Java. But I think this article raises some really good issues, and honestly, makes me worry about the fate of Java when its creator can't even make it an acceptable language platform for their own internal application development.
I have no special gift, I am only passionately curious. --Albert Einstein
oJava is used in more than half of all development projects. Python does not register on the scales. It's a true scripting language and not meant for real world heavy-duty applications. You won't see it running the company apps anytime soon. Most people like it because it us fast to develop with - fast dev does not equal fast execution, stability, or capacity.
As to a 9M hello world in java... In M$ C#/C++ there are tens of megabytes taken up by the dlls and other junk running in the OS. The 9M in java is actually a much smaller footprint.
As to speed, Java is kick butt fast. Those that think it is slow, do not run bench marks. I have been writing Java almost eight years - would I if it were slow or buggy? I have seen a lot of slow Java! Mostly from programmers that don't use their brains. The number one problem is heavy use of Vector and Hashtable. A simple switch to ArrayList and HashMap will fix part of the problem. Removing them where they are not needed is the real key.
As to GUI speed and bugs, this is mainly caused by IDE tool. Semantic and Borland are the worst! Ninety percent of the problem is all the useless and replicated init code. In a couple hours I can make any IDE generated code run 20 times faster.
M$ would do anything to discredit Java. The question is, are you too lazy a developer. If you can't write good code in any language, it is time for you to see programming as a hobby and not something that it is worth paying you for
.
The least clever bit is the part which asks why the retail channel (198x) hasn't yet been saturated with java titles and then goes on to say that because of solaris, java is mostly known as a web language.
Time to switch to the D Programming Language, from Digital Mars which doesn't suffer from any of these problems.
Isn't it ironic that this article on Slashdot is followed by an ad for .NET?
who wouldn't dream of deploying any software with their own VB Package and Deployment Wizard.
We were somewhere around Barstow on the edge of the desert when the drugs began to take hold. - HST
Clue: people were touting that Java was great for this sort of stuff 5 years ago.
Clue: at one point in time a 366mhz with 96 meg of RAM was a good machine for pretty much everything else in vogue *except* building GUI stuff with Java.
Clue: I'm running some Java apps on an 800mhz machine with 384meg. They're slow to start up, and slow to run. Slow under Linux with Sun JVM, slow under Windows with various JVMs. Slow with 1.3, and slow with 1.4. In comparison to *any* native programs (anything under Gnome, KDE or Windows) they're just slower. And it's often suprisingly slow when trying to run server-side stuff too.
Maybe I should just get a clue and just go get a 2ghz processor and a gig of RAM, right? It's so cheap, right? Then when Sun releases the next version of Java, I'll just upgrade my hardware again to take advantage of all the great enhancements (read: 'bug fixes' and 'new bugs'). Excellent idea!
It's rarely mentioned, but Sun is a HARDWARE company. What incentive do they have to make stuff optimized to run more efficiently on existing hardware? *NONE*
creation science book
Well, this is certainly more fuel for the long-standing argument "Why I Hate Java".
Unfortunately, it's part of the curriculum at my college. Let's not even get into the fact that they change textbooks every semester because the current one isn't "adequate" enough.
Love and Peace,
Valen
"The best compliment a girl ever gave me was 'Your hair smells nice.' I hate being the platonic friend." -Valen
Yeah, it's a fake. I work at Sun, and a quick LDAP search lets us know that Sun doesn't employ a Julian S. Taylor. Geez, I wish f'dcompany.com would check this stuff out before they post it. Actually, I wish /. would check this stuff out first...
-Jon
"In a 32-bit world, you're a 2-bit user. You've got your own newsgroup, alt.total.loser." -Weird Al
believe me, this is aa great hoax, hahahahaha :)
Sun uses java for more things that it should.
The typo in the parent post confused me at first (spelled correctly the first time, wrong the second). Furthermore, there does not appear to be a psyco package in Debian.
To clarify:
psyco is the name of the Python specializing compiler. The Psyco project homepage is:
http://sourceforge.net/projects/psyco/
pysco, on the other hand, is a group of python modules for composing music. More information about pysco is available here:
http://www.slinkp.com/code/#pysco
I could not find a package for either of these in Debian.
This article is a giant vat of uninformed bullshit.
I won't address Java 1.4x points because in general, java 1.4 sucks. (Handicapped threads, new io architecture forced on installed base, inept standard regex and logging facilities, bah)
Java on store shelves: The fast majority of companies use java to model internal business processes and integrate them into systems. Java is extremely useful for this because programmers don't have to worry about hardware. This is not the kind of software you shrinkwrap.
TogetherJ/TogetherSoft: The installer asks you if you want to install a JDK with the product, or use a separately installed one. It also will tell you if your installed JDK is sufficient.
Python: Python source is compiled into bytecode upon first interpreting. It has it's own VM, also mutable from native code. There are quite a number of differences between python and java, but your comparison is uninformed.
Java Minor releases: The differences between 1.2 and 1.3 is quite large. These are not minor releases, despite sun's versioning scheme.
JNI Stability: JNI isn't easy to produce correctly. But it's stability is a responsibility of the programmer. C programmers don't blame the OS when a program segfaults.
I guarantee had this article been about perl's deficiencies, it would've been scrutinized with a scope large enough to see Venus, and wouldn't have made it passed submission.
no WONDER Sun wants so desperately to force Microsoft to ship their version of Java.
this ia hoax and all lies by M$
Microsoft just announced that .Net server is written in VB 6 and CLR is written in VB 6 ...horray.
It's surprising that a company that has such skills with distributing a mission critical, highly available OS (Solaris) doesn't enforce the same practices across the development of something as complex as the JVM.
Pud has a good reputation.
Good? Pud has a very seedy reputation. He's a slimy opportunist who provides a useful service. He runs a rumor site where bitter workers vent their anger. Take everything you read with a big grain of salt.
But regardless, the trust of Pud has nothing to do with this. Is he a Java expert? No.
Is he an expert on internal Sun politics? No.
He just runs a website: People post things to his website, and if he likes them, he will post them to internalmemos.com or fuckedcompany.com or some other related site.
It'a rumor mill.
"Can of worms? The can is open... the worms are everywhere."
1. Release false memo. /. - to find out developers thoughts on the JRE.
2. Wait for it to be discussed on
3. ???
4. PROFIT!!
when everything is working perfectly.. BREAK SOMETHING before something else FUCKS up!
Bill Gates : Well our petstore bench mark stuff in the ServerSide.com back fired so lets do this publish a hoax memo from SUN and send to slash dot all lies about Java. ehehehe (I am so smart)
.Not acceptance is zero in market ..did you all use VB6 on .Net server too....
By the way
PARENT POST IS A TROLL
1 result returned.
what good stuff have you been smoking?
so only a fool or a masochist would use it for simple text manipulation tasks (ever written a CGI script in C?)
Yes, I have. And surprisingly, it's not half bad.
libcgi and glib make things much easier than you would expect.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Regardless of the authentisity of this document, I have been thinking alot about the startup time of java.exe. I use ant, javac, tomcat, etc all day and it kills me that ant takes 20 secods for a 600 millisecond task. The heavy lifting involved with creating the jvm and tearing it down kills me. java (the executable) should be written in platform dependent ASM or C code. It should run as a service at startup and fork jvms as necissary. A persistant reusable jvm would make ant (and other small utility apps than start and stop frequently) fly. Why has work on a shared jvm like JOS and Echidna not flurished? Always on JVM discussion
I use and admin Solaris systems every day, at work and at home, and in itself it's a great product. But its biggest problem is Java. More and more stuff is being java-ised, resulting in absolutely horrid performance.
Examples: the SunScreen 3.2 commandline. Takes ages to load or do anything, especially viewing your firewall logs. Sun Managment Center: It does not perform. It becomes completely laughable when you try to display the screen on another Xserver. This is how Sun was demo-ing it at Lisa2001, and although the lead developers over there agreed that it didn't perform, they blamed this on Swing but had this scary religious fervor when it came to doing things in Java.
The new patch-managment tools from Sun? Nice idea, very flawed implementation. Sloooooow, and so buggy that we ditched it, prefering to keep our Suns up to date by hand.
Java installers are another fun item. Sun has a very nice packaging system, which makes it possible to jumpstart machines with identical software configurations etc. But more and more software becomes 'java installed'. It does not add any functionality apart from a badly drawn gui, but it breaks all the convenience of having one standard packaging tool for the os.
Please stop this madness.
Duh.
The server is exactly the place you DONT want to use a language like Java. On the server you need to handle very large numbers of connections with exceptional processing speed.
Although Java -is- used on servers for a majority of application service provider services, in my humble opinion, it shouldn't be. For server applications only very fast and efficient languages should be used.
I find it contradictory that there was such a rivalry in early speed comarisons between MS IIS and Apache, then people turn around and use Java?
And, why do you need a cross platform language for a server? Again, use a faster language.
+2 cents contributed.
Where I work, we use NT and Linux (and in my case OSX) to develop on, and Solaris for deplyment. Personaly, I find it VERY handy that I can compile something and move a class file between boxes, and even better have a basic level of certainty that a program working one way on one box will work in a similar manner when deployed to a different environment.
Java's portability is real and works. There seem to be a number of peeople who either think it doesn't work, or isn't useful... but to me they seem like they have little expereince with the subject.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Java does OK at high loads, especially when you can offset the greater resources consumed with clustering.
However, if you take a look at most enterprise applications you will find they are not high load (thousands of hits a second) at all, even for large businesses. There are plenty of internal apps that are very well served by Java beacuse the ease of development gives you more features and a more stable system.
One of my favorite sayings is "Premature optimization is the root of all evil". That doesn't just apply to programming - also to hardware and language choices as well! Make something work, see how many users actually use it, then figure out if it needs to be sped up.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
My school recently replaced a bunch of dual boot windows/linux machines with some Solaris workstations. All I can say is "What the fuck?" The damn things are running CDE for gods sake.
I was waiting in line the other day to use a 'burning station' where you can get CDs made for site-licensed software, and I tried using one of the machines. It was ridiculous. The only browser they had was Netscape, and Java didn't even work! I mean, this is a sun machine!
Solaris may make a good server OS, but for a desktop OS I'd rather stick with windows or Linux.
autopr0n is like, down and stuff.
Python is dog-slow compared to C++, inherently. Implying that it somehow isn't, or even worse, that it can be faster, or still worse, that it can be massively faster, strikes me as silly.
Is it legitimate? I first saw a pointer to this a couple of days ago
on fuckedcompany.com. That's hardly a ringing endorsement of
legitimacy. Even if it real, is it significant? Not clear.
It looks to me like mostly an attempt to get attention. I have to
admit, somewhat reluctantly, that I used have to write memos along
these lines when I worked for a company that ships a prominent
application server. The fact was that there were only two ways to get
attention focused on problems that would keep us from shipping our own
product on this app server: 1) Find the developer responsible and
persuade him to fix it or 2) Get one of our executives to yell at one
of their executives. Often the second approach was the only one that
had a chance of working and it required memos like this (complete with
specific bug numbers, sweeping generalizations about the support
structure, dire warnings about the future and so on). This is
corporate politics at its "finest." Quite the technique for building a
close working relationship, eh?
Some of the points about application-specific JVM version requirements
and footprint have merit (even if they're overstated, in my
experience), but generalizing this to "Sun does not eat its own dog
food" seems difficult to justify based on the limited examples shown
here. How much of Sun's software is actually written in Java, for
example? And if Java is such a problem, why has the app server market
been growing so quickly?
You Boys should refer to FUD.
.NET is not going anywhere, it will die in 1-2 years.
.NET is more than C#. I say, .NET is dog food!
FUD == Fear Uncertainty & Doubt
Whos behind it? The usual suspect, Microsoft. Why?
I like C#, but since threres no C# for Linux, its useless. You might say but
As for the talk about Solaris, well Solaris, like any other UNIX Operating System, are now years behind Linux. I my oppinion the current SuSE LINUX is the best ever UNIX ever made. You might say, but SuSE is not American. Thats right! If it was made by Americans it would be called RedHat, a crappy distribution since version 5.0.
Well lets stop talking and do some work!
I think you're missing the point.
RAM is cheap. People's time is not.
Java allows you to be a better programmer.
This type of self criticism is exactly what I would expect to see from a group that is striving for excellency.
This is really a blow to the Java platform in general. Everyone kinda knew the implementation had some showstopping bugs, and the recognition of that by a Sun manager is going to get people shying away from the technology.
What.. you say that its only the Solaris implementation? Well, anyone looking to deploy a large J2EE site is usually going to need a high end solaris system to serve it. And if its eating up huge amounts of memory for no good reason, it's going to be a huge problem and possibly a show-stopper.
If you've tried to deploy a large j2ee project using linux as your OS, you've doubtlessly run into major performance/memory problems also.
My point is simple... Sun, quit hyping up Java as the end all solution to enterprise development if you aren't going to provide a decent JRE to run programs built with the framework. Or at LEAST put the spec's out there and encourage groups to build their own JRE implementation (I'm sure the jakarta group would pick up a project like that very enthousiastically).
That Free Software has succeeded so spectacularly at cross-platform portability, without any of the extraordinarily expensive and risky apparatus needed to run Java, demonstrates further that Java and its apparatus are not necessary to get the benefits the language has been sold on, and mainly just mean overhead.
Gross overhead is good for hardware sales, but only when there's no credible competition from more efficient alternatives.
Okay, I concede that C is pretty adaptable, especially if someone else has already written a library aimed at the kind of task you're trying to do. I would be interested in seeing how much C code you had to write, and how much PHP could have done the same job. I personally find that a hybrid C/PHP works quite well, with C generating the information and PHP formatting it nicely.
I am TheRaven on Soylent News
Here. Previously mentioned on Slashdot here.
The memo may or may not be a fake, but many of the peformance issues mentioned in it are real.
To a Lisp hacker, XML is S-expressions in drag.
Right. We should outlaw everything except raw machine code, that you enter directly in binary. Assemblers are for pussies.
A typical nonsense Java zealot response followed up by a second clueless Java idiot who "validates" it with a +1.
Java not only lacks the runtime abilities of Lisp (where code and data fundamentally the same), but Java is a staticly typed compiled language to boot. So it's the worst of all worlds. You use javacc to build and then you run the result in an java interpreter. Of course it's a slow to run memory hog!
Use a real dynamic language like Scheme, Lisp or Python instead of this flavour of the day tripe called Java.
"You're an uninformed language bigot who really needs crawl out of the basement and try to get laid."
He may be an uninformed language bigot, but your reference to his living in a basement and the idea that having sex somehow makes you a better person reflects badly on you. Too bad- you were doing ok up until that point.
graspee
Stupid amateur produced toy language.
When (new Long(4).equals(new Integer(4))) returns true, maybe I'll give it a second look.
Or not. Smalltalk is soooooo much more productive.
This is just an example - but Java is fundamentally flawed on so many levels that its hardly worth explaining to its self flagellating users why they're perpetually over budget and late.
This is not a troll. Java sucks, and object oriented languages suck, too. All the "good stuff" of OO detracts from the main purpose of the computer, which is to 'do the job'. After millions of lines of code written in the last ten years of my life, I reached the conclusion that the programming language is irrelevant.
So, I mainly do everything in C these days and I am twice as productive as anybody else(of course, with a little help from my own libraries that does basic stuff that C doesn't have).
Well, to be honest, I don't know PHP so I can't be qualified to make a comparison. I will say that I loathe to write simple CGI scripts in C, and defer to perl (like PHP) because it is an easier excercise, and no Makefiles required, :-)
What you find is that when you need to tie together unfriendly APIs, do device manipulation, and do heavy lifting, the C implementation can be comforting.
I wrote a 4-script cgi app in C that acts as a front-end/configuration tool for a hackneyed backup solution for windows boxen based on samba and tape archive metaphors. Another was a secure utility for maintaining non-ASCII docs in a CVS style hive.
To be fair, a small army of perl scripts do maintenance tasks outside of the cgi code's control. But that code (and some accompanying utils) are all C, about 2500 lines total.
I have been moving away from C recently, and towards perl for my rapid CGI development. I have done a similar thing where I push the C into the background, into daemons and utils that the perl script manipulates from the front end; acting as a sophisticated "display" layer. So, I feel that this must be a common POV.
Do investigate libcgi, it can save you during the times when you want to bolt a web front-end to an existing C/C++ code utility./C
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Comment removed based on user account deletion
...and if this memo is true, it's no surprise.
I was given the boot from Sun during the recent RIF,partly for my refusal to become a Java fanboy. I objected to Sun's stupid reliance on Java for everything (Constipated? Try Java!). Their internal Java apps were so disgustingly slow and crashy, it's not difficult to believe the memo. That and the "amusing" reference to Python demonstrates the real lack of direction within Sun Microsystems.
God Speed, I say to them, I have my cheque, I'm happy. But Java is so often a technological dead end these idiots insist on galloping down.
It's about freaking time!!! Anyone who's ever gone to the trouble of starting down the java path by figuring out which text book to buy can tell you that it's obvious even without downloading a JRE that the language gets updated too frequently in incompatible ways for it to provide real portability.
:-(
We use Oracle on HPUX - Oracle always requires a specific version of the JRE.
We also use Oracle Applications on HPUX, which relies on java - but a 16GB box quickly chokes and falls over when each java process consumes upwards of a gig of RAM and reserved swap space.
If sun (and HP, for that matter), would focus on their own platforms, maybe others would have some faith in those platforms instead of stepping continuously over to winblows.
With every release, Sun breaks something that worked in an older version. Swing in 1.4 blows up all over the place where 1.3 worked fine. If the failures in the latest JRE don't affect you, then you can use it. The place I work for runs into this with every release we make. We have to pick one version and say we only support that because other versions have bugs. We also don't have the QA resources to make sure we run on every single version. We're not the only ones. BEA WebLogic still does not support JDK 1.4, even though it's been out for over a year and is approaching the second minor version update.
"Typical resident set requirements for Java2 programs include: Hello World 9M" Again, BS. I have a TINI board running that only has 8M of memory total, AND I have an old Handspring (8M) that has Sun's JDK and IBM's JDK and Java3D on it.
Just because there's a Java implementation that runs on a small platform doesn't mean the one that runs on Windows or Solaris isn't grossly overweight. IIRC, running something not a lot larger than Hello World on 1.4 for Windows takes about 12M. That's a stupid-big footprint and there's a feature request in-process to fix it.
47% of all statistics are made up on the spot.
Why is the College Board changing the AP Computer Science tests from C++ to Java next year?
Sigs are gay.
It's my server.
autopr0n is like, down and stuff.
Case A) Lets say you use native coce. You have a 1000 things want to do on a 1000 platforms. That's a total of 1 million programs.
Case B) Now lets say you use a p-code which runs on a virtual machine (like the JRE) as in intermediate step. Then you have 1000 things you want to do on 1000 platforms . Then you have to make 1000 platform specific VMs + 1000 programs that run on the VM. That's a total of 2000 programs.
Add a platform or a program to Case A and you are looking at 1000 pieces of software which need to be written. Add a platform or a program to Case B and you are looking at 1 piece of software which needs to be written.
That's really the argument for using a p-code / VM system. OK now why Java?
Java has C++ish syntax without offering the platform specific enhancements. So you can make a strong case for Java vs. C++.
Here is where I personally think the case breaks down. IMHO once you agree to take the performance hit I'd go much higher level like Perl, Python, Mathematica, Lisp...
i don't get this.
one can easily dynamically load code, and that can be a class, in compiled languages.
-pyrrho
Anybody can write bad code. It is particularly easy to write bad C++ code and fall into the common traps, such as lots of hidden object instantiation issues, for example. Besides, I can always put empty loops all over the place and made hand-used calculators faster than a program :)
Python is dog-slow compared to C++, inherently. Implying that it somehow isn't, or even worse, that it can be faster, or still worse, that it can be massively faster, strikes me as silly.
He didn't say Python is faster than C++, he said an app he wrote in Python was faster than a really badly written older version of the app that had been written by somebody else who didn't know what they were doing in C++. Yes, this is possible.
Mozilla 1.21 is much faster than Mozilla 0.7, and they're written in the same language. Why do you suppose that is?
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Lisp has one of the best object-oriented paradigm implementation, Meta-Object Protocol among languages with both scripting and bytecompiling capabilities.
Scheme has been proved as a good language for GUI and configuration: GIMP, Sawfish, TeXmacs.
OCaml has all the power as Lips, just in syntax conviniect for many Java/C-poisoned brains to read faster. No wonder there are many real-world applications on it.
Haskell... I just love how it demonstrates that OOP is not everything (and even not enough) :)
Sun works for telecom industry - why not consider Erlang?
And don't ignore Mozart - it's multi-paradigm pradigm might be just what we all will thing as the best in 3-5 years.
The list is not complete, of course. And it's inspired by Functional Programming.
My main point here is: each of above languages, would it be in hands of Sun marketed instead of Java (with all that money invested to), would have quality of implementation much better than Java.
In fact, I am impressed how such poorly designed language as Java succeed so far on the market. It wouldn't without so much money behind. And without so many classes written by Sun to compensate the poor design of the core language itself.
Would Sun invest so much efforts and money to FP language then the result would be much better. Because quality is why FP matters.
Less is more !
Damn, this place is really turning into a huge pile of conformity-ware shit. Average age? 17? 16?
Sorry for saying something true in response to something that was only FUD: the idea that this fake memo thing will tarnish Unix. Duh.
Strict obedience to the law is the key to liberty.
Java is Dead, .NET is the future. If you don't want M$ to own everything, join the Mono project today! It's no one's fault but ours if M$ takes over with .NET, because it is a superior platform. We must embrace it or be left behind.
To the naysayers:
Port a fast I/O and CPU intensive native application to Java, and watch it crawl miserably and gobble all the memory you can throw at it.
Develop a CORBA/XPCOM/ONC-RPC system, and watch how difficult it is to maintain and extend.
The future platform of hope is Linux running Mono. The highest performing OS running the CLR, potentially the highest-performance VM.
ralvek
I am a former Sun employee and I wrote these kinds of memos.
Specifically, I wrote that Java was unsuitable for Sun's own web development projects, and that this represented a serious problem in terms of missed opportunities to improve our software and for our public relations and marketing.
The memo may be a fake, but it's right on target. I especially agree with the problem of internal tech support for critical bug fixes.
I worked on several projects that were a nightmare due to subtle bugs in Java's HTML and XML classes. In each case, the bugs were easy to fix: a few lines of code, changing private methods to protected methods, etc.
The response from Sun support? "Will not fix."
So I had to rewrite the classes-- basically rederiving the entire Java HTML+XML parsing tree-- which stuck the customer using my custom code. Talk about a bad upgrade path!
There were many, many examples of this. As a result, I deployed many projects using Perl on Linux instead of Java on Solaris, and I wrote internal memos like the one in this article.
All that said, the Java engineers were some of the smartest, nicest people I've ever had the pleasure of working with. I have a lot of confidence in them, and each Java release gets substantially better and faster. The problem IMHO is not the engineers, but the corporate culture that misses opportunities to learn from employee projects.
The Sun engineers and internal developers can really do some amazing things, if McNealy and Zander could start prioritizing Java inside Sun, and start funding rapid-turnaround tech support for employee programmers.
Cheers,
Joel
Why Java sucks , written in 1997, but some points still hold true.
I have also noticed that Sun's website doesn't use jsp very much (or if they did, why won't they display the .jsp extension?). So far, all the forms I have only found submit to .cgi, which normally indicates that it's not a Java backend. Compare this with Microsoft's site which uses asp pages (even it's just for show, at least they are using _something_).
I'd like to submit this as Exhibit T in the "Slashdot needs a -1 Plain Fucking Stupid moderation category" case.
Seriously. The "GINORMOUS" 9MB you talk about includes the JRE which can be used to run pretty much anything else you care to run.
Serious business (as in serious about making & handling money) will not be at Solaris 9 for another year or two yet....Solaris 9 is too young for all the needed patches to come out. Heck, all the places I've worked & consulted for are largely at Solaris 2.6, with 8 being tested.
Are there open source Java bytecode runtime engines?
There surely must be one out there for Solaris...
Another screw up by the moderators. This
post is informative. The problem is, it's
political. Whenenver you tell the truth:
C is faster than Java, it gets scored -1.
Whenenver you cry about it: "oh that FUD,
java rules!!!" It gets scored +5.
The java weenies just can't handle the truth.
It makes more sense to view this document as a plea to those in higher power to pay attention to the direction that Java is heading. It's abviously on the downhill but I think that if Sun was to spend more time fixing current bugs instead of providing more features (this reminds me of someone else I know... M$ anyone?) Java could be a platform that could prove to be cost effective to develop high end software for.
Being a wanna-be programmer, I noticed the impracticality of JAVA simply by writing a few small programs and trying them on various systems. On Linux, they would, for the most part, run well, on Windows, they were SLOW and GROGGY - on SUN, they were also a little slow... keep in mind that the LINUX and WINDOWS tests were done on the same machine!
Sun should concentrate on the current problems and that would be beneficial to everyone!
just my 2cents
The quote I've used I've seen in print many times - I've almost never seen anyone say "better in the enemy of good enough" (I think I have heard a quote that is the reverse of that though).
The original poster was asking why use Java at all, instead of assembly (or something like that). My point is that for a lot of needs Java is plenty fast enough for a lot of real world enterprise apps, even on older boxes... and if speed of executation is going to be fast enough for the final program why not get all of the proven benefits of Java over a potentially faster, but more risky language platform?
I agree that architecture and design descisions are something you want to think through up front. But that is NOT the same thing as deciding you're going to use C++ with in-line assembly for an app that might serve ten users. That's (to use another old saying) "putting the cart before the horse".
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I have written large Swing apps that worked quite well against Windows and other platforms - and that was back in Java 1.2 just after it was released. On 32MB machines.
Mutimedia I'll agree is not that great with Java yet, you are probably still better off going native there.
GUI though - I think that works pretty well already across platforms. There just aren't a lot of people that seem to be able (or willing) to use Swing very well. Frankly, I can't imagine a GUI I'd rather have if I needed to have heavily customized controls.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Empty loops? Ha!! I'll match your empty loops and raise you one optimizing compiler!
> Thatnk you, this has been added since I last read PHP docs (4.0).
WTF is your problem? Why lie about it? Look, if you don't like PHP, just say so. Posting out-right lies about the language is a bit childish. accept_connect(), bind(), close(), connect(), listen(), socket(), and strerror() have been in PHP even *before* PHP V3 was released. Why the outright lie about it being added since V4.0? Go away troll. I just wish the moderators had more clue than to keep adding points to your trolls.
> You can't, it doesn't let you accept incomming socket connections.
Moderators on drugs again? Why would a post with out-right lies like the above get a +5? The first version of PHP3 we used was 3.0.6. It supposed socket connections, and we've been using it in production since.
This is a power grab by an internal Sun committee. It's riddled with scaremongering and concocted reasons why the ARC should control Java. It's a sign of deep malaise within Sun.
internalmemos.com has address 66.40.105.34
[localhost:~] % host sun.com
sun.com has address 64.124.140.181
Who runs the class C IPs 66.* & 64.*? I question ownership & operations of this media delivery (the report critical of Java) & bandwidth provided.
A corporate memo is just that. Java is Sun's thing. It's their brand. What does Sun have to say about it? This looks like one group having very specific complaints in specific build environments based on Sun's product. Meanwhile elsewhere Java development continues to make sustainable cross platform support happen.
I don't know anything about who this group is or the specific core projects they're developing... It's like another blog page complaining about lack of features or quietly promoting specific features developed thru cross-channel blog communication with other techbloggers. That's normal but why does slashdot have to post *this* page on Java?
Looking beyond strictly corporate governance, what do we care for a project run by corporate personhood (not speaking of Java ) when opensourcers can do a better job hacking script like Java in more dynamic profit-oriented environments, time worked paid for by the chill hours system (work along I/school/friends schedule) not the colonial-imperialist corporate policy hours system only (9a.to5p. M-F)?
-Anonymous Slick
Oh good grief. The memo may or may not be fake. Java does have some design problems, and some inherent ones. Not everything in the LONG list of Java libraries is a object.
More importantly of course a scripting language is faster than a PROGRAMING language it's the scope what it triest to do, SMALL text maniplation programs in Java 1 and 2 are faste enough to not make a fcuking difference. Java is a interperted language so if this ape knew that he'd also know that even at 1/4 the execuion it's in esence going 4x as fast, and for fuck sake if you need pure speed is the C language mode OR HotSpot mode of the VM the SUNVM is not the fastest beast it's only the most compatible, and the Swing libraries improve execution speed (Though the repaint methods still stink).
Since this idiot doesn't say any of that he hence HasNoClue, and do not include #him.ever*
A study performed by an outside team appears to indicate a rough parity in performance between Java and a common implementation of another OO language called Python (see IEEE Computing, October 2000, "An Empirical Comparison of Seven Programming Languages" by Lutz Prechelt of the University of Karlsruhe).
This article does not exist in the IEEE Explore database
if it's a contest between Java and Solaris, and for Java to be perfect I have to think Solaris is buggy, then I still don't think of Solaris as buggy.
-pyrrho
My old comp sci. professor used to talk about the difference between "speed" and "efficiency". A quicksort program written in basic, running on a 386 machine, can for sufficiently large datasets, outperform an insertion sort program written in assembler, running on a Cray.
Most really big performance wins (like the 100x example) don't come from using a lower-level language or fancy compiler optimisations. They mostly come from a more efficient design.
sigs are a waste of space
wtf, mod system screwed up?
Having sex does make you a better person. It makes you more relaxed and more pleasant to be around.
"Having sex does make you a better person. It makes you more relaxed and more pleasant to be around."
YOU ARE SO FUCKING WRONG! YOU ARE ETH IDIOT! I HATE YOU DO YOU HEAR ME? I HATE YOU! SHUT THE FUCK UP ALREADY! GRRRRRRRRRRRRRRRRR!
graspee
Please try to keep posts on topic.
Try to reply to other people's comments instead of starting new threads.
Read other people's messages before posting your own to avoid simply duplicating what has already been said.
Use a clear subject that describes what your message is about.
Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)
Please don't try to make that into the next /. meme. Let's have some class, eh?
Java rules and all these lies would make any difference. .Net sucks and it is dead..take that Billy.
Open mindedness is one thing. You are something else. Please stop helping me.
With regard to your sig, I happen to know some people who do HIV research. The hard kind, not the bullshit public health kind. They are not liable to be swayed by offers of money or other blandishments from the Eeeevile drug companies. And they are far from stupid.
The arguments cited by your web site are unscientific crap, and are getting a bunch of innocent people killed in Africa.
Evidence? There's a measurable, linear relationship between HIV virus load and the onset of full blown AIDS.
AIDS appears in the presence of HIV, does not appear in its absence. You can even infect experimental animals and they get it. Transgenic mice, for example.
That is known as Koch's Postulates of Pathogenicity. Look it up, it is the method used to identify and isolate pathogens so drugs can be made to fight them. If your pet web site has anything substantive enough to pay attention to, you'll be able to prove at least one of the postulates wrong.
If not, time to re-adjust your open mind. Remember, if you can't measure it, it ain't science.
On OS X, virtually all the IDEs written in Java (JBuilder, Eclipse, NetBeans, etc) feel solid and more responsive than many of the Carbon applications (written in C or C++) like MS Office and Macromedia Dreamweaver, the only exception is Oracle JDeveloper which is totally unusable. JBuilder is particularly powerful and probably better than any IDE on all platforms except perhaps the OS X combination of Project Builder and Interface Builder. Surely this proves that there is nothing wrong with Java at all, at least not on Mac OS X. As a C++ programmer for over 10 years, I recently switched to Java and feel much more productive.
The memo is either very old or simply a fake, particularly wrt the memory footprint - the resident set of JBuilder is typically about 70 MB even after weeks of continuous usage. In any case, if there are genuine issues with the Solaris implementation, Sun should put more effort to deal with it. After all, Apple and IBM have done a wonderful job, so could Sun and others.
Can somebody post a copy of this? My company blocks the site as "illegal". LOL
Zeinfeld wrote:
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.
DNS-and-BIND wrote:
And this is different from Clinton HOW exactly? At least the current occupant of the White House hasn't been disbarred or impeached. He didn't smoke pot, either, though he was a champion drinker.
Absolutely correct, there is no difference whatsoever. By design.
And here, ladies and gentlemen, lies the crux of the matter: The US democracy is for show. The two-party system gives the american people the illusion of a democratic process. The truth is, no matter if you vote Democrat or Republican, the same group of people (or, at east, the same kind of people) stay in power. Whether it is large corporations, media magnates, the CIA or any other group is irrelevant but left as an excercise to the reader for extra credit.
This section of the memo was, for me, the most interesting:-
In earlier Java releases there were useful APIs that weren't available in the core, such as XML/XSLT, JNDI, Swing, etc.. but for application developers like me, it was straight-forward enough to distribute these extensions with applications that needed them. Sun's policy of bloating the core with all these Java extensions is actually harmful to Java. For example, Sun's official explanation for putting logging facilities that were inferior to Apache's log4j was that there was a JDK 1.4 Merlin release deadline to meet. Same goes for the stunted XML API's in JDK 1.4. Why can't these extensions grow, evolve and mature outside the Java core? As long as they're easy enough to distribute, do they need to be part of one big release?
What the Sun engineers are complaining about is that a change in one of what could be hundreds of extensions breaks the entire platform. To try to prevent this, Sun have imposed 'draconian binary-compatibility rules' which are a sure way of prohibiting refactoring and major improvements, bottom line: Java bloats and innovation effectively stops.
Either Java needs to use it's own extension mechanism more consistently, or to create one that is more flexible/usable and more open to third-party code. How many times have you needed a particular version of xerces, xalan or log4j in the classpath? (or found out your customer has a different version that the one you built with, and this is the cause of that subtle and evasive bug)
It's not just the Solaris performance/memory aspects of Java that are a problem, it's the very way that the technology is distributed and evolves. I've had a lot of fun/success with Java and want it to continue getting better. Congratulations to the insightful engineers behind this memo.
Can anyone confirm that "Hello World" does indeed take 9 megs of memory space using JVM 1.4 on Solaris?
Java is a good language for server applications. Your points ignore a few things:
1). A cross-platform language is every bit as useful on the server as it is on clients. The main benefit is that I can do testing of Java servlets on my Windows desktop and have the application run exactly as it will under Unix, or the AS400, or wherever it is deployed. This makes it much easier to do good testing and debugging and makes for a more robust application on the server.
2). Java's performance is at its worst when the application first starts up. When an application is running there is little difference in performance between a Java app and the same one written in C. Java servlets load into memory once and stay there, so the startup penalty only affects the first request.
I've found this to be true on the client side too. I have created Java apps and run them on an old Pentium and while startup times were awful the apps were useable enough once they got running.
3). Java's garbage collection and avoidance of pointers makes Java apps more robust. A Java server app can fail without taking down the web server.
Not getting any, huh?
Disclaimer: my opinions are my own and do not represent any company or organization.
I worked as a JDK developer at Sun for a certain length of time (let us just say more than three years to continue to protect my anonymity). And no, I no longer work for Sun.
To respond to this menu (assuming that it is real), first look at the executive summary and sender information: this memo represents the opinion of a single person who is representing a specific group of people, in order to push a specific agenda: JDK conformance with the SDF, which is probably some sort of new program or committee body within Sun (or any industry-wide standard--anyone know what this is?). Now in order to "sell" people on this agenda, it is necessary to build up a case for Java to fall in line with it.
Now, let us continue to assume that this is legit and examine the case presented independent of the context, though keeping in mind that that is what this memo is about, not some "corporate-wide" opportunity for someone at Sun to bash its own technology. This isn't news: it's "dog bites man" at best. Java has bugs, Solaris has bugs, communication at Sun needs to improve, etc.
First of all, the "will not fix" problem is clearly an internal communication problem here (and a big misunderstanding on the part of the author of the memo). JDK engineers don't just close things as "will not fix" willy-nilly, or because they don't have the resources, or because they don't see them as serious enough bugs. I can recall on many occasions that engineers have been pulled aside, sometimes even during weekends or during critical projects, to work on critical Solaris bugs. Solaris has been (and I would imagine will continue to be) one of Sun's most critical software projects. Entire JDK releases have even been delayed at times because of serious Solaris issues. Solaris is important, period, and JDK engineers have a very clear grasp of this, contrary to what this memo may suggest. Simply listing a bunch of "will not fix" bugs doesn't mean anything. A "will not fix" typically means "read the fine print in order to figure out what is going on with this bug and why it won't be fixed." Every bug report has an "evaluation" section, and listed there (if the engineer is doing his or her job) is the reason for closing the bug out. Many such bugs are simply no longer applicable: discontinuing support of older versions of Solaris or motif are some possible examples. Other examples may be ludicrous or ambitious enhancements which will probably never realistically see the light of day: "support Java on the Commodore 64". Looking at this list, it's fairly easy to speculate where many of these bugs fell. I see a pattern of things here which were backward-incompatable that were probably closed as "will not fix" because the new behavior is seen as more "correct" than the old behavior. This is further evidenced by item 4 in the following section, as well as other such remarks throughout the memo (more on that item later).
Item 1 on the list appears to, again, be a communication problem. The author of the memo shows a lack of familarity with Sun's internal support process (including the Sun-on-Sun initiative). This could be a legitimate cross-management communication issue or perhaps just ignorance on the part of the author. This is evidenced by a number of things, not least of which is the mention of JDK 1.1.5 and Netscape running together which "has not changed for years." Anyone who has downloaded Netscape in the past 5 years knows that to be just plain wrong.
Item 2 is both flamebait on one hand, and on the other hand is entirely true. Memory footprint is an ongoing problem for the JDK, something which is addressed and paid attention to in every release. Yes, Java has warts. Engineers take these problems very seriously and are constantly struggling to improve performance. Solaris is no exception.
Item 3 again shows lack of familiarity, this time with the Java Community Process (JCP). The examples cited predate JCP 2.0 and are not relevant to the current state of the JDK on Solaris. How emerging technologies evolve as extensions and find their way (if relevant) into the JDK has been long since made clear by the JCP. The "lack of modularity" example of TogetherJ is an example of JDK modularity, not extension modularity, which makes it more relevant to Item 4, not Item 3.
Item 4 seems like the real meat of this person's complaints with Java, the appearance of Java being an "unstable platform." While backward compatability across versions is a legitimate complaint, it is scarecly a complaint about Java so much as it is an industry-wide problem having to do with the nature of software, though middle-ware is particularly vulnerable to this problem (something is broken, but somebody relies on the broken behavior, then you fix the broken behavior, the already-broken person then complains). The author seems confused about the difference between "major" and "minor" versions of the JDK, and in all of the examples cited these are differences between "major" versions of the JDK (so-called "feature" releases), and not "minor" versions of the JDK. While it is idiosyncratic of the JDK to never evolve beyond "1.x", it is not (to my knowledge) widely misunderstood among Java developers and managers, especially after the 1.2 JDK experience, that evolutions in the second digit are feature releases. The *third* digit is the minor version, wherein backward compatability is most guaranteed. These kinds of releases are called "maintenance releases." Furthermore, there is an underscore "_01," etc., which represents "patch releases," which are purely critical bug-fixes.
There isn't enough time in the day to have a full discussion of how to resolve the backward-compatability problem, but there isn't a single person I know of who complains that they can't put a 10 inch vinyl record into a CD player. Any decent software engineer knows that when a new release of some underlying technology comes out, it should be treated as a *new product* and should not be expected to run everything 100% the same as it did in the previous version. Anyone who makes the decision to blindly ship with a new technology without first running their product through a new quality lifecycle is just asking for trouble. Aside from JDK 1.2, personally I have found Java to be surprisingly backward-compatable for larger GUI projects, certainly compared to the world of Win32 development. Of course, experiences are likely to vary among developers on this, so I would gladly be sympathetic if someone wanted to flame me with their top "Java horror story".
Overall, I would say that this memo isn't informed enough to build a case against Java on these grounds. I have a number of complaints with the technology's shortcomings, with Sun in general, with Solaris, etc., but none of the items presented here really hit the mark.
JVM stands for Java Virtual Machine and is not a set of libraries. The main set of libraries is the JFC or the Java Foundation Classes. These are broken up into Swing components and AWT components.
- Kill Yourself, spare us all! -
Examining the site, I noticed no disclaimer. If this memo turns out to be a hoax and creators of the website did not properly shift the liability to the poster, the "RCK Group Inc." could face a mega-lawsuit from Sun.
Open mindedness is one thing. You are something else. Please stop helping me.
As usual, the response is mockery and invective, not dialog.
With regard to your sig, I happen to know some people who do HIV research. The hard kind, not the bullshit public health kind. They are not liable to be swayed by offers of money or other blandishments from the Eeeevile drug companies. And they are far from stupid.
And I happen to know some people who know that HIV is an orchestrated lie. See, I can make unsubstantiantiated claims, too!
The arguments cited by your web site are unscientific crap, and are getting a bunch of innocent people killed in Africa.
Yet you fail to indicate which arguments are "crap," you just dismiss them all with a sweep of your hand.
Evidence? There's a measurable, linear relationship between HIV virus load and the onset of full blown AIDS.
Are you discussing so-called "viral load"? There is quite a bit of criticism on this subject:
here
here
AIDS appears in the presence of HIV, does not appear in its absence.
You are merely quoting the definition of AIDS. How do you explain an HIV+ child born to two HIV- parents? How do you explain HIV+ children whose HIV mysteriously "goes away" as they get older?
You can even infect experimental animals and they get it. Transgenic mice, for example.
Yet you provide no evidence to back up your claim. Have other primates ever gotten HIV/AIDS?
That is known as Koch's Postulates of Pathogenicity. Look it up, it is the method used to identify and isolate pathogens so drugs can be made to fight them.
Has HIV been isolated? If so, who isolated it?
If your pet web site has anything substantive enough to pay attention to, you'll be able to prove at least one of the postulates
And interesting strategy: Find some criteria unrelated to the criticism and then declare that as reason enough to dismiss all the criticism as irrelevant. Furthermore, the web site is merely a collection of articles that have been written by many different scientists and journalists for many years. Your calling it my "pet" web site is an attempt to paint me as single-source.
If not, time to re-adjust your open mind.
I think, instead, that you should open yours. You've stated in no such uncertain terms that dissenting views of HIV/AIDS are beneath your contempt. Isn't this the very definition of closed-mindedness?
Remember, if you can't measure it, it ain't science.
I agree! I do not think that "HIV==AIDS" is science. I think it is money.
I don't make the rules. I just make fun of them.
"Yet you provide no evidence to back up your claim. Have other primates ever gotten HIV/AIDS?"
9 31.html These mice don't just catch HIV, they are sequenced to produce HIV themselves from birth. As you can see from the article, they get the same kidney damage as humans with AIDS, which the drug being tested apparently prevents.
What, you want footnotes? Ok then. Chimpanzees are infectable by the HIV virus but don't get AIDS from it, you can google that up on your own.
Transgenic mice with human immune system markers were INVENTED to research HIV. Here's the second hit I got on Google on the issue, http://www.aegis.com/pubs/aidsline/1999/jan/A9910
There are many transgenic mouse lines, some of them patented, developed specifically to investigate the connection between HIV virus and T-cell death. Some were invented where I went to school by people I know.
The argument about when the virus was isolated and by whom is CRAP, as the state of the art has advanced to the point mentioned above, a transgenic mouse that is making HIV markers and proteins on its own. Point being you have to know what those proteins and markers are before you can sequence for them.
Then there are the vaccines developed to fight HIV. There's one in trials now that looks like it won't kill everybody that takes it, no word on whether it kills all the HIV or not. However there was another vaccine that came out in the late 1980's that killed nearly everyone who took it. It worked by stimulating the antibodies to HIV. A subject with a good T-cell count and a low virus load would take the vaccine and shortly thereafter their t-cell count would plummet and they would have full blown AIDS. The trials were terminated after the first few subjects got sick. You can go look that one up too.
These are matters of public record, not some super secret stuff that nobody can get at. An afternoon of surfing should be more than enough to dispell any doubts on the issue. Unless of course you can't understand the evidence. Then you are going to have a problem.
As to my credentials, I'm a physical therapist and my wife is an internal medicine doc. I studied at New York Medical College where they do a load of AIDS reseach, much of it with transgenic mice. Some of our friends were kind enough to let me play in their labs and ask questions.
What medical school did you go to?
So you can see why I and others have a problem not laughing when you claim all of AIDS research is a vast conspiracy. You are getting invective and mockery because your claims are idiotic. Some ideas are just too silly to be taken seriously, and this is most assuredly one of them.
Do you have any idea how many people would have to be "in" on the secret if there really was a conspiracy? Thousands. Do you think thousands of people are all going to keep quiet about something that big? Come on.
So now, any progress on prying your mind open yet, or am I wasting my time on yet another fanatical partisan? I'm used to that from talking to anti-gun people about science. There is no logic, no evidence, no argument that can shake their conviction. Are you one of those?
(It uses the DynamicJava project internally, which is another Java source interpreter. I don't have the link handy.)
-brian, a former developer on the DrJava project