Java is Slow! - A Cautionary Tale

Discussions

News: Java is Slow! - A Cautionary Tale

  1. Java is Slow! - A Cautionary Tale (54 messages)

    Here is a cautionary tale for those who claim that "Java is too slow!" We all know the type. This is also a cautionary tale against those clueless "engineers" who reinvent the wheel (e.g. hand-coding DB4O and threads messaging instead of using ActiveMQ/JMS) with a kludge because "they want to see the data" and don't trust Java best practices. From the article:
    "You're a developer, not a hacker," Dick ranted after being shown the Java prototype, "we already have the right tools for the job at our hands. Anything that must be run as bytecode through a virtual machine will always be ten times slower!" ... "Dick insisted that, if we were to interface with your system, then we'd have to write everything to text files for reliability. He likes to have the data around where he can see it. To the best that we can tell, he just didn't trust the whole Java and database thing."
    Beware of the clueless or inexperienced C/C++/Perl dabbler in your midst!

    Threaded Messages (54)

  2. Here is a cautionary tale for those who claim that "Java is too slow!" We all know the type. This is also a cautionary tale against those clueless "engineers" who reinvent the wheel (e.g. hand-coding DB4O and threads messaging instead of using ActiveMQ/JMS) with a kludge because "they want to see the data" and don't trust Java best practices.

    From the article:
    "You're a developer, not a hacker," Dick ranted after being shown the Java prototype, "we already have the right tools for the job at our hands. Anything that must be run as bytecode through a virtual machine will always be ten times slower!"
    ...
    "Dick insisted that, if we were to interface with your system, then we'd have to write everything to text files for reliability. He likes to have the data around where he can see it. To the best that we can tell, he just didn't trust the whole Java and database thing."
    Beware of the clueless or inexperienced C/C++/Perl dabbler in your midst!
    Man, this so much reminded me of my first job fresh out of university when I worked as a programmer at a Microsoft Shop. My supervisor was similar to Dick, and he was the company's senior programmer, but he always insisted on doing things from scratch in C, even though I tried to convince management and him that C was not ideal for everything and it often led to programmers re-inventing the wheel for many common problems which unlike the java tech space, there were many things already built for which you just plug them into your app and go. But the usual response was that Java was too slow (i.e. byte code execution), and seeing that he was the senior programmer, our old school management team always went with his call. I can't begin to tell you how painful it was for me to end up building medium to large scale client server apps in C and Visual Basic. And don't even talk about the size and severity of the bug lists - remember, things were usually built from the ground up, including security. I had to leave the company to save my sanity - been happy ever since in Java land.
  3. db4o performance a fault[ Go to top ]

    Just had to comment on the cautionary example's use of db4o ;-) Absolutely hilarious ..... and I agree...just because something is wicked fast doesn't mean you use it to mix the cake batter. You can end up with egg on your face. Cheers, -Robert db4o - The Database for Developers ..right tool for the job
  4. Java slow than C++[ Go to top ]

    Anybody that has ever used a non-trivial Java program or has programmed in Java knows that Java is slower than native programs written in C++. This is a fact of life, something that we accept when we use Java. However, many folks would like to convince us that this is just a temporary condition. Java is not slow by design, they say. Instead, it is slow because today's JIT implementations are relatively young and don't do all the optimizations they could. This is incorrect. No matter how good the JITs get, Java will always be slower than C++.
  5. Yes. Java is too slow[ Go to top ]

    Yes. Java is too slow. I'm not talking about runtime performance but in innovation in the language. I'm talking about just the language and platform. Not frameworks/open source efforts. Closures anyone? The way Java 7 is going, it isn't too re-assuring.
  6. Btw.. The actual story did make me crack up :-)
  7. Re: Yes. Java is too slow[ Go to top ]

    Yes. Java is too slow. I'm not talking about runtime performance but in innovation in the language. I'm talking about just the language and platform. Not frameworks/open source efforts. Closures anyone?

    The way Java 7 is going, it isn't too re-assuring.
    This is Java's MO. There are plenty of languages that add features faster than you can keep up with them. In some ways this is it's strength. A lot of languages burn-out and become unpopular because of the weight of all the features they have.
  8. Re: Yes. Java is too slow[ Go to top ]

    Yes. Java is too slow. I'm not talking about runtime performance but in innovation in the language. I'm talking about just the language and platform. Not frameworks/open source efforts. Closures anyone?

    The way Java 7 is going, it isn't too re-assuring.


    This is Java's MO. There are plenty of languages that add features faster than you can keep up with them. In some ways this is it's strength. A lot of languages burn-out and become unpopular because of the weight of all the features they have.
    Man, you are taking the words out of my mouth. Some degree of innovation is good, but going too fast is never that good. Let just think that many house are still using 1.4; (there might even be some stuck in 1.3). Pacing the innovation race allow those trailing houses to catch up. Waiting for everybody to reach a good maturity level on 1.5/1.6 can only lead to a stronger adoption of 1.7 when the majority will be ready (IMHO). On the other hand, going too far too fast without waiting for those trailing houses to catch up a little bit will only lead to more resistance (IMHO again). ZC.
  9. java is slow[ Go to top ]

    sun sold java to oracle , when it became evident - java cannot compete with new languages.
  10. Re: java is slow[ Go to top ]

    sun sold java to oracle , when it became evident - java cannot compete with new languages.
    Hmm, I am not sure if I got this wrong or you, but wasn't Sun sold to Oracle as a whole and not just Java, and as a consequence Java also changed hands to Oracle. However, if you believe some "internal sources", Oracle actually bought Sun *because* of Java since it considers it it's greatest asset, besides it huge customer base in financial services and government and its brand. Just my 2 cents... But, back to the original topic: There are actually some benchmarks showing that these days a well written Java application on a modern JVM and OS can perform better than a native, speak C/C++, application. So, this tells me that a) Java and its performance has come a long way, and b) Java is definitely not slow!
  11. Re: java is slow[ Go to top ]

    I though that ALL Sun was sold to Oracle, not just Java
  12. Out of my experience, Java IS slow. Sometimes it is VERY slow. You may get acceptable performance, but the number of traps to work around will be higher than with other languages. I have seen C# performing better than C. Never seen that with Java. My best guess is that C# compiles everything to native while Java compiles what the VM considers necessary. As soon as the VM makes a mistake, Java fails. Java is VERY memory hungry when compared to other languages. And it is STILL necessary to instruct the VM how exactly memory hungry it should be in order not to crash. Those who say Java is not slow actually say that in many cases it is NOT UNACCEPTABLY slow. Java has not perished yet for exactly one reason: it makes software development more predictable. Where 100 mediocre Java programmers have 80% probability to complete a project in 2 years and require 3 servers to run it, 5 good Ruby programmers have 30% probability to complete the same project in 6 months and run it on a low end PC. In a corporate environment that makes Java a clear winner.
  13. Yes. Java is too slow. I'm not talking about runtime performance but in innovation in the language.
    And how exactly is C++ doing any better there? Wasn't the x in C++0x supposed to be a 3 initially? Currently it probably even won't become a 9. Now the last language innovations where in 1998, that's at least a 12 year time span without any innovation. The std library had a minor update in 2003 orso. This was the kind of update that would seem small for a point update in Java (i.e. Java 6 u8 to u9).
  14. I was just reading a post on a forum from someone who wrote an XML parser in RPG because the XML package they have "works, but it is S---L---O---W. (It's written in Java.)" Of course there are plenty of Java programmers that think WS* is the only web-service technology going. It's quite easy to become "Dick".
  15. I will take a leap of logic and assume this is an AS/400 platform, on account of the use of RPG. To my chagrin, I know a bit about Java on the AS/400 and it's typical [mis]use on that platform. Part of the problem is that the JVM startup time is huge. The AS/400 has its own "native" byte code optimizer which can invoked from QShell or through the excellent JTOpen java class library. This makes a pretty big difference, but I have observed it is rarely used. More to the point, java is frequently used for one time invocations and I would say with 75% certainty that your RPG enthusiast friend was calling a new instance of a JVM to parse each XML fragment rather than the prescribed architecture of keeping a JVM running all the time and passing tasks to it. Virtually any byte code oriented virtual machine will perform poorly when used in this way. We actually run a JBoss application server on the AS/400 and once it fires up, it performs quite well, including XML parsing. I should also point out that OS/400 has been shipping with an RPG based XML parser for some time, and while I have heard it is cumbersome to use, it is quite performant and makes me pause to wonder why your RPG enthusiast friend would write his own parser when already being in possession of two provided by IBM. I am sure there was a good reason, however.
  16. I will take a leap of logic and assume this is an AS/400 platform, on account of the use of RPG. To my chagrin, I know a bit about Java on the AS/400 and it's typical [mis]use on that platform. Part of the problem is that the JVM startup time is huge. The AS/400 has its own "native" byte code optimizer which can invoked from QShell or through the excellent JTOpen java class library. This makes a pretty big difference, but I have observed it is rarely used.
    I do some work on the 400 and in current versions the optimizer runs automatically. I think not at the highest level but I've seen some things that suggest to me that the 40 level optimization is buggy (or was.) The bigges performance problems I've had with the 400 have had to do with a misconfigured memory pools that forced the application to thrash wildly on even smallish (30 MB) heaps. I've also found that doing a lot of IO to the IFS (e.g. trace logging) causes similar behaviors.
  17. To my chagrin, I know a bit about Java on the AS/400 and it's typical [mis]use on that platform. Part of the problem is that the JVM startup time is huge.
    I forgot to say that my experience is that the VM startup time (after the initial run) is not much more than I see in other environments. It matters if you submit the job or run it interactively but once I learned about the memory pools and not to do too much IO to the IFS, things run just fine. It's a challenging environment to run Java in to be sure partly because it's so hard to get any information. IBM's documentation is next to worthless. Maybe we should start a Java/400 forum somewhere.
  18. Too slow, perhaps[ Go to top ]

    While there is value in stability, there is also value in evolution, particularly toward some long-term goal. The Java programming language has nobody responsible for planning its evolution. The changes being considered for Java 7 are one-off, mainly unrelated features with little strategic value. There is no benevolent dictator for Java, and the Java ecosystem suffers as a result.
  19. Re: Too slow, perhaps[ Go to top ]

    While there is value in stability, there is also value in evolution, particularly toward some long-term goal. The Java programming language has nobody responsible for planning its evolution. The changes being considered for Java 7 are one-off, mainly unrelated features with little strategic value. There is no benevolent dictator for Java, and the Java ecosystem suffers as a result.
    I don't disagree with that but the point is that if Java were a language that was constantly adding features, I imagine a lot less people would be using it. What I mean is that a lot of the developers 'forced' to use Java wish it would get their favorite features but if it were the kind of language that had everyone's favorite features, they wouldn't be 'forced' to use it. They'd likely be bitching about a different slowly changing language. On the subject of Benevolent Dictators, I like Python but it's being ripped down to the studs to clear out all the garbage that's been added over the years, I think it's a pretty decent illustration of trade-offs in question. Not that Java's perfect or anythin, not by a long shot. The upshot is that IMO, it's not such a bad thing to have different languages with different strategies for change.
  20. I was just reading a post on a forum from someone who wrote an XML parser in RPG because the XML package they have "works, but it is S---L---O---W. (It's written in Java.)"

    Of course there are plenty of Java programmers that think WS* is the only web-service technology going. It's quite easy to become "Dick".
    And it didn't occur to you before you made this post that maybe that Java XML parser implementation may not have been optimal or maybe the person who was having the problem with that Java XML parser could have tried another one from the multitude of available Java parsers? You see, the deeper point behind the story of Dick and Pete, is that people like Dick normally do unnecessary programming activities, not directly related to the implementation of the business requirements, because they usually want to draw attention to themselves from management that they are the greatest thing in their organization aside from the mail server - i.e., doing Wylie Coyote style programming where they code both the application infrastructure code (e.g. their own custom application server, database servers, etc.) along with coding the actual business process aspects of the overall system. Rather than trusting the maturity or wide scale adoption of third party code or sub systems, they instinctively jump to building themselves what's already available . Modern software development practices, usually encourages you not to repeat yourself, or not to re-invent the wheel, unless you absolutely have to - meaning that you do the due diligence in googling around the web for someone or some company that has already built what you're looking for. Building an RPG XML parser sounds really Dickish to me. lol.
  21. And it didn't occur to you before you made this post that maybe that Java XML parser implementation may not have been optimal or maybe the person who was having the problem with that Java XML parser could have tried another one from the multitude of available Java parsers?
    Why would you think it didn't occur to me? That seems like a pretty stupid assumption. I expect that it was slow. It was the assumption that the reason was because it was written in Java. I actually suggested that he look at the setup on the system and that there are many ways tools to parse XML in Java.
  22. If you are working for Real time/missile application, you may have to consider 1/10000 of the second. Most of the enterprise application needs faster response, however it doesn't mean/count 1/10000 of the second. So even if java runs slower it should be okay. Many times you don't have to re-invent the wheel. I do know the pain of writing each and every functionality on your own. In the Java land, most of them are already available, all we need to integrate it well.
  23. And it didn't occur to you before you made this post that maybe that Java XML parser implementation may not have been optimal or maybe the person who was having the problem with that Java XML parser could have tried another one from the multitude of available Java parsers?


    Why would you think it didn't occur to me? That seems like a pretty stupid assumption.

    I expect that it was slow. It was the assumption that the reason was because it was written in Java. I actually suggested that he look at the setup on the system and that there are many ways tools to parse XML in Java.
    You're all over the place here man. Why didn't you post this later part of your explanation in your first post? Your first post left the impression that the one Java XML parser that the dude was having a problem with led him to create an XML parser in RPG because Java is slow. Now you're saying in this post that you gave the dude suggestions on looking at system setup, and other tools to parse XML in Java. What are you really trying to communicate, or do you think the readers of your posts are psychic and can tell what you really want to say in your posts despite the information gaps, or that we can tell what you're going to say in your followup posts? Either way your posts seem confusing dude. Just read them over for yourself in the sequence written, and see for yourself.
  24. You're all over the place here man. Why didn't you post this later part of your explanation in your first post? Your first post left the impression that the one Java XML parser that the dude was having a problem with led him to create an XML parser in RPG because Java is slow.
    That's what he wrote (hence the quotation marks.) What's confusing about that?
    Now you're saying in this post that you gave the dude suggestions on looking at system setup, and other tools to parse XML in Java.
    How is that inconsistent with the above? He wrote that "Java is slow" I responded that Java isn't slow. Just because a given Java application is slow doesn't mean the language is the reason. What part of this are you struggling to understand?
    What are you really trying to communicate, or do you think the readers of your posts are psychic
    The irony here is that you appear to think you are psychic.
    and can tell what you really want to say in your posts despite the information gaps, or that we can tell what you're going to say in your followup posts?

    Either way your posts seem confusing dude. Just read them over for yourself in the sequence written, and see for yourself.
    I think you have a problem with reading comprehension. And if you are going to respond to someone with unprovoked snarkiness, I suggest you first get your shit correct.
  25. You're all over the place here man. Why didn't you post this later part of your explanation in your first post? Your first post left the impression that the one Java XML parser that the dude was having a problem with led him to create an XML parser in RPG because Java is slow.


    That's what he wrote (hence the quotation marks.) What's confusing about that?

    Now you're saying in this post that you gave the dude suggestions on looking at system setup, and other tools to parse XML in Java.


    How is that inconsistent with the above? He wrote that "Java is slow" I responded that Java isn't slow. Just because a given Java application is slow doesn't mean the language is the reason. What part of this are you struggling to understand?

    What are you really trying to communicate, or do you think the readers of your posts are psychic


    The irony here is that you appear to think you are psychic.

    and can tell what you really want to say in your posts despite the information gaps, or that we can tell what you're going to say in your followup posts?

    Either way your posts seem confusing dude. Just read them over for yourself in the sequence written, and see for yourself.


    I think you have a problem with reading comprehension. And if you are going to respond to someone with unprovoked snarkiness, I suggest you first get your shit correct.
    @J Watson So I see that you didn't take my advice to read through your posts to review the confusing aspects of it, particularly the first one and the original impression it seemed to bring across that the dude was justified to go and write his own RPG XML parser. Instead you're allowing your ego to cloud the rational part of your brain by instead concentrating your energies on flaming, and backtracking to save face, after I raised the matter of your confusing second and first posts. You should know that what you wrote is still there right? Go ahead man, whatever creams your coffee. I'm done with telling you. I'm guessing here that you didn't get the meaning of the story of Dick and Pete or even understand the title of the article. But that's ok, give it a day or two to settle in. lol.
  26. So I see that you didn't take my advice to read through your posts to review the confusing aspects of it, particularly the first one and the original impression it seemed to bring across that the dude was justified to go and write his own RPG XML parser.
    That's in your head. It has nothing to do with what I wrote. I never intended to suggest that nor is there anything in what I wrote that does.
  27. OMG!! Please oh please, somebody tell me that peoples like this dick don't exists anymore. This is an actualized tale of the 1960's isn't it ? ZC.
  28. OMG!! Please oh please, somebody tell me that peoples like this dick don't exists anymore.
    This is an actualized tale of the 1960's isn't it ?

    ZC.
    Oh, but they do. Have a look at this page from the Hypertable project: http://code.google.com/p/hypertable/wiki/WhyWeChoseCppOverJava On the plus side, at least the acknowledge that Java is good for "some things" Ryan-
  29. Your exemple of JMS is bad. We started using JMS... And it was infact far too slow. We tried many implementations etc. Then we went to simple TCP/IP (in java) and i was realy realy faster. And for our need, most of JMS was not necessary at all and need yet another server to manage it. At the beginning the client wanted message to be encoded in XML (with more than 20K message to send and receive per second)... Again it's was too slow and we then used Java Serialization. It's true java is slow, but using the right tool, even in JAVA is really important. For most IT needs, java is simply a good choice. If you need fine control of performance and low level concerns, instant responce and thing alike just go C/C++... But only if it's really needed.
  30. This has been an age-long (at least 10 years) complaint about Java and I have found in these 10 years that it's a load of bull****. I have implemented a number of highly transactional systems as well as GUI applications (yes, Swing) in Java that have run extremely fast. The top reasons I have found for Java being slow are 1. Lack of application of fundamentals of programming (such as taking care of the number of objects you create). Spring to some extent reduces this risk, if used correctly. The impact is the highest in Swing applications where layouts are nested too much just because someone didn't spend enough time to do the design properly. In some cases, even moving some unwanted "new"s out of loops will help things significantly. 2. Not using the right software and instead reinventing the wheel. I have used MQ Series for a distributed system that happily processed around 100,000 records or more per hour without any complaints. The average transaction was around 7ms. And it was all written in Java. 3. Not using threads optimally. One program that used the Java Advanced Imaging packaged processed and uploaded 50,000 images (each image around 200K) per hour easily when multiple threads were used (you have to of course check how many threads are optimal). 4. Not using a profiling tool to check your code. In the glory days of Borland, I used their OptimizeIt software - an excellent tool to detect object leaks, something that's ignored due to Java's garbage collection. 5. Finally, not tuning the JVM. After optimizing your code, you need to tune the GC so that it works for your application. Just leaving the defaults as they are (or just modifying the ms/mx values doesn't cut it). It's like expecting an auto-gear car to win in a drag race.
  31. This has been an age-long (at least 10 years) complaint about Java and I have found in these 10 years that it's a load of bull****.

    I have implemented a number of highly transactional systems as well as GUI applications (yes, Swing) in Java that have run extremely fast.
    I agree fully that especially today, it is complete nonsense. Most of the performance problems in Java programs are a result of bad design. It's common for people to retrieve objects into a huge list and then process them one at a time. Not only is this slow, it requires huge amounts of memory. Another thing is that it's common to see people doing things like this: for (int b; (b = istream.read()) >= 0;) { ostream.write((byte) b); } This is even considered "idiomatic Java" but it's (in my experience) up to 30 times slower than using a 1K array for the reads and writes. That means that you bring local file reads and writes down to networking speeds.
  32. Your exemple of JMS is bad. We started using JMS... And it was infact far too slow.

    We tried many implementations etc.

    Then we went to simple TCP/IP (in java) and i was realy realy faster.
    Iff plain old sockets-based passing works for you, then a message queue (like JMS impl) sounds like an overkill. MQs are used for rather different purpose than simple messaging; just like relational DBs are used for tasks where simple storage as text files wouldn't work. At the same time though JMS MQs can be tuned for very high message throughput, so it's not often that they are too slow for the task. And as to object serialization; it really depends on tools used. For example, results from: http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking indicate that xml-based serialization can be faster than regular Java serialization (and JSON even more so).
  33. If you read the article and then read the comments, you'll notice an interesting irony: that the most vocal commenter ("xtremezone" -- how cool is that? ;-) is basically the same person as the story is written about ("Dick"). There are two things you can always count on in our industry: * The surprising extent of ignorance, and the immunity it shows to education; and * A strong correlation between the depth of ignorance and the vociferousness of the individual possessing it. Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, .NET and C++
  34. * A strong correlation between the depth of ignorance and the vociferousness of the individual possessing it.
    I'd say that's a more universal rule.
  35. If you read the article and then read the comments, you'll notice an interesting irony: that the most vocal commenter ("xtremezone" -- how cool is that? ;-) is basically the same person as the story is written about ("Dick").

    There are two things you can always count on in our industry:

    * The surprising extent of ignorance, and the immunity it shows to education; and
    * A strong correlation between the depth of ignorance and the vociferousness of the individual possessing it.

    Peace,

    Cameron Purdy
    Oracle Coherence: Data Grid for Java, .NET and C++
    I'm going to take a stab at guessing that the commenter you're talking about is James Watson right? I mean, if you look at his first post (i.e. Confusing coded sentences.) and seeing how many posts followed (i.e. Most vocal commenter, having the most posts) for him to actually clear up what he was really trying to say in his first post. Most everybody else made their point very clear in their first post on their views of the story, and Watson's tidbit on the guy who wrote his RPG XML Parser. :-). He seemed to have redeemed himself much later though. Just count how many posts he has made to get to a point that could have been made from post one. Talk about redundancy in communicating. Maybe a LINT for redundant posts can help him out here. lol.
  36. I'm going to take a stab at guessing that the commenter you're talking about is James Watson right?
    James and I don't always agree, but he does tend to put a lot of thought into what he writes. I was primarily referring to the "xtremezone" poster from the DailyWTF comment thread: http://thedailywtf.com/Comments/Java-is-Slow!.aspx http://thedailywtf.com/Comments/Java-is-Slow!.aspx?pg=2 http://thedailywtf.com/Comments/Java-is-Slow!.aspx?pg=3 http://thedailywtf.com/Comments/Java-is-Slow!.aspx?pg=4 http://thedailywtf.com/Comments/Java-is-Slow!.aspx?pg=5 Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, .NET and C++
  37. I'm going to take a stab at guessing that the commenter you're talking about is James Watson right?


    James and I don't always agree, but he does tend to put a lot of thought into what he writes.

    I was primarily referring to the "xtremezone" poster from the DailyWTF comment thread:

    http://thedailywtf.com/Comments/Java-is-Slow!.aspx
    http://thedailywtf.com/Comments/Java-is-Slow!.aspx?pg=2
    http://thedailywtf.com/Comments/Java-is-Slow!.aspx?pg=3
    http://thedailywtf.com/Comments/Java-is-Slow!.aspx?pg=4
    http://thedailywtf.com/Comments/Java-is-Slow!.aspx?pg=5

    Peace,

    Cameron Purdy
    Oracle Coherence: Data Grid for Java, .NET and C++
    I have to agree with you on the latter, but not so sure on the "but ..." part of the former though. lol. Peace.
  38. James and I don't always agree, but he does tend to put a lot of thought into what he writes.
    Thanks, buddy. I think usually agree with you though.
  39. If you read the article and then read the comments, you'll notice an interesting irony: that the most vocal commenter ("xtremezone" -- how cool is that? ;-) is basically the same person as the story is written about ("Dick").

    There are two things you can always count on in our industry:

    * The surprising extent of ignorance, and the immunity it shows to education; and
    * A strong correlation between the depth of ignorance and the vociferousness of the individual possessing it.

    Peace,

    Cameron Purdy
    Oracle Coherence: Data Grid for Java, .NET and C++
    Yeah. And he likes ASP.Net. [scratch head] Obviously he has not done anything complex with it.
  40. Re: Java is Slow! - A Cautionary Tale[ Go to top ]

    There are two things you can always count on in our industry:

    * The surprising extent of ignorance, and the immunity it shows to education; and
    * A strong correlation between the depth of ignorance and the vociferousness of the individual possessing it.
    I cannot agree with this at all. On the contrary, there is no other "industry", where constant education is as rewarded as in our industry. Looking at the "industry" as a whole of course. A broad perspective is rather interesting and rewarding, since it allows you to judge what the latest product is all about - usually it is about renaming some well not concept or product and reselling it as the next silver bullet with a differnt name. This allows to sell textbook stuff like Pipes and Filters, Caching, Model-View-Controller, Object Oriented Databases as the next big thing. Mortage Certificates anyone?
  41. I cannot agree with this at all. On the contrary, there is no other "industry", where constant education is as rewarded as in our industry.
    I can think of lots of industries. Genomics, off the top of my head where constant education is much more rewarded. It could be an experience thing but I see people rewarded for phony education. Developers go to training courses about the next hot thing. 5 years later no one could care less about that same topic (e.g. CORBA.) I think what Cameron was referring to was real CS education. And if I am right in that assessment, I have to agree to a good extent. The software/IT industry is fad driven and chases after the mirage of tools that allow for commodity programmers.
  42. It could be an experience thing but I see people rewarded for phony education.
    I agree. I don't see people being reward for trully educating themselves. In fact, the ones who are rewarded are those who can climb the ladder. Typically these are people who can talk the talk but seldom walk the walk. There are places and ways to be rewarded for educating yourself (ie what Cameron did). But these are few.
  43. I think what Cameron was referring to was real CS education. And if I am right in that assessment, I have to agree to a good extent. The software/IT industry is fad driven and chases after the mirage of tools that allow for commodity programmers.
    Well, the Corba Training course may have been worthwhile if one had learned the general principles of remote communication. It can help a lot to judge the quality and applicabiliyt of todays "better" remoting technologies, like web services, EJBs, Spring Remoting etc. I think "real" CS education is desirable, but education is also very much about understanding and learning a toolset. If an engineer goes off to learn about a new piece of equipment or a new tool or a new software package for CAD or visualisation this is of course refered to as education - and rightly so. If a corporate developer goes off to learn about new language, application server or database features this is education as well.
  44. I cannot agree with this at all. On the contrary, there is no other "industry", where constant education is as rewarded as in our industry.


    I can think of lots of industries. Genomics, off the top of my head where constant education is much more rewarded.

    It could be an experience thing but I see people rewarded for phony education. Developers go to training courses about the next hot thing. 5 years later no one could care less about that same topic (e.g. CORBA.) I think what Cameron was referring to was real CS education. And if I am right in that assessment, I have to agree to a good extent. The software/IT industry is fad driven and chases after the mirage of tools that allow for commodity programmers.
    Well, every industry has its fads and wrong turns. I don't think software development is necessarily unique in that respect. I may change my mind someday, but today, I don't fear the commodity aspect. As anyone who's been in the business a while knows, the technology is one aspect. As James said, in 5 years, no one will care about today's technology. But you will always need to be able to to problem solve, to absorb the tech de jour, to play well with other teams, to be customer facing, to have vision, and to have passion if you are to truly stand out from the pack.
  45. I may change my mind someday, but today, I don't fear the commodity aspect. As anyone who's been in the business a while knows, the technology is one aspect.
    You are right not to fear the commodity developer idea. The reason is that it's not going to happen. Tools will get better and developers may become less technical but the core problem of translating requirements into working software is unchanged by this. The problem with the concept of commodity developers, or as I term it: technical typing, is that the tools that chase this goal tend to limit what the developer can do. This is ostensibly to keep people with limited technical skills from getting in over their heads. In my experience, however, is that skilled developers will ultimately take control of these tools and the limitations serve only to reduce the quality of the work those developers produce. In a nutshell, these types of tools fail in every aspect. Despite this reality being demonstrated time and time-again, IT management continues to buy the same snake-oil under different labels.
  46. The problem with the concept of commodity developers, or as I term it: technical typing, is that the tools that chase this goal tend to limit what the developer can do. [..]
    I think software developers should actively work to make their current roles obsolete. The more we do that, the more invaluable and irreplaceable we become .. Our ability to obsolete our current roles is what enables us to move to the next level. Someone's going to go there; we can choose to move forward ourselves, or to allow atrophy to set in while we watch others surge ahead. Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, .NET and C++
  47. The problem with the concept of commodity developers, or as I term it: technical typing, is that the tools that chase this goal tend to limit what the developer can do. [..]


    I think software developers should actively work to make their current roles obsolete. The more we do that, the more invaluable and irreplaceable we become ..

    Our ability to obsolete our current roles is what enables us to move to the next level. Someone's going to go there; we can choose to move forward ourselves, or to allow atrophy to set in while we watch others surge ahead.

    Peace,

    Cameron Purdy
    Oracle Coherence: Data Grid for Java, .NET and C++
    I think this is orthogonal to my point. It's good to say "we can do better" or "this can be automated" and continually improve in terms of efficiency and quality. There are tools that do this. But the tools I am talking about don't do that. They basically attempt to take one thing that a developer can do and make it possible for a less qualified developer to do it. There is no improvement in quality (usually quite the opposite) and eventually in every case I've seen, more qualified developers need to be brought in to fix the mess that results. Because these tools do not provide the necessary tools to provide quality results, these developers then put time and effort into working around the limitations of the tool in order to achieve mediocrity instead of providing good software. Where I work we use one such tool and we now have more staff than we ever before because it has a constant development curve for new tasks as it lacks any meaningful way of reusing logic. Each new task requires as much effort as the first. Any change in approach must be multiplied by the tasks that were done before (we are now in the task times 1000+ range). We basically have expensive resources executing repetitive tasks. What I am NOT saying is that tools don't matter or that tools can make things better. What I am saying is there is a big difference between the goal of providing developers with more powerful, robust, and efficient tools and eliminating the need for skilled developers. The first one is a good idea. The second one is a pipe dream, as far as I am concerned.
  48. If you read the article and then read the comments, you'll notice an interesting irony: that the most vocal commenter ("xtremezone" -- how cool is that? ;-) is basically the same person as the story is written about ("Dick").

    There are two things you can always count on in our industry:

    * The surprising extent of ignorance, and the immunity it shows to education; and
    * A strong correlation between the depth of ignorance and the vociferousness of the individual possessing it.

    Peace,

    Cameron Purdy
    Oracle Coherence: Data Grid for Java, .NET and C++
    Yeah. And he likes ASP.Net. [scratch head] Obviously he has not done anything complex with it.
  49. Has this actually happened...[ Go to top ]

    ...and if so, who was right? Java may not be slow now, but it *was* slow in the "late nineties". Talk about immature and instable database drivers, problems with the garbage collector. Even today, Java's memory model is less than perfect. Recently, I saw code from a shop that used "best practices" to access a relational database. This included scrapping a proven, fast, but somewhat tiresome process of access data (using stored procedures in the database) with - yes - Hibernate3. One of the reason to do so was (of course and equally tiresome, "platform independence" and getting the SQL right). Development was more or less a breeze, but the performance of the thing was, well, not quite what was hoped for. The reason was of course that the application did not bend the way Hibernate (or any ORM tool for that matter) would expect, since it consisted of a lot of data presented to the user that required various join operations on the database and updates that typically spanned multiple tables. You should have seen the stares when people looked at the actual SQL statements. At the end, a lot of custom SQL had to be placed into Hibernate to get good performance and most of the advantages of ORM were lost. Moreover, Hibernate Mappings are in the deployed EAR Files. Also, to fix a bug or change some behavior in the database stored procedure was orders of maginitudes easier that to prepare a new EAR File and get it through Quality Assurance. Thus, the result for some people was "Java is not only slow but also inflexible".
  50. Recently, I saw code from a shop that used "best practices" to access a relational database. This included scrapping a proven, fast, but somewhat tiresome process of access data (using stored procedures in the database) with - yes - Hibernate3.
    As in almost all cases, the problem here is not with Hibernate3, rather with the designers/developers. Hibernate never claimed to be the 'fastest' database access mechanism. It's an ORM tool, facilitating access of RDBM as objects. That's why it has support for named SQL queries and stored procedures. In one of my projects, we developed a matching routine (Lucene was at its infancy then) that connected to an AS/400 DB2 instance. We developed an ORM via Hibernate, which made the code quite flexible and easy to use, but we still kept certain core aspects of the routine in stored procedures. The result was a very fast search engine (around 100,000 queries an hour, almost 5 times faster than the AS/400 app we were replacing and enhancing). We also spent a lot of time logging the SQLs (using Spring's very nice AOP mechanism) and ensuring that all generated SQLs were tuned properly. The result... the bottleneck move from the application to DB2. The system was as fast as the time DB2 took to execute the stored procedure. Bottomline - don't blame the framework or the language. It's just a tool. It's up to the wielder of the tool to pick the right one for the occasion and apply it the right way.
  51. As in almost all cases, the problem here is not with Hibernate3, rather with the designers/developers. Hibernate never claimed to be the 'fastest' database access mechanism. It's an ORM tool, facilitating access of RDBM as objects. That's why it has support for named SQL queries and stored procedures.
    Of course the problem is not "with" Hibernate3. The problem is that a developer/designer has to choose from a limited toolset in order to create a maintainable solution. Even today, I'd say the toolset is actually to broad, meaning that it is to complex to really take into account all the aspects of the tools used (In the original example JMS was mentioned. Interesting enough JMS is quite complex to handle, since various messaging systems support it in various ways, let alone failover behavior, subtleties in transaction support etc.). That said, not only does "performance" matter. Development time is a critical factor in most projects as well. In the above example, Hibernate can be quicker to patch something together, but tuning it soon becomes as complex as tuning the original SQL in the first place.
  52. Even today, I'd say the toolset is actually to broad, meaning that it is to complex to really take into account all the aspects of the tools used (In the original example JMS was mentioned. Interesting enough JMS is quite complex to handle, since various messaging systems support it in various ways, let alone failover behavior, subtleties in transaction support etc.).
    True, but that's the con of having a democratic system than a monopolistic one, isn't it? Everyone thinks they can do it a little better than the other person. The onus is then on the developer to not be swayed by the 'latest' technology and even if so, pick it and use it only as appropriate. In your example, I fail to understand why they did not intersperse stored procedures or complex SQLs as applicable with Hibernate. Hibernate is great to map results into domain objects, but that doesn't mean you have to only use ORM. In case of JMS, although it can be complex, we primarily used just it's point-to-point communication and didn't really touch the publish-subscribe part or any of the more complex persistent storage options, because we didn't need them - and that's my point. You understand what's there but then select only what you need from the lot as it applies to you.
    In the above example, Hibernate can be quicker to patch something together, but tuning it soon becomes as complex as tuning the original SQL in the first place.
    I don't agree. I've worked with a number of successful Hibernate implementations that scaled extremely well. Hibernate, like any ORM software, relies on a fully normalized database. If the database is not normalized (such as too many composite primary keys, etc.), then Hibernate, or any other ORM tool for that matter, will be a pain to use and implement - mainly because it specifically is not designed that way.
  53. I don't agree. I've worked with a number of successful Hibernate implementations that scaled extremely well. Hibernate, like any ORM software, relies on a fully normalized database. If the database is not normalized (such as too many composite primary keys, etc.), then Hibernate, or any other ORM tool for that matter, will be a pain to use and implement - mainly because it specifically is not designed that way.
    Sure, I have seen successful projects with Hibernate and other ORMs as well. In particular when one can use the schema generation/updates and do a lot of prototyping wotk without ever leaving the Java layer. Nice. However in a lot of cases, database structure is given and is often rather ORM unfriendly. As soon as you do a lot of stored procedures / views etc., Hibernate scales of course - but so does plain JDBC and Hibernate gives you very little. It is in fact a lot easier and faster to implement a proper update statement compared to implementing a complex query. Strangely enough, we have a development paradigm called DRY which is extremely popular among modern developers - the same frequently use Hibernate. When used on the server side, Hibernate repeats itself quite a lot, since the session can not be used for caching (as it can be in thick client). ORM also loads a lot more data than what the client actually needs, since it needs to contain proper objects for handling subsequent saves of data rows.
  54. 1.0 and 1.1 was no match for compiled languages as I can remember. Nowadays I don't think there is any point in coding in C++ instead of java for performance. Many people still think Java is slow because it was slow in the early days. But things change and some people have too much earwax. Heh, well many java apps are still slow and sluggish, but that is just framework bloat... Not the language being slow.
  55. Back to basics[ Go to top ]

    Speed? What kind of application? A simple transaction to update a few database records or astronomical calculation or some maths calc like finding the value of PI using Gregory series and nn billion iterations? Obviously no one will use Java for astronmical calculations where many iterations are involved...Compiled languages are needed here... Java vs C++ - Java is slow...But that alone doesn't decide anything. How about an interactive application (called online olden days) where user has to updat a few database records? The speed needs to redefined here in terms of the actual CPU (Java + DBMS), elapsed time, wait time (from user's perspective) etc. The sum total is the deciding factor. But today's application frameworks make it confusing to measure all these in a meaningful way...I have often wondered 'who is stealing the CPU,,, how can my EJB wait for times like 1000+ seconds clocktime??' ? Java code, Weblogic code or the DBMS region!! Add a few more packages, and you have a complete mess.