An anonymous reader writes "Programmers agonize over whether to allocate on the stack or on the heap.Some people think garbage collection will never be as efficient as direct memory management, and others feel it is easier to clean up a mess in one big batch than to pick up individual pieces of dust throughout the day. This article pokes some holes in the oft-repeated performance myth of slow allocation in JVMs."Ads_xl=0;Ads_yl=0;Ads_xp='';Ads_yp='';Ads_xp1='';Ads_yp1='';Ads_par='';Ads_cnturl='';Ads_prf='page=article';Ads_channels='RON_P6_IMU';Ads_wrd='java,developers';Ads_kid=0;Ads_bid=0;Ads_sec=0; Java Urban Performance Legends Log in/Create an Account | Top | 397 comments | Search Discussion Display Options Threshold: -1: 397 comments 0: 392 comments 1: 315 comments 2: 220 comments 3: 67 comments 4: 36 comments 5: 18 comments Flat Nested No Comments Threaded Oldest First Newest First Highest Scores First Oldest First (Ignore Threads) Newest First (Ignore Threads) The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way. Nonsense (Score:4, Funny) by hedge_death_shootout (681628) <stalinNO@SPAMlinuxmail.org> on Sunday October 09, @09:29AM (#13750205) These java urban performance legends are rubbish - java is highly performant in a rural or urban setting. [ Reply to ThisPartial Retraction by hedge_death_shootout (Score:1)Sunday October 09, @09:35AMRe:Nonsense by justsomebody (Score:2)Sunday October 09, @12:42PMI hate Java. by JPriest (Score:1)Sunday October 09, @01:16PMRe:Nonsense by object88 (Score:2)Sunday October 09, @02:03PM Robomaid (Score:5, Insightful) by Doc Ruby (173196) on Sunday October 09, @09:30AM (#13750212) (http://slashdot.org/~Doc%20Ruby/journal | Last Journal: Thursday March 31, @02:48PM) How much time have I spent with Electric Fence and valgrind finding memory leaks in my C programs? In Java, the auto garbage collection is as good as Perl's, without that tricky "unreadable code" problem ;). And I can always tune garbage collection performance by forcing a garbage collect when I know my app's got the time, like outside of a loop or before creating more objects in storage. [ Reply to This Re:Robomaid (Score:4, Insightful) by Some Random Username (873177) on Sunday October 09, @09:44AM (#13750258) (Last Journal: Tuesday August 30, @12:13PM) If you spend alot of time using stuff like valgrind and searching for memory leaks, then you are doing something very wrong. Its really not hard to just free the memory you allocate. The fact that people can write entire operating systems in C without having these problems indicates that the problems are with people, not C. [ Reply to This | Parent Re:Robomaid (Score:5, Insightful) by Doc Ruby (173196) on Sunday October 09, @09:51AM (#13750281) (http://slashdot.org/~Doc%20Ruby/journal | Last Journal: Thursday March 31, @02:48PM) Of course, that's why I program everything in machine language. Memory allocation in hex opcodes worked for me in 1981, it still works in 2005. Programming languages don't leak memory, programmers leak memory.In seriousness, look at the bugzillas and changelogs of any programming project. Memory leaks abound. So the reality is that memory de/allocation programming eats quite a lot of productivity, and impedes many otherwise ready releases. Of course we can de/allocate memory properly in C. And we can compute with scientific calculators. When we've got something better, we use it. [ Reply to This | ParentRe:Robomaid by AArmadillo (Score:3)Sunday October 09, @10:12AMRe:Robomaid by Doc Ruby (Score:3)Sunday October 09, @10:30AMRe:Robomaid by Q2Serpent (Score:2)Sunday October 09, @11:03AM Re:Robomaid (Score:4, Insightful) by Doc Ruby (173196) on Sunday October 09, @11:24AM (#13750635) (http://slashdot.org/~Doc%20Ruby/journal | Last Journal: Thursday March 31, @02:48PM) Please forward me the resumes of these programmers, which include "Skills" like "I never write memory leaks". And whose "Certifications" include "Good Programmer", not those other resumes which say "Bad Programmer".The fact is that Java programs include more intelligence about programming from the compiler and the JVM. So programmers are more productive than with C. Which means that the same programmer budget can produce more product, or a lower budget can produce the same product. With distributed teams, outsourcing, OSS integration projects, those considerations are crucial to project success. Sure, quality projects also require good design and management. But Java eliminates some quality problems right out of the box. That can't be dismissed merely by saying "hire good programmers, not bad". Because it's a continuum, with a sliding scale of costs that isn't always proportional to productivity. [ Reply to This | ParentRe:Robomaid by dubl-u (Score:1)Sunday October 09, @01:01PMRe:Robomaid by thoth (Score:2)Sunday October 09, @01:51PM Re:Robomaid (Score:5, Insightful) by Mr. Shiny And New (525071) on Sunday October 09, @10:35AM (#13750424) (http://home.primus.ca/~mr.shiny/) You're right, Java does have memory leaks, in a sense, but these same problems can arise in any language. You could have a cache implemented in C/C++ that is never properly emptied, so over time it fills up. Or you could have a request log where, due to a bug, requests are not always removed from the log after they are processed. Sure, you might have included code to free the objects in the cache or log when you are done with them, but the programming error is that you forgot to remove the item. This is not a language issue, this is just a programming mistake.At least in Java you only need to worry about one problem: removing items from caches, logs, queues, etc when you are done with them; in C++ you have to also worry about de-allocating that object, which requires strict planning since the object must not be referred to anywhere else when you de-allocate it. In general you can't prove that the object isn't still referred-to by someone who had it before it was put into the cache/log/whatever; instead you need to establish rules and write documents to make sure everyone knows what the lifecycle of an object should be.As for your company not having a memory bug logged in 3.7 years, that's great, but without knowing what kind of applications you write, or how they're used, it's hard to say if that's significant. Some programs, like, say, grep, or mv or ls or any one-time-use utilities may be rife with memory leaks, but who cares? When the program terminates the memory is freed, and the user will likely not notice the leak. But even if your apps are long-running network services or whatever, I bet the time spent by developers preventing memory leaks is significant, even if that time is completely spread out throughout the development cycle instead of in large, easy-to-spot chunks running Valgrind or some other profiler. [ Reply to This | ParentRe:Robomaid by Midnight Thunder (Score:2)Sunday October 09, @11:51AMRe:Robomaid by NoOneInParticular (Score:2)Sunday October 09, @03:19PM2 replies beneath your current threshold.Re:Robomaid by Baki (Score:2)Sunday October 09, @02:33PMMaybe you should look harder. by Some Random Username (Score:2)Sunday October 09, @11:15AMYou should consider reality by Doc Ruby (Score:2)Sunday October 09, @11:27AMRe:Maybe you should look harder. by TheRaven64 (Score:2)Sunday October 09, @12:20PMRe:Maybe you should look harder. by Dwonis (Score:2)Sunday October 09, @03:25PMRe:Robomaid by someone1234 (Score:2)Sunday October 09, @11:19AMRe:Robomaid by Doc Ruby (Score:2)Sunday October 09, @11:34AMRe:Robomaid by ezzzD55J (Score:2)Sunday October 09, @12:22PMRe:Robomaid by Doc Ruby (Score:2)Sunday October 09, @12:51PMRe:Robomaid by NoOneInParticular (Score:2)Sunday October 09, @03:25PMRe:Robomaid by Jonner (Score:2)Sunday October 09, @02:59PMRe:Robomaid by Anonymous Coward (Score:1)Sunday October 09, @10:03AMRe:Robomaid by hedge_death_shootout (Score:1)Sunday October 09, @10:18AMMod parent Funny! by BerntB (Score:2)Sunday October 09, @10:20AMRe:Robomaid by carlislematthew (Score:1)Sunday October 09, @10:20AMRe:Robomaid by Mnemia (Score:2)Sunday October 09, @01:29PMRe:Robomaid by carlislematthew (Score:1)Sunday October 09, @01:40PMRe:Robomaid by dorkygeek (Score:1)Sunday October 09, @11:58AMRe:Robomaid by tsotha (Score:2)Sunday October 09, @02:28PMRe:Robomaid by Anonymous Coward (Score:1)Sunday October 09, @10:34AMas good as Perl's? by jbellis (Score:2)Sunday October 09, @11:13AMRe:as good as Perl's? by Doc Ruby (Score:2)Sunday October 09, @12:39PMRe:as good as Perl's? by DougWebb (Score:1)Sunday October 09, @01:26PMRe:as good as Perl's? by M. Baranczak (Score:2)Sunday October 09, @02:33PMRe:Robomaid by stesch (Score:2)Sunday October 09, @12:24PMGarbage Collection: not just for C by OpenGLFan (Score:2)Sunday October 09, @01:47PMRe:Robomaid by David's Boy Toy (Score:1)Sunday October 09, @01:47PMRe:Robomaid by MenTaLguY (Score:2)Sunday October 09, @03:18PMRe:Robomaid by Doc Ruby (Score:2)Sunday October 09, @10:20AMAnonymous Cowards Can't Write by Doc Ruby (Score:2)Sunday October 09, @10:42AM2 replies beneath your current threshold. Java Urban Performance Legend #1 (Score:5, Funny) by GillBates0 (664202) on Sunday October 09, @09:30AM (#13750214) (http://slashdot.org/~GillBates0 | Last Journal: Wednesday August 03, @01:06PM) JVM memory allocation isn't "SLOW". It's just pleasantly unhurried. [ Reply to This1 reply beneath your current threshold. They're good.. now.. (Score:5, Insightful) by onion2k (203094) on Sunday October 09, @09:31AM (#13750218) (http://www.ooer.com/) JVMs are surprisingly good at figuring out things that we used to assume only the developer could know.Yes they are. Now. 10 years ago when Java applets were being embedded in webpages (to show rippling water below a logo :) ) they weren't. The performance of the language has greatly improved while the perception of language has remained the roughly same (at least amoung the general coding community).Just goes to show that even if you have a great technical product you'll still need the marketdriods. Unfortunately. [ Reply to ThisRe:They're good.. now.. by eraserewind (Score:2)Sunday October 09, @10:05AMRe:They're good.. now.. by Mr. Shiny And New (Score:3)Sunday October 09, @10:42AMRe:They're good.. now.. by qbwiz (Score:2)Sunday October 09, @12:50PM1 reply beneath your current threshold.Re:They're good.. now.. by Anonymous Coward (Score:1)Sunday October 09, @10:50AMRe:They're good.. now.. by DrXym (Score:2)Sunday October 09, @11:28AMRe:They're good.. now.. by M. Baranczak (Score:2)Sunday October 09, @02:46PM2 replies beneath your current threshold. BULLONEY!! (Score:3, Insightful) by Anonymous Coward on Sunday October 09, @09:31AM (#13750219) These articles keep popping up flatly stating that Java's slowness is a myth. But, no matter how many times you say it is a myth and how hard you try to create a new perception, the FACT is that people's real-world experience, no matter how anecdotal, consistently demonstrates that Java is MASSIVELY slow than similar apps in C or C++.Java is slower. Don't even get me started on C#. [ Reply to This Re:BULLONEY!! (Score:5, Interesting) by pla (258480) on Sunday October 09, @09:58AM (#13750308) (Last Journal: Sunday December 08, @06:40PM) Don't even get me started on C#. I should hope not! Any form of benchmarking ofMicrosoft's .Net violates the EULA. And wewouldn't want that!So when Microsoft declares their interpretedinverse-polyglotic language as "faster" thancompiled pure C, just accept it. Best foreveryone that way.the FACT is that people's real-world experience, no matter howanecdotal, consistently demonstrates that Java is MASSIVELY slowthan similar apps in C or C++. Well, the linked article contained a number of what Iwill graciously call "assumptions" (rather than "outrightlies") about allocation patterns in C/C++ that simplydon't hold true in most cases.For example, the parent mentions the old "stack or heap"question... Which no serious C coder would ask. Use theheap only when something won't fit on the stack.Why? The stack comes for "free" in C. If you needto store something too large, you need the heap. Butthen, you can allocate it once, and don't even considerfreeing it until you finish with it (generational garbagecollection? Survival time? Gimme a break - It survivesuntil I tell it to go away!). As for recursion... You canblow the stack that way, but a good programmer willeither flatten the recursion, or cap its depth.And the article dares to justify its "assuptions" bycomparing Java against a language interpreter suchas Perl. Not exactly a fair comparison - Yes, Perlcounts as "real-world", but in an interpreter, youcan't know ahead of time anything about yourmemory requirements. At best, you can cap them and dumpthe interpreted program if it gets too greedy.Now, some might point out that Java gets interpretedas well - And I'll readily admit that, for doing so,it does a damn fine job with its garbage collection.But if you want to compare Java to Perl, then do so.Don't try to sneak in a comparison to C with a layerof indirection.One last point - The article mentions that you no longerneed to use object pooling. SURE you nolonger need it - Java does it implicitly at startup.You can avoid all but a single malloc/free pair in C as well,if you just steal half the system's memory in main().Sometimes that even counts as a good choice - I've usedit myself, with the important caveat that I've done sowhen appropriate. Not always. I don't have malloc()as the second and free() as the second-to-last statementsin every program I write. And that most definitely showsin the minimal memory footprints attainable between thetwo languages... Try writing a Java program that eats lessthan 32k. [ Reply to This | Parent Re:BULLONEY!! (Score:4, Informative) by LarsWestergren (9033) on Sunday October 09, @10:21AM (#13750382) (http://www.smirkingchimp.com/) The stack comes for "free" in C. If you need to store something too large, you need the heap. But then, you can allocate it once, and don't even consider freeing it until you finish with itOr NOT consider freeing it when you forget about it... as the case may be.Try writing a Java program that eats less than 32k.No problem at all. [sun.com] [ Reply to This | Parent Re:BULLONEY!! (Score:4, Insightful) by pla (258480) on Sunday October 09, @10:35AM (#13750426) (Last Journal: Sunday December 08, @06:40PM) Or NOT consider freeing it when you forget about it... Programming takes some level of skill.If you "forget" to increment a pointer, it won't haveadvanced the next time you use it. If you forget toopen a file, assuming your program doesn't crash, anythingyou write to it goes to the bit bucket.If you forget a wife' birthday, you'll have a pissed-off wife."Try writing a Java program that eats less than 32k." No problem at all. Uh-huh... Now do the same thing without needing aspecial, stripped-down, nearly featureless JRE. Idon't need a special build of GCC to satisfy the condition,why did we shift from apples to oranges to make it possiblein the Java world?And most of these points end up exatly there - Apples andoranges. Java can do better than a few worst-casescenarios in C. Java can fit in a sane amount ofmemory with special builds. Java can outperformC by-way-of Perl. All nice claims, but self delusiondoesn't make for better programmers. [ Reply to This | Parent Re:BULLONEY!! (Score:5, Insightful) by gaj (1933) on Sunday October 09, @10:42AM (#13750452) (http://slashdot.org/ | Last Journal: Wednesday December 10, @03:54PM) It's not really apples to oranges to use a smaller profile JRE for creating smaller profile programs. The JRE includes libraries and features such as threading and such. Let's see you build a C program that uses pthreads and one or two major libraries and still have your memory use come in under 32K. Remember, apples to apples, right? [ Reply to This | Parent Re:BULLONEY!! (Score:5, Insightful) by earthbound kid (859282) on Sunday October 09, @10:44AM (#13750466) (http://deadhobosociety.com/) Programming takes some level of skill.If you "forget" to increment a pointer, it won't have advanced the next time you use it. If you forget to open a file, assuming your program doesn't crash, anything you write to it goes to the bit bucket.If you forget a wife' birthday, you'll have a pissed-off wife.I'm not about to forget my girlfriend's birthday, because my computer warns me about it three days ahead of time. Similarly, why should we risk forgetting to deallocate stuff from the heap, when we can have the computer do it itself? Yes, programming takes some skill. But we shouldn't start programming using only our thumbs while dangling over a pit of lava, just to up the skill factor needlessly. If we're going to do something more difficult, we need to get a benefit for it. The benefit of not using a garbage collecting language is that your code will probably be slightly faster than the equivalent code in a GC language. But, is that slight performance increase worth the pain in the ass of doing it the manly way? In most cases, not really. But hey, judge for yourself: find the best language for your particular job and forget the rest. [ Reply to This | ParentRe:BULLONEY!! by Skye16 (Score:2)Sunday October 09, @11:17AM1 reply beneath your current threshold.Re:BULLONEY!! by Lost+Found (Score:1)Sunday October 09, @01:42PMSignal processing by tepples (Score:1)Sunday October 09, @02:32PMRe:BULLONEY!! by LarsWestergren (Score:2)Sunday October 09, @10:58AMRe:BULLONEY!! by Bloater (Score:2)Sunday October 09, @01:43PMRe:BULLONEY!! by ninejaguar (Score:2)Sunday October 09, @11:18AMRe:BULLONEY!! by Xyrus (Score:2)Sunday October 09, @01:03PMRe:BULLONEY!! by matfud (Score:1)Sunday October 09, @02:44PMRe:BULLONEY!! by Chagrin (Score:2)Sunday October 09, @01:15PM2 replies beneath your current threshold.Re:BULLONEY!! by sjasja (Score:2)Sunday October 09, @11:41AMRe:BULLONEY!! by aaronl (Score:2)Sunday October 09, @01:33PMRe:BULLONEY!! by Matt Perry (Score:2)Sunday October 09, @12:38PMRe:BULLONEY!! by ctzan (Score:1)Sunday October 09, @02:44PMRe:BULLONEY!! by dubl-u (Score:2)Sunday October 09, @01:17PMRe:BULLONEY!! by msormune (Score:1)Sunday October 09, @10:10AM Really? (Score:5, Informative) by Mark_MF-WN (678030) on Sunday October 09, @10:25AM (#13750394) Really? Can provide a few REAL world examples? Can you name one? Personally, I'm running Azureus and Netbeans right now, and they're not perceptably different from C++ desktop applications like KDevelop or OpenOffice. [ Reply to This | ParentRe:Really? by Skye16 (Score:2)Sunday October 09, @11:14AMRe:OMG LOL!!! by sdhankin (Score:1)Sunday October 09, @11:59AM1 reply beneath your current threshold.Truth vs Perception by SmallFurryCreature (Score:3)Sunday October 09, @10:37AMRe:Truth vs Perception by the eric conspiracy (Score:3)Sunday October 09, @11:33AMRe:Truth vs Perception by Dogtanian (Score:3)Sunday October 09, @01:36PMRe:Truth vs Perception by Helios1182 (Score:2)Sunday October 09, @01:22PMRe:Truth vs Perception by M. Baranczak (Score:2)Sunday October 09, @03:15PMRe:BULLONEY!! by hobo sapiens (Score:1)Sunday October 09, @12:17PM1 reply beneath your current threshold.Dont take Swing GUI apps as an example by steve_l (Score:2)Sunday October 09, @02:48PMRe:BULLONEY!! by Baki (Score:2)Sunday October 09, @02:50PM Re:BULLONEY!! (Score:4, Interesting) by HeaththeGreat (708430) <hborders@mail.win.org> on Sunday October 09, @09:50AM (#13750279) What Java apps are you talking about?There aren't many professional-grade Java Desktop apps out there, and those that _are_ out there are generally built for maintainability, not speed (Eclipse, Netbeans). I built a Java web client that blew the pants off its older C++ version. The reason Java apps are generally slower is because the Java culture is about maintainence over performance. [ Reply to This | ParentRe:BULLONEY!! by m50d (Score:2)Sunday October 09, @10:49AMRe:BULLONEY!! by Baki (Score:2)Sunday October 09, @02:59PMRe:BULLONEY!! by Q2Serpent (Score:2)Sunday October 09, @11:14AMRe:BULLONEY!! by KarmaMB84 (Score:2)Sunday October 09, @11:31AMRe:BULLONEY!! by innot (Score:1)Sunday October 09, @11:56AMRe:BULLONEY!! by gbjbaanb (Score:2)Sunday October 09, @02:58PM1 reply beneath your current threshold.3 replies beneath your current threshold. As I see it. (Score:4, Interesting) by Z00L00K (682162) on Sunday October 09, @09:33AM (#13750223) The memory allocation management routines are normally running when the JVM thinks it's best, but as a programmer it is usually possible to predict the best time when to actually take care of the housekeeping. Even if the memory management cleanup takes the same time in both cases Java has a tendency to issue them in the middle of everything. So if I as a programmer does the garbage collection at the end of a displayed page and Java does it uncontrollable in the middle of the page the latter case is more annoying to the user. [ Reply to ThisJust for you by MochaMan (Score:3)Sunday October 09, @11:29AMRe:As I see it. by sulam (Score:1)Sunday October 09, @12:00PMRe:As I see it. by Hangeron (Score:1)Sunday October 09, @12:10PM1 reply beneath your current threshold. Article somewhat ignores the fatness of the JVM (Score:5, Informative) by expro (597113) on Sunday October 09, @09:33AM (#13750225) How many JVMs can you afford to run on your system for different apps, and how can you make sure they are all the right size, the garbage collectors are in an appropriate mode that can keep up with generated garbage, etc. I can run lots of native apps, which in many cases have no need for a significant heap like Java brings into the picture in far less space than a single JVM. A JVM runs much heavier on the system, and when I run Netbeans, it is continuously on the verge of eating my 1.2 GB powerbook alive, in fact I have to frequently restart Netbeans to get memory back. It has a long way to go in real practical terms even if they have theoretical solutions to some of the problems. I am porting my server software away from Java for the same reasons. This is JDK 1.4, and I am about to try it on 1.5, but I don't think there is that much difference. [ Reply to This Re:Article somewhat ignores the fatness of the JVM (Score:5, Informative) by LarsWestergren (9033) on Sunday October 09, @09:50AM (#13750278) (http://www.smirkingchimp.com/) How many JVMs can you afford to run on your system for different apps, and how can you make sure they are all the right size, the garbage collectors are in an appropriate mode that can keep up with generated garbage, etc.Try "java -X". You will see that you can decide what the "right" size is. See this link, a guy forces the JVM to run a web server on 16 mb of memory and still get decent performance [rifers.org]. [ Reply to This | ParentRe:Article somewhat ignores the fatness of the JVM by Bastian (Score:2)Sunday October 09, @11:30AMRe:Article somewhat ignores the fatness of the JVM by matfud (Score:1)Sunday October 09, @02:58PMRe:Article somewhat ignores the fatness of the JVM by Anonymous Coward (Score:1)Sunday October 09, @09:54AMRe:Article somewhat ignores the fatness of the JVM by expro (Score:2)Sunday October 09, @10:27AM1 reply beneath your current threshold.Re:Article somewhat ignores the fatness of the JVM by jherber (Score:1)Sunday October 09, @09:55AMRe:Article somewhat ignores the fatness of the JVM by eraserewind (Score:2)Sunday October 09, @10:10AMRe:Article somewhat ignores the fatness of the JVM by expro (Score:3)Sunday October 09, @10:20AMRe:Article somewhat ignores the fatness of the JVM by hedge_death_shootout (Score:1)Sunday October 09, @10:25AMRe:Article somewhat ignores the fatness of the JVM by NormalVisual (Score:2)Sunday October 09, @11:00AMRe:Article somewhat ignores the fatness of the JVM by hedge_death_shootout (Score:1)Sunday October 09, @11:13AMFirefox, with its layers, is way better than Java by expro (Score:2)Sunday October 09, @11:17AM1 reply beneath your current threshold.You may see a diff in 1.5 by willCode4Beer.com (Score:2)Sunday October 09, @10:42AM1 reply beneath your current threshold.Re:Article somewhat ignores the fatness of the JVM by dnoyeb (Score:2)Sunday October 09, @11:59AMRe:Article somewhat ignores the fatness of the JVM by dnoyeb (Score:2)Sunday October 09, @12:01PMRe:Article somewhat ignores the fatness of the JVM by sulam (Score:1)Sunday October 09, @12:04PMRe:Article somewhat ignores the fatness of the JVM by dubl-u (Score:1)Sunday October 09, @01:20PMRe:Article somewhat ignores the fatness of the JVM by Hurricane78 (Score:1)Sunday October 09, @01:24PMRe:Article somewhat ignores the fatness of the JVM by Wastl (Score:2)Sunday October 09, @03:00PM2 replies beneath your current threshold. Article Actually Argues Something Else (Score:5, Informative) by PepeGSay (847429) on Sunday October 09, @09:37AM (#13750237) This article is actually debunking some people's reasons why Java has poor performance. It does little to debunk my actual real world experience that it *is* slow. I'm glad to see that performance has increased alot, but I remember some all (well 90% or something) Java applications, like the original JBuilder, that made me want to claw my eyeballs out when using them. Those apps and other early apps are where Java's performance issues really took hold in many people's psyche. [ Reply to This Re:Article Actually Argues Something Else (Score:4, Insightful) by NeoBeans (591740) * on Sunday October 09, @10:27AM (#13750397) (http://www.neobeans.com/blog) I remember some all (well 90% or something) Java applications, like the original JBuilder, that made me want to claw my eyeballs out when using them. Valid point... for 1999. But Java has been through a lot of changes since "the original JBuilder" came out. There have been three major changes to the class libraries (1.2 [sun.com], 1.4 [sun.com], and the 5.0 [sun.com]).Honestly, I understand why people are down on Java -- it's because there have always been two strengths to the Java "platform":It provides a simple programming model (single inheritance, indirect memory management, ...)A rich class library for specific tasks that are easy to learn (but difficult to master, obviously). ...and early implementations weren't able to keep up with native code in any way, shape or form.That said, I think you hit the nail ont the head -- people are still thinking in terms of 1999 and not 2005 when they think of Java -- at least on Slashdot. But the typical Java developer is busy writing enterprise apps, not writing kernel code, device drivers, or anything else that requires C/C++. [ Reply to This | ParentRe:Article Actually Argues Something Else by Bastian (Score:2)Sunday October 09, @11:35AMRe:Article Actually Argues Something Else by Decaff (Score:2)Sunday October 09, @03:21PM