I don't really agree with you Purgatory on your stance on Java. I will agree that it's slower than native in some areas, such as games and such.. but you can get around most of that with mixing java and C.. getting the benefits of Java for some things, while still using some C for specific reasons. That said, I've seen and been part of very large scale robust Swing desktop applications that are rock solid smooth on slower hardware. My point about you saying it's slow and it's not is that the mind set that most people have of it stems from over 10 years ago and for some reason most people can't seem to let that go. It really stems from the push for Java applets to be the next great web thing.. and how miserably they failed for a number of reasons, being slow was one of them. Funny thing is, you can embed applets now and they are pretty solid and very fast, as fast as Flash or anything else. Sun/Java community chose to put time into JavaFX instead however, because they knew that Java + applets had an imprinted bad taste on everyones brain, even people who had no idea what it really was.
Java was created to bridge the gap with cross platform development that was a major pain in the arse (and still is) and the various platforms, including at the time set top boxes. I still argue that if Java was really that slow, it would not be in so many devices. I think to be fair, Java was a bit easier to learn than C + various underlying processor architectures. If J2ME were done in C instead.. you'd have to figure out each phone architecture and learn the nuances of it to really utilize the various devices.
But, today, with JDK 1.6, the JIT is so effecient at turning bytecode into native code that many apps run faster because the JIT can actually monitor slower bytecode and speed it up better than a pure native compiler could primarily because it analyzes runtime performance bottlenecks. You could, no doubt, compile code, run it, watch slowness, and do that yourself in your code, keep recompiling it, etc. But in this case, java developers get the luxury of the java language and rich libraries and support, with the knowledge that the JIT will vastly increase the speed of slow segments of code. That could be a double edge sword.. some developers may rely on that and not care about the quality of their code. I personally have been an optimizing freak since my C days, always trying to wreak more speed while making my app smaller in size and less code.
Anywho, it's ok to agree to disagree.
Java was created to bridge the gap with cross platform development that was a major pain in the arse (and still is) and the various platforms, including at the time set top boxes. I still argue that if Java was really that slow, it would not be in so many devices. I think to be fair, Java was a bit easier to learn than C + various underlying processor architectures. If J2ME were done in C instead.. you'd have to figure out each phone architecture and learn the nuances of it to really utilize the various devices.
But, today, with JDK 1.6, the JIT is so effecient at turning bytecode into native code that many apps run faster because the JIT can actually monitor slower bytecode and speed it up better than a pure native compiler could primarily because it analyzes runtime performance bottlenecks. You could, no doubt, compile code, run it, watch slowness, and do that yourself in your code, keep recompiling it, etc. But in this case, java developers get the luxury of the java language and rich libraries and support, with the knowledge that the JIT will vastly increase the speed of slow segments of code. That could be a double edge sword.. some developers may rely on that and not care about the quality of their code. I personally have been an optimizing freak since my C days, always trying to wreak more speed while making my app smaller in size and less code.
Anywho, it's ok to agree to disagree.