Slashdot Mirror
Java Rocks On Linux
Begonia writes "While we're on the subject of Java, I'm really impressed with its performance on Linux these days. I'm using IBM's latest (1.3) version of the JDK,
which has only been out for a couple of months. And I just stumbled across this latest set of benchmarks for various JDK's on Linux and
Windows here. Not dated, but must be at most a couple of weeks old. Lots
of very interesting food for thought."
Ah, ick. You will be *much, much happier* if you run-don't-walk to 1.3.0. I know that early JDBC had a lot of problems like you describe.
And GC in Java is definitely not suitable for attempting to prevent non-memory resource leaks.. even the finalizer mechanism won't do it, since it is not strictly analagous to the C++ destructor mechanism. If you need to prevent resource loss, you need to wrap your activities with a try bracket and use finally to clean up.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
to use a StringBuffer, but they won't do it for code within loops, like
which allocates a new String object for each iteration, creates a StringBuffer for the addition, and converts that StringBuffer into a String -- leaving you with two objects that need to be created, only to be immediately garbage collected for each iteration.
I posted some tips for optimizing Java in another thread -- many of the other replies in that thread are good as well. Have fun.
~wog
Why do people only mention speed when evaluating Java? Memory footprint should enter the discussion too. And unfortunately, Java on Linux seems to suffer from bloatitis.
A Swing app I am developing under JDK 1.2.2 for Linux uses about 20MB of RAM without JIT. It's not really that big a program. When I tested it under IBM's JDK 1.3 (prerelease), it ate about 30MB of RAM. With Sun's JDK 1.3 with Hotspot, it still uses about 20MB of RAM. Sun's JDK 1.3 tries to reduce memory footprint, but I am guessing that the additional overhead of Hotspot and native threading tends to erase this gain. It does start faster though.
When writing a Java GUI app, speed may no longer be relevant. Most of the time, the application is waiting on user input. My app runs just fine on a P166 on a JVM in interpreted mode only (no JIT). Any speed advantage in the JVM is not noticeable. But the memory footprint is noticeable, and this also translates to a long startup time.
I have solid evidence that Java is slow and cumbersome: The IBM Point Of Service system. I work at parts counter at CompUSA, where these units are used as cash registers. These registers are running NT4SP5 (strange, considering that there are USB ports on the units). The POS program used is entirely written in Java. On power-up, there is a scripted FTP session to download JPEG files used for instant advertisement. The monitor functions as a display of the receipt (to comply with a recent town ordinance to show the customer the receipt; I'm going to oppose this ordinance, since it only spawns more Java programmers). The keyboard latency (time you have to wait before pressing another key) is 150ms. If the enter key is pressed before this time has elapsed, a certain letter will appear (proving that the Enter key and Escape key are remapped in the program). In C programs, there is no keyboard latency. The thermal receipt printer (suspiciously named the "IBM SureMark") makes a stuttering sound when sent its data to print. During the test print/paper cut sequence, there is no stuttering, proving that the Java program lags when sending data. There also have been problems recently when the entire Java data files were changed; there is an option for what kind of CompUSA credit card payment method (so we can manually trigger the 6 month no interest plan), but sometimes (and this has happened at the damndest times), a credit card will come up with a message of "Use Another Tender," and it won't let the cashier enter in an auth code. This became annoying once because I actually had an auth code from the creditors!
So next time you say that Java is fast, just walk into your local CompUSA, and watch the cashiers cursing at the register terminals. The POS terminal program was coded by IBM's (snicker) Java (snicker snicker!) technicians (ROTFL!!!).
I am majoring in Computer Engineering at the Wentworth Institute of Technology in Boston, so I will have to learn programming. However, I have made a vow to learn C(++) as a second language. Maybe I'll learn Java, but it will have no place for me, since Java-driven drivers are the worst drivers.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
The only one I'll give you is XML support. Java probably has the best support for XML right now - too bad its general text-handling sucks.
I suppose all this affect benchmarks too; most readers today will be more interested in testes that show server-like workloads.
I think if my testes showed server-like workloads they'd rupture.
I would be a paid subscriber if Taco and Hemos weren't such cunts
Comment removed based on user account deletion
Perl is the king of text processing languages (no contest)
Any language X is the best at Y thread ought to result in the spontaneous combustion of the poster's terminal. From a technical standpoint, you could make a pretty strong argument that Icon is a much better text processing language (and a better language in general) than Perl, and that Oberon's Juice JVM is structurally better-suited to delivering high-performance platform-independent binaries. Of course, you won't hear much about them -- or dozens of other great technologies -- because developers seize on the first thing they like and congeal and harden around it, forever after ignoring anything else that comes along. The popularity of programming languages and other technologies has next to nothing to do with technical considerations and everything to do with the same instinct that makes 13-year-old girls decide they all like Britney Spears simultaneously. Of course, software engineers can typically provide more compelling-sounding arguments for why they closed their minds as soon as they found Language X.
Maybe this is unavoidable in the relatively conservative, unimaginative corporate world -- the help wanted section in twenty years may still consist of a set of twenty or so acronyms repeated over and over -- but there's no excuse for it in the (let's face it) largely unpaid world of free software. Get out more.
--
Proud member of the Weirdo-American community.
I find it hard to belive that Java is really faster on linux than it is on just about any other platform. At least Java 2 anyway. Do they have native threads yet? Blackdown changed their status page. Where's the checklist page? If they do use native threads I guess they don't use ptreads. If they did each thread would appear as a separeate LWP. Imagine running a Java proggie that had 300 threads and then looking at top and finding 300 6MB processes(linux threads reports same total memory usage of all threads for each individual thread). Although I have never done any benchmarks my feeling through expirience is that its just a little slower due to particular memory usages and other stuff I have heard. But maybe they sorted some of that stuff out. Great to hear if it's true. I wouldn't develop on anything else even if it where half the speed.
KidSock
You forget that Java can be compiled too. Just look at GCJ
Java is really three things. JWZ has a nice paper about this. It's a language, virtual machine, and class library.
The JVM indeed slows things down, and the class library does some too. But Java the language, even when natively compiled, is slow all by itself.
After all, the GCJ project uses the gcc/g++ compiler code base. So why is a C++ application compiled with g++ so much faster than a gcj compiled application? Must be the use of exceptions and GC (in the form of a shared library with gcj).
So Java isn't slow, exceptions handling and garbage collection are slow.
I'm glad to hear that we now have "Java Rocks". Not that I have the slightest clue how to implement an application or class library on this new development, but it just sounds cool.
:-) I have enough serious rambling yet to finish.
Isn't a cool name the core of any new technology product?
It brings up an image - I see it now! A penguin hurling Java Rocks at stained windows...
Enough pointless rambling
A dingo ate my sig...
Okay, repeat after me:
HARDWARE IS CHEAP. PEOPLE ARE NOT.
HARDWARE IS CHEAP. PEOPLE ARE NOT.
HARDWARE IS CHEAP. PEOPLE ARE NOT.
So, Java's a little slower on the runtime versus native code. Quantify that difference (call it X).
On the other hand, I've heard (and experienced) that writing with Java and its APIs is much faster and easier than learning and writing code to various OSes and their bare-metal system resources. Quantify THAT difference (call it Y).
So, what's the per-unit cost to compensate for X across multiple forms of hardware. What's the per-unit cost to compensate for Y across OSes, people, and systems.
I'd be willing to bet, were this all actually well formulated as an equation, that you'd find we really don't give a shit anymore about how blindingly fast a given programming language can be if you're hacking close to the hardware. Hardware is cheap, just throw another faster CPU at it. People, however, are much harder to upgrade.
hen a programmer just has to know one pretty simple language and API, rather than many OS quirks and tricks and system-resource details that distract from the main task at hand, programmer cost goes down. Make it easy for the people, and it becomes so much cheaper that we accept a margin of performance cost on our easily improved hardware.
Fact is, you can't say Java is fast or slow, it depends a lot on the context.
Uhh... Use the right tool for the right job. I'm not, of course, saying everything should be done in Java. I'm just saying that for many things, Java is great and it has it's place - as does many other languages and technologies.
I just read an article where Linus Torvalds says his siblings and grandparents use Windows cause it has better support for the apps they need. Fair enough. He doesn't jump out the window cause of it or start crying that Linux is the only way to go. The same attitude might be smart when dealing with languages and software platforms. A professional software engineer uses the best tools for the job.
The first problem I see is that the first posts to an article are the most likely to be modded up. Moderators tend to hang around the couple most recently posted stories.
Not everybody refreshes Slashdot every two hours. The people that do, are the ones that agree most with the stereotypical slashdot agenda.
Insightful posts take time. It could easily take an hour to *read the article*, do some other research, and post some meaningful commentary. Those who post fast seem more likely to spout out their gut feelings.
To sum up: The people who post first are likely to be avid slashdot readers and more zealotous. Posts that are made soon after the article goes up are not as likely to be based on facts.
On hot trigger issues such as this one, I have read comments soon, then comments later and been pleasantly suprised by a couple better posts that get moderated later. Often on looking further, I notice that there are several more that I would have modded higher than the ones that are modded higher.
Let me try to illustrate this with a graph:
PostQualityv sTime:
|high
|
| +---+
| +++--+
|+-+ +---+
|++ +---+
|++ +---------------
|++
|+-+
|++
|++
|
|low
+-----------------------------------------
time-- ->
Sumofmoderationdone
|more +-------------------------
|+-----+
|+--+
|++
|+
|++
|+
|+
|+
|+
||
|
|less
+-----------------------------------------
time--->
As you can see from the graphs, I think there are a lot of good comments posted later that don't get moderated, while a lot of earlier comments that might not be quite so good, do.
I suggest the golden moderation system.
You get 5 moderator points.
2 of the are gold.
2 of them are silver.
1 of them is bronze.
gold points can be used on any post at any time. Silver points can be used on posts attached to articles that are more than 2 hours old. Bronze points can be used on posts attached to stories that are more than 1 day old.
I think this would really do wonders for Slashdot
In this interview some Sun engineer says the next Java release will definitely support wheel mice with Swing. No word on how this release (1.4, 'Merlin') will be out, though.
Okay, I can understand being happy when something like NVIDIA's OpenGL (which is very Windows oriented) performs nearly as well on Linux. However, does Linux Java being slower than Win32 Java "rock?"
A deep unwavering belief is a sure sign you're missing something...
I am tired of benchmarks. I am tired of hearing about MySQL vs Postgres, Apache vs IIS, etc. That sort of benchmarking is not worthy of discussion and Slashdot should understand this by now. Hey. If Ingo Molnar writes a kernel-space web server which will be available in upcoming Linux distributions, that's interesting and that's news. But please. Please. PLEASE stop with all of these useless benchmarks. All they do is provoke people and lead to endless arguments about nothing at all.
Dave Bailey
If the app runs for more than 5 minutes without crashing, version 1.0, baby.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
And what is your experience with Java, please? I've spent almost the last five years developing a significantly large scale Java app, and it is very very good for what I need from it. You may not have a need for a secure, portable, high level programming environment with decent performance and easy programming, but there are a lot of us who do and have found it in Java.
It would take a moron to decide that Java or anything else is the perfect answer to everything, but to declare people suckers for saying 'hey, Java is really some pretty nice stuff and I get a lot of benefits from programming in it' is insulting and pretty close to zero content.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
According to http://members.ping.at/theofilu/netsc ape.html, Netscape gets its problems from memory management functions (big surprise there) in the the libc.so.x.x.x library. I'm trying the fix recommended on that page, sounds like it might help clear up the other Java problems.
Not only is this not representative of most real-world programming tasks (it checks the gc and allocation code more than anything), but he didn't perform simple optimizations that would have helped him big-time (like loop unrolling). He also apparently didn't read the gcj docs, which point out that gcj's bounds checking is much slower than it should be, so if you don't need it, you can turn it off. Since he does 1.5 million array accesses and does all the bounds checking himself with loop termination invariants, bounds checking is a fairly important -- and unnecessary -- constant multiplier, I'd say. :-)
~wog
Not just CPU - but of course it also helps some in making the speed disadvantage less noticable. I have this old texture filler that I coded some years ago to test the speed of Java graphics and on JDK 1.1.4 (or .3 or whatever) it ran with about 8 frames per sec on a given texture on a given polygon on a given app on a given computer. Microsoft's jview clocked around 12 fps.. Then with JDK 1.2.0, it dropped to around 3 (!!) on some color models, but I wrote another version that used a color model without any alpha channel and the speed was now somewhere around 8 fps. Meanwhile, JDK 1.1.8 was clocking up to 15 fps. With 1.2.2, it's up to 17 and 1.3.0 is almost at 20 fps. This is still with the same machine, same texture, same app.. The computer I use for this is my IBM 390 laptop that has a Pentium 233MHz MMX. On my AMD K7 / 500 Mhz, I get over 45 frames per second using 1.3.0.
The speedup is directly visible in apps that use GUI's - Swing in particular.
What a lot of people fail to realize is that a lot of "java performance problems" are caused by sub-par java programmers who don't understand how costly some operations are. Another entire class of performance problems are caused by bad algorithms. An O(n) algorithm coded in QuickBasic will outperform an O(n^2) algorithm hand-coded in assembly language for most possible inputs.
OK, so all things being equal, using smart algorithms, and not abusing the language, java is still a bit slower than C. Big deal! In most cases, it doesn't matter. Server-side apps are blocking on I/O most of the time anyway; client-side apps are blocking on user interaction most of the time. For projects with hard real-time requirements, you have the RTJ standard; if you're really speed-hungry or are doing serious systems work, then you can write it in C.
However, my employer could buy a middle-range Sun workstation for what he pays for my time in a week, and I'm a lot more productive in Java than I am in C. Furthermore, because I pay attention to engineering and design issues, other engineers can re-use and subclass my code without modifying it. If I've used good algorithms, avoided stepping on the GC, and steered clear of known performance problems (like the + operator for Strings and the unnecessarily synchronized Java 1 collection classes), then my code is probably fast enough. If it's not, then it's a lot cheaper for my boss to requisition a faster machine than it is for him to pay me for an extra two months to chase pointers and re-model object-oriented systems in procedural code.
~wog
Add to my list of complaints that dumbass moderators, who have knocked my original post from a +2 to 0 with several "offtopic" mods (shrinking my karma in the process, of course), have seen fit to give MrBogus' post a rating of +4, even though it appears in a thread underneath my post and deals with the same material, which is supposedly offtopic.
You can't have it both ways, meatheads.
slashdot broke my sig
I understood the poster's comment to mean that moderators should be given ten moderation points to work with, not that posts should enjoy an upper limit of ten points.
The problem is not the posts that get moderated up, it's the posts that don't and the moderators that blow their load on the first 30 posts.
There should be no negative moderation, it's pointless. Start all posts at zero by default, adding a point or two for merits, then allow the good posts to accumulate positive moderation points.
"Yeah, but what about crappy posts that get moderated up?" Get a clue. A post might get one or two mods you think it doesn't deserve, but if four or five moderators think the post merits a bump, that's a pretty good indication that it deserves the increased exposure.
slashdot broke my sig
On the server side it is different. Java is a very nice language to develop in. The class library is HUGE and having the flexibility to support several platforms at the server is very good and something we surely will take advantage of in the future. It seems to be easier to optimize server side JVMs also.
Java is here to stay, especially at the server. Those who flame Java for its weak points (small client applications) should look closer on the areas where it rocks, before discarding the language as a whole.
It isn't pretty. All of the Windows solutions beat all of the linux solutions, inlcuding gcj.
:)
Java may be adequate on linux, but I really don't know how you could conclude that it "rocks".
The article actually concludes with this very point, in fact, something along the lines of "The Linux JVM is almost as fast as its Win32 counterpart".
What's impressive for the Linux side is how far it's progressed lately - support for 1.3 will help an awful lot. The main cause for difference in speed is the amount of time Java has been available and the amount of time spent improving it on each platform - years for Win32, almost none so far for Linux.
I don't quite get the "rocks" part myself either, but it's a definite improvement
Fross
Java too slow? We've heard that a million times. Boring. It's quick enough for thousands of Java hackers out there.
It's not as quick as C performance-wise, but you get a speed tradeoff in return for platform independence, greater stability etc etc. The vast majority of apps being written today do not need to be blindingly fast. It's much more useful to have them written faster and be easier to mantain, both of which are helped a lot by Java.
I suspect most of the flame I hear against Java is from established C coders who are scared they'll have to learn a new language. Try it, you might like it. I use Java and Perl almost exclusively now. I wouldn't use C now unless I was feeling masochistic or had to do something really low-level.
What is your point? "runs nicely" really means nothing.
You said:
Have you ever used the swing JFC? If you have tried the demos included in the distribution, you know what I am talking about.
I simply say that I'm programming an application that is quite a bit more complex than the demos and there is no problem with it. No flicker, no slow GUI refresh, no problem. I also get along quite fast because Swing is easy to understand. So whatever you experienced isn't true for me -- got it?! The statement '...try the demo and you'll know what I mean' is simply nonsense. My system is a P-II 350, so not exactly the fastest machine.
Heavy use since 0.9.
Most of the time very frustrating - trying to use the various incarantions of AWT/Swing/whatever.
On the server side, some serious data mangling and networking (perl/C++ destroys it in this repsect).
Its a solution looking for a problem.
Will be fixed in 1.4, according to some guys in comp.lang.java.programmer. There already is a fix, but only for Win32...
Saying that Java is hype because you used it to write software which is not its core competency is an instance of a poor worksman blaming his tools
Java's GUI API will always be slower than Native GUI toolkits. In most instances if the app is complex then it'll be almost unusably slow. Heck, even Sun has canned most of its Java GUI tools because they became unusable the larger they became.
Perl is the king of text processing languages (no contest) and C++ gives more fine grained control of sockets than Java.
Now for medium to large scale, cross platform, multithreaded, easily extensible, middleware applications that will need little or no maintainance but are easily maintenable, Java(TM) cannot be beat.
PS: Your rant is similar to someone bitching that C sucks because it is poor at text processing even though C was designed as a portable assembly language.
The Queue Principle
First of all, IBM has done more with Java than Sun... one of the first useful Java applications I ever tried was their Java IRC client, which did everything an IRC client should. If anyone was going to do a quality Java implementation, the people at the IBM alphaworks would be the ones.
Also, one shouldn't dismiss the Open Source contribution to this. Having the ability to examine the kernel source in detail makes it that much easier to tailor your Java implementation so that it best integrates with the kernel. With the highly closed nature of Windows, developers have to guess how to best integrate with the complex APIs and SDKs of Windows.
Java may actually take off only about four years after it was supposed to be The Next Big Thing in programming languages. With APIs like Jini and Personal Java, Java may actually find a niche in PDAs and Internet Appliances...
I've been running the blackdown jdk in a production environment for over a year now. It has been nothing but stable and seems pretty fast. I did try out the IBM jdk 1.3 and was very impressed... until I ran apache bench. It crashed within seconds of a 100 concurrent user test that I run with no problems on blackdown. Has anyone else seen this? It's a new port, so I will try back with the next release.
"What a waste it is to lose one's mind. Or not to have a mind is being very wasteful. How true that is"
Vidi, Vici, Veni
So there's too many people Karma Whoring for 5s and your solution is to raise the bar to 10? Why? To seperate the truely good whores from the mediocre ones? The problem is not the posts that get moderated up, it's the posts that don't and the moderators that blow their load on the first 30 posts.
In my book, we need more negative moderation and less positive moderation. I'd be perfectly happy with a maximum of 3 if you could moderate people down for reasons such as "Stupid", "Wrong", "Waste of Bandwidth", "Bitchy Old Timer", "Karma Whore", "Didn't Read the Article", "Advocacy Post" and "Take it to sid=Moderation".
When I hear the word 'innovation', I reach for my pistol.
Last Modified: Sun, Aug 6, 2000 2:59:48 AM GMT
I'll second this. We had unacceptable performance with the Java 2 JDK that comes straight from Sun. If you're going to do Java on Linux, use the Blackdown JDK. As a bonus, the Blackdown JDK far outperforms the Windows JDK as well (at least for server apps, we don't do any GUI development).
--jb"Javalobby stats should not be trusted - my experience is that Javalobby has the lowest collective IQ of any community tech site on the web, and their articles are typically mindless advocacy with no useful data."
;)
Funny, that's just what they say on JavaLobby about Slashdot
The survey is here, go and vote. Recently, a petition was put forward to open source javadoc (the Java sourcecode documentation tool), but Sun hasn't responded (possibly due to lack of attention from the media). I think if we really bug Sun about this, we might get an official response (*fingers crossed*).
As to the topic at hand, my primary Linux JDK for development is IBM's. It's excellent, and very fast - I haven't had any problems. Sun's 1.3.0 JDK hasn't even been officially released for Linux or Solaris yet, so there's not really much of an alternative at the moment.
It's not a solution looking for a problem, it's just not a solution to every problem.
If you're looking to build a GUI app on a single platform, Java isn't going to give you the best results. If you're looking for a server app to do text processing or data reduction, Java isn't going to give you the best results. If you're looking to build a TCP/IP server, Java may make it easy to do, but its lack of a select()-type call or asynchronous i/o means that Java today isn't going to give you nearly the best results.
But, if you're looking to build a portable distributed application with graphics and interactivity beyond the web browser, with lots and lots of classes, many thousands of objects, tons of concurrent threads and a nearly transparent networking layer for distributed object calls, and you want to be able to leverage as much reliable, pre-written classes as possible, Java is just the thing.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
I've seen 'real' applications written in Java. I've used Moneydance personally, and several custom apps we've designed at work, and a couple of shrinkwrap apps written in Java, both stand-alone and Web-based. For the most part, they perform very well. Java does indeed rock as a programming language. That, however, is a seperate issue from it's execution speed, and it's speed (or lack thereof) cannot be attributed to the language as a whole, but rather to the implementation of the JVM. A good JVM and/or JIT greatly enhances the Java experience.
People who say that Java is slow are correct, for the most part. Even with the best JVM, Java cannot approach the speeds of a well-designed native-code application. This does not mean that Java is a bad programming language, or inappropriate for mission critical apps. We have several mission critical apps written in Java. They run well, and are stable. The loss of speed in the application, though, was not great enough to outweigh the benefits of the cross-platform execution. We can design the app on AIX, OS/390, OS/2, Windows NT, or Windows 2000, and we can compile that app once, and then we can take that compiled app and run it on AIX, OS/2, Windwos NT, or Windows 2000, or OS/390. The simple fact of 'compile once, run anywhere' so far outweighs the speed loss that it's worth it.
So, you are wrong when you say that "The very fact that someone claims that shows that they are not in the industry and have no idea what's going on in the Real World (tm)". I say that Java is slow, and I work in the "Real World (tm)". It's just that the slowness disadvantage is not near as important as the advantages.
Matthew Vanecek For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting i
suns JDK on linux sucks rocks. it tends to lock up under heavy loads. i've personally observed this several times. blackdowns 1.2.2FCS works as well as suns JVMs on solaris do. note that most JVMs are better off with a max of 125 threads/JVM. of course with java multiprocessing/mutlithreading is built into the language from the ground up and as a general rule i run at least 4 independent JVMs per machine (500 concurrent users) for decent performance.
Order in which JDK 1.3 is/will be released for various platforms:
Has to be a tad embarrasing for Sun!
--
DWR is Ajax for Java
It was one of the few places I worked at that had an active hostility towards Linux. Needless to say, I no longer work there.
Looking at these benchmarks, I do not think I would be able to convince any of my ex-co-workers that Linux is ready for heacy-duty Java yet.
I note that Java on Linux has caught up in a number of ways, but still has a way to go with:
- Scalability
- Graphics performance
The scalibility issues should be much less of an issue when the 2.4.x kernel comes out (knock on wood), and the graphics issues are simply a matter of LinuxJava accessing the hardware directly.Anonymous so my ex-employer doesn't get on my case for breaking any NDA I may have signed
*yawn*
Obviously it's fast enough for the couple hundred thousand or so (millions?) of Java coders and companies that use it every day in mission critical applications all over the world.
Seriously, I doubt you have any real world experience with Java if that's still your take on it. Yeah, three years ago, it wasn't fast enough. Things have dramatically changed since then.
Anyone can code a crappy app in C and say "woah! look, it sucks! it's slow!". That doesn't prove that C would be slow - it proves that the code sucks. In the same way, an amateur not knowing what he or she is doing with Java can see slow apps. If you know what you're doing, the situation is different.
I don't know about the rest of you here but I'm getting very tired of the same old "Java is slow" and "I've never seen any real apps in Java" myths here on Slashdot. The very fact that someone claims that shows that they are not in the industry and have no idea what's going on in the Real World (tm).
I'm just in the process of writing a Swing app (JDK 1.3 / Sun). It runs nicely, the GUI's concept is simple to understand, so -- where's the problem? My story is as anecdotal as any, but what is so bad about Swing?
People don't complain about the execution speed of Python or Perl because nobody touts either Python or Perl as being fast. When you are working with a scripting language you are optimizing your development time, not execution time.
The Open Source community has long been skeptical of Java for many very good reasons. For example, as you yourself state many of the core Java libraries are painfully inefficient. Another problem with Java is that it has been touted from it's inception as a "Write Once Run Anywhere" language, and yet the Linux and BSD versions of Java have historically been late, buggy, and incomplete. In other words, Java has been a "Write Once, Run On Solaris Or Windows" language up until very recently. Perl and Python both work very well on the Free Unixes, and (speaking as someone who tried Java first) generally performed as well or nearly as well as the more complicated Java. For example, Perl will completely destroy Java if the task includes a lot of text manipulation. And comparing a GUI written in Python/Tkinter (or better yet wxPython) to a GUI written in Swing is ridiculous (or has been until recently on the free Unixes). The Python GUI would almost certainly use less memory, and be more responsive.
The killer has been that Java has historically had all the speed of an interpretted language and all the complexity of C++, hardly a compelling combination. This is just starting to change, but it will be some time before Java loses its stigma. In the meantime the hackers that have chosen Perl or Python have very little reason to switch. They are, by in large, quite happy with their choices. And it really isn't that hard to implement a solution in Python (or Perl) and then optimize the slow bits in C.
Let me see If I got this right...don't use Java (pure OO), use Pascal (Delphi by any other name...). And you're telling ME to grow up?
Try going below to read some of the other, more well thought out comments before you spout idiotic nonsense.
Would I use java to create a graphic-intensive, Windows only exe? No that's not what the tool is for. Would I use it to create a thread-safe, cross-platform networked servlet? Now your talking.
About 10-15 years ago many people were saying the same thing about some upstart, slow, bloated language called C++. I guess we know what happened to that.
Never by hatred has hatred been appeased, only by kindness - the Buddha
Wow, what a lot of whining here by the "java is too slow" crowd.
The right tool for the job. Look at what you need to do. Look into ways to do it. Choose the way that is right for your situation. If that means using Java on Linux great! If it means ASP on NT, fine (insert anti-MS statement here).
I'm currently using the 1.3 Java 2 SDK on an NT box for some development we are doing. The data access(JDBC) and networking (Servlets) works great - quite zippy, at least for our needs. The client (a custom applet) renders a little slow but we accept some slow rendering speed in order to get the peculiar UI our client wants (a round component with buttons that are pie wedges a la Trivial Pursuit pieces each one of which pops up a dynamically created menu with database data in it). We choose java because it was one of the few languages which allowed us to do all these disparate programming chores and keep the code clean and maintainable. We went from zero to prototype in 5 days.
Now I'm sure we could have done this in a number of different ways (although we couldn't figure any others).
The story was about how much the IBM JDK for Linux has improved in terms of speed, how it's almost ready to do graphic intensive stuff like desktop apps and such. If you really need that couple of extra milliseconds, use something else. Just stop whining about it.
I personally don't like perl (my own opinion) but I don't go around slagging it - for some things its probably the best tool for the job.
Never by hatred has hatred been appeased, only by kindness - the Buddha
It isn't pretty. All of the Windows solutions beat all of the linux solutions, inlcuding gcj.
Java may be adequate on linux, but I really don't know how you could conclude that it "rocks".
Javalobby stats should not be trusted - my experience is that Javalobby has the lowest collective IQ of any community tech site on the web, and their articles are typically mindless advocacy with no useful data.