- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
I'd rather write a simple nested loop to iterate a large 2d array and have the compiler section it up so I don't thrash L1 cache than worry about doing it myself, especially when I want it unrolled too.
Admin
Your job is to make judgements and analyze crap. The java 2 thing was confusing for exactly 5 seconds, and then it was ignored. If you can't deal with marketroid crap, why are you even here?
you're the one who claimed that strings were arrays of chars and then bitched about how java strings are immutable. mutable strings is largely regarded as a mistake, so you're in the minority on this one.
re: constants, yes, of course you can pass a constant string as a parameter. Why wouldn't that work?
Admin
Admin
Apparently, you aren't smarter than a marketroid. I'm sorry.
You can't pass an object into a method in java period. A final const string is as close as you will get - at most the method can change the reference it's using. As many people have said, passing an immutable wrapped object ref will prevent the method from modifying the parm's members.
Now then, if you haven't done this in C++, you don't have const either - const is a suggestion, and can be cast away. Const, just like class visibility only works if the other programmers are acting in good faith.
Now then, you need to settle down and listen a little more if you want to get better at what you do.
Admin
Ahh, the 99% statistic! Why not just say "most"? :P
Admin
Admin
Because it doesn't use the const keyword. I'm just playing around, functionally they are the same.
Admin
There is a million and one reasons NOT to use a preprocessor directives. This is common knowledge for C++ developers.
Admin
C# is not bound to any platform. You even mentioned Mono in your post (and uh, it does count).
Compiling C# produces IL code, not machine code. So theoretically it could be executed on any platform with a virtual machine capable of executing the IL.
Admin
For the last time, C++ DOES NOT HAVE CONST CORRECTNESS. Please don't ever code in C++ again, thanks. And yes, there are plenty of ways to guarantee this in C# (and Java too I'm assuming; I'm not a Java coder).
Admin
Slower in CPU then what? When you say something like that you really should be more specific.
For pure 100% CPU bound number crunching algorithms, the performance of Java ranges from approximately 2x as fast to 3x times as slow when compared to C++. In a fair number of situations Java is nearly exactly as fast as C++, but C++ is more often 2x as fast then its 2x as slow. For some specific algorithms, C++ is 3x as fast.
It all depends on how well the actual run-time data can be used to optimize the algorithm. Java depends heavily on a very high-performance run-time optimizer, while C++ depends on a very high-performance static optimizer. Both have their virtues. As said, on some algorithms Java performs better, on some C++ performs better. Overall the two are nowadays at approximately the same level.
If you compare Java to PHP however, it becomes a completely different league. Algorithms implemented in Java can be a 100x(!) faster, in some occasions even almost up to 200x.
Still, as other posters have pointed out, a lot of business systems simply aren't about number crunching, but are a mix of CPU and IO, with IO typically being the more important aspect. That's precisely why a horribly slow language as PHP is still able to implement high performing web applications. Basically PHP simply isn't the one doing any heavy lifting. Typical PHP applications put request values in an SQL query, sent that to some DB and after a little while they'll iterate over the resultset to pump out some HTML.
Admin
Macros (i.e., via the #define directive) in particular are bad because they make the code obscure to the programmer and hide things that aren't obvious. However, there are still times where there is no other solution.
The main reason macros are bad is because the C++ compiler doesn't even know about them (they are substituted before it sees the code) so it has no way to know where the actual offending code is. As a result, tracking down errors that are the result of macro substitution is painful and error prone: you can be looking at valid code, but part of that code might be substituted with text that makes it invalid.
Admin
Admin
Admin
Oh come on, it does for all practical purposes. If you're going to const_cast the constness away (or declare all your class member variables 'mutable'), that's your own fault and nobody else's.
That said, these C++ vs Java debates are silly, and I think deep down in your hearts you ALL know this. Personally, my languages are C++, Python and Tcl. I've only had minimal exposure to Java and C#, but from all I've heard and read, in MOST cases there's not much to choose between these languages (C++, Java, C#), as far as performance is concerned. If you code your programs using efficient data structures / algorithms, either of those languages will more than cut the mustard. There may be some specialized cases where you may have to revert to C++ or even C (or ASM), but for the vast majority of applications this should be unnecessary. Oh, and I full believe that an interpreted language can do some things as fast or faster than C++, because sometimers the virtual machine will be able to make certain optimizations AT RUNTIME that can allow out it outpace functionally equivalent C++.
QUESTION: The one thing that kinda puts me off Java is the lack of RAII, which to me is one of the most essential tools a computer language can offer. In C++ this is easily doable by simply allocating RAII guard object on the stack. These objects will then perform cleanup when their destructor is run. Python offers RAII functionality via 'context managers'. In Incr Tcl, one can create 'local' objects, whose destructors is run as soon as the function they were created in is left. Last time I checked, Java didn't have anything like that, but then I haven't been doing any Java in ages. Does anybody know whether this has changed in the meantime?
Admin
C# is not supported outside of the MS platform. Mono is always a rev back and needs to be validated separately, so no, it doesn't count. Let's not talk about theory when discussing operating code.
/hoping xtremezone goes away
Admin
Exactly. You still have to install the equivalent components.
Admin
In other words, with a native program (written in any language and compiled to a supported binary format) you need:
With Java:
Count the points. :P You might notice an extra requirement for Java. :P
The JVM is essentially an interpreter. To my knowledge, your Java program is always interpreted (probably JIT compiled) by it before being fed to the processor. It isn't essentially the same. It's completely different.
And there's nothing wrong with that. But it means that in practice, Java will probably never be faster than C++ in more than a few select areas, where run-time analysis reveals a few useful optimizations.
My processor time AND memory are important to me. I don't want to waste them on needless layering and lazy programmers. In practice, Java can be replaced with a high-level language (like D) that is designed to abstract all platform specifics so that code doesn't need to be ported and can easily be compiled natively for each platform.
With that, Java sounds obsolete.
** EDIT **
This reminds me of an interesting note... It sounds like a huge WTF that static properties are implemented at the JVM level, not the program level... :-X When is that useful (for non-"constants")?
Admin
STFU indeed.
Admin
Java is technically a language and a platform, and you simply compiled the language to a native binary (which can be done with any language). That doesn't work with Java byte-code which was the point I was making (that is, you can't take Java byte-code to a fresh OS and run it without installing a JVM). Look at all of the Java applications used today. None of the popular ones are distributed as native binaries to my knowledge. They all require Java to be installed.
It's still not really the same thing. Java compiled to machine code would eliminate one of the problems I have with it.
Addendum (2009-05-13 22:00): <sigh/>
According to the Web site, applications still require about the same amount of RAM and disk space on end user machines as if used by Sun JRE...
Admin
Was the client rep named "Dick" ?
Admin
Yes it does. A program that casts away the const-ness of a const object is not a conforming C++ program.
Admin
Now I know you're trolling, but that doesn't give you a right to become downright offensive. So I'm a lazy programmer because I prefer not to waste time hunting obscure bugs that have to do with the fact that applications that do not run in a virtual machine have a tendency not to have all the bounds checking and security that a virtual machine offers?
Let me put it differently. When I started programming, which would have been in the early eighties, it wasn't just easy to completely hang/crash your computer whilst programming, it was in fact expected. You'd have to switch off your computer, switch it on again (which luckily took mere seconds) and reload your program from cassette tape.
Between then and now I've worked with Z80 assembler, 8088 assembler, 68000 assembler, several flavours of BASIC, (Turbo) Pascal, C on MS/DOS, C on the Amiga, C on Unix, C++ on Unix, Perl, Bourne Shell and a bunch of others that aren't worth mentioning. And Java, of course.
There's no way that I'll ever go back to an environment where I have to spend time on things that a computer could do for me, like all the things a JVM does for me. I've got better things to do.
And abstraction, yes, that's important too. Try writing an application on a Windows system that you test with a MySQL database, and then port it to Solaris with Oracle. If you're using something like Hibernate to abstract the database engine, you don't even need to change your SQL queries and recompile.
Your point keeps coming back that CPU time is more important than the time you spend developing. In other words, the computer is more expensive than you are. It's not something I would be particularly proud of, but then again I get paid rather well for programming in Java, so what do I know?
Admin
Admin
Admin
Ah, Eclipse, an awesome development environment.
Also, reposting FTW: - Went & looked up that java quake2 port previously mentioned, and interestingly it had benchmarks!
http://bytonic.de/html/benchmarks.html
Fullscreen (probably more reliant on CPU)
C - 315fps Java 1.5 - 250fps
Admin
I don't find myself getting caught by those kinds of bugs very often. I find it's relatively easy to track them down. I'm sure you're aware that debuggers and stack traces exist for native programs...
As for security, I'm not sure if you mean system security or application security, but operating systems are fully capable of handling system security (i.e., what memory addresses and/or resources your program can access) and I don't really see a difference between application security in C++ and Java applications (with the possible exception of buffer overruns, etc., in poorly written native code).
Absolutely. Abstraction is a good thing. There's nothing preventing abstraction from being written into C++ though. The reason C++'s standard library is so lacking is mostly because of its age. There are libraries and frameworks to fill in the gaps. Boost has a ton of functionality, though I'm not sure what exists for data layer abstraction. No, the time I spend USING is more important than the time I spend developing and it's related to CPU time. I don't care if it takes me 6 months to develop an application if it does what I need efficiently for the next 3 years.Time adds up quickly. I don't know about you, but if I could somehow count the time wasted on slow Java applications it would probably amount to a lot of wasted time.
And development time is directly affected by CPU time as well. You can only test an application's functionality as quickly as it can run. So if it takes more time to run then it will take you more time to test.
Maybe you need Java to hold your hand, but I don't. There is absolutely a time to use RAD tools and interpreted programs can be useful to get something simple done quickly, but personally for something that myself or others will be using a lot, I think it's worth the development time to build an efficient native program (even if you decide to prototype it in Java first).
Admin
My parents used to have problems with Excel, and were always asking me for help. I installed VisualStudio.NET and the full MSDN library onto their computer and told them to write their own spreadsheet application, and now they never ask me for help!
Admin
Well, it's STILL not in the current version of Java which at the time of writing this is Java 6 update 13. However, former Sun employee and designer of among others the collection framework in Java, Joshua Bloch, is currently making a strong argument to have this ability included in Java 7.
The original reason for leaving this very useful feature out might be exactly the same reason why enums and templates among others where left out: Java needed to remove a lot of 'redundant' and 'unnecessary' features to be able to position itself as the easy alternative to C++. Of course, beginners and people who program only occasionally for fun don't need RAII. Well, they basically would need it, but they will never understand that they'll need it. When Java took of as a development language for serious development, it became clear that leaving out all of this had been a mistake. Later versions of Java thus added enums, and something that captures one use case for which one typically uses templates in C++ (generics). Although Generics are but a shadow of C++'s templates, enums are actually better implemented in Java.
Currently try/finally is used in Java to make up for the missing RAII functionality. Hopefully Joshua's proposal will make it to Java 7. Java 7 is slated for a release in 2010, but release dates tend to slip by a year or so. This is one area where Java surely does better than C++, where release dates tend to slip by close to a decade. <ducks> :P
Admin
Well, that's good to hear. I might get my feet wet with Java some more then. And you're right, the pace at which C++ evolves IS painfully slow. I mean I understand the need to carefully review all decisions lest they turn out to be a mistake later on, but gosh ... it's been 6 years since the last C++ revision and it'll probably be one more before C++0x arrives. And then it'll be a couple of years before compiler vendors implement all the new features? ... :-(
Admin
LOL!! :D
Admin
Why?
Because of its lack of concurrent classes like ConcurrentHashMap, etc..?
Because of its lack of a TreeMap?
Or because of its failure to give you a reasonable way to handle timezones? (Don't say DateTimeOffset because it doesn't even have proper daylight savings handling)
Or maybe it is because of its VERY POORLY encapsulated database API? I mean.. I thought MS invented ODBC, they could at least have made a good copy of JDBC.
ASP.Net is awesome.. but .Net and C# are just Ok when compared to Java. In Java world the UI frameworks are mostly a mess (though Wicket and GWT are nice).
Admin
const_cast is used to interact with legacy interfaces. Any other use would be an abuse.
I'm not sure what you mean by you can't pass an object into a method. You can pass a reference to an object... I commonly refer to this as passing an object. Maybe that's wrong but that's what I say.
This whole comment flame war has mostly been C programmers who think they are C++ programmers vs Java and C# programmers who may or may not know what they are doing...
Admin
And again you come with this claim that Java is so slow, without ever trying to back it up with some evidence. What sort of applications do you write anyway? You haven't mentioned that, you've just been re-hashing the 'Java is slow' mantra.
Again, what sort of program? Note that the code I write runs on back-end servers, deals with very large amounts of data, and is very much bound by the database engine (Oracle) that we use. As said, Java is fast enough, because we don't do simulating of aircraft or nuclear explosions.But apparently you typically write programs where development time and deadlines are not an issue, but quick run times are? If you're working at a university, it could make sense, but please do enlighten us.
Admin
Java is indeed slow, as you can see for yourself by visiting any site with an embedded applet and watch Java painfully struggling to load, while the page displays a pathetic 'Applet loading' message.
Admin
why is the cpu execution still in focus when it comes to sw?
As many seem to say that it is maintainabillity that really makes sw usefull over time..then we could pay some performance pennalities in order to gain maintainabillity..one factor in this is portabillity.
we need to think in execution cykles of the sw not the cpu?
C++ and old hw thinking might screw up a lot. 1.cpu centrik seems really cilly as we have multiple cpu.. 2.OO thinking in the old code reuse way is cilly as reusabillity is really worthwhile first on high levels of abstraction.. Dicks argumentation that got him into trouble is that he did not understand what is the driving force behind his system. 1.adaptabillity to requirement changes is far more important than performance when in reasonable diffrencies. 2.integration that works is the responsibillity not of any older system but of the CIO. 3.If a faliure occurs and it is to be fixed and it is the interface techniqe between the applikations that causes the problem..only severe constraints should prevent you from updating the older app to a newer more effective interface.If it is not doable this should be a signal to rewrite in the other language. 4 cost of apps is not just the maintenance cost day by day.It can be total replacement cost if it is keept in to old environment.
Admin
Attempting to claim that Java has more installation dependencies than C++ is nonsense of the worst kind. C++ requires the biggest library of them all THE WHOLE OPERATING SYSTEM. It requires special servers - whatever it was compiled against.
Admin
Actually, that's the JVM that's starting up which is written in C++ so ... sorry, own-goal there I think. After the start-up time it is very fast.
What sort of solutions do you have for writing applets in C++? Oh, that's right .. none .. can't be done .. you'd wait forever which is veeery slow indeed.
To counter my own point. Install the latest version of Java and you'll find that the applets pop open very quickly. They managed to work round the buggy C++ .. eventually.
Admin
You can, however, take C++ from one machine to another without much extra work if your team is aware of platform specifics and everybody writes platform independent code (and all libraries used are either platform independent or equivalent functionality is pulled from platform specific libraries for all supported platforms). It isn't like C++ needs to be completely rewritten in order to work on another machine. There's nothing platform specific about C++, the language. It's the compiler implementations and operating systems that bring the specifics. And that stuff can easily be wrapped up just like Java wraps it. Reusing stable and powerful platform independent frameworks can really save you a lot of work.
In practice it usually isn't as convenient as Java, sure, but then again the end result is hopefully software that greatly outperforms the equivalent Java software and is that much more user-friendly for it. I hate waiting for computers to do things and therefore expect applications to perform as quickly as possible. Especially applications that I use a lot. Perhaps the way we use computers differs.
The right tool for my jorb right now is ASP.NET. I never said to use C/C++ (or other native alternatives) for everything. I wonder what your machine specs are. I haven't used NetBeans in about a year or two, but when I used it it was nearly unusable on decent hardware (albeit, it ran MUCH better in Linux than Windows). I spent much of my Java classes in college wishing it had been written in a native language.And actually, Visual Studio has become quite slow as well (at least, in my experience). I don't know if it was written in managed code or is just bloated, but I'd guess it's probably a little bit of both... :P
I find it refreshing to get home and develop in Vim. :D
Sure I do. If the code runs slower than native code then it will be slower to test than the equivalent native code. It doesn't matter if it's a full scale application (which still needs to be tested regardless of unit tests) or a unit test. It's common knowledge that Java is slow. I don't need to prove it. Anybody that doesn't believe me can install it and find themselves a nice Java application to use. Obviously a zealot will deny this. And maybe the Java applications that you use aren't slow. I don't know. The ones I've used have been.Slow is a relative term anyway. As somebody said earlier (maybe you, maybe not), on the backend you can throw hardware at it to make it perform adequately. Most users don't know what's happening in the backend and only experience the Java running on their own hardware. Even if the backend is fast because of lots of hardware, there are usually many many frontends that you don't have control over (and couldn't afford to anyway) that need to interface with the backend. If those are all written in Java, hardware might not be available to solve the problem.
By all means, if you can afford to make your Java applications perform well with hardware on the backend, go for Java. I don't care what you use on the backend as long as it performs well and works correctly. However, unless you're going to buy me an uber powerful gaming rig to use your frontend, write it in something less wasteful so it doesn't hog all my system's resources.
I develop Web applications at j0rb (and don't use C++ for it). As I said, we develop with ASP.NET (and still maintain legacy code in ASP).I never said to use C/C++/D/etc. for everything. However, there is absolutely a time to use it and IMHO the use for Java is a relatively small niche. Again, that's based on my personal experience running Java applications which obviously isn't like yours because you love it.
IMHO, the vague description the article gives doesn't give us enough information to make a technology decision. By the sound of it, the system will handle lots of data for an entire country and won't change much once written. To me, that sounds like a good candidate for native programs. I don't know that obviously. I know next to nothing about what this particular contracted company was being considered for. You don't know that Java was the right tool either though.
Admin
Admin
It is also common knowledge that people who write in ASP.NET are talentless and brain-dead. They're all VB6 drag'n'drop muppetts who've retrained using a Learn * in 24 hours book. They didn't have the design talent to get a PHP job or the programming skill to get a job writing real applications in Java/C++/C/... They use Windows because they're soulless corporate micro-drones and aren't smart enough to use a real shell. They once tried to install Linux but were confused when they didn't have to click Start to Stop their PC.
It turns out that 'common knowledge' isn't that reliable since one, or more, of my previous statements may be untrue.
Admin
Java requires AN operating system not A SPECIFIC operating system.
Point 1 isn't quite true since there are/were Java machines that had the JVM on bare metal - effectively it was the OS. This was an awful idea but, that aside, Java can run without an OS.
With each release of Java more and more of it is written in Java and it gets faster with each release. Make of that what you will.
Admin
Not enough to worry about.
Just because you rarely use a debugger (surely if Java catches more syntactic errors, the majority of bugs will require a debugger, being logic errors) just suggests a different technique. I know C++ coders who rarely use one, but the VS2005 one is by and large fantastic. There's plenty of static analysis tools for C++, ever heard of Lint?
Don't be silly, you can, if you want, write portable C++ code. I've come across it on several occasions. The difference is that you can also use platform specific libraries to leverage (really hate that word) specific functionality. It's there if you want it, and most people use it, probably because the majority of software is Windows based. Java doesn't offer that. Portability is a noble cause, but different things for different purposes, and if you don't need it for your requirements, why limit yourself for it?
I do, but I also work in an environment where performance is absolutely critical (and fits neither of your scenarios). For quick things I'll use C#. It's quicker than Java because VS2005 has one of the best IDEs out there (although I did particularly like IDEA [possibly the only one that I think had any real chance of beating it] when I did Java, although ReSharper changes the playing field) and because the framework has a better selection of commonly used things for the things I need to do. The performance critical stuff is done using C++, memory management, stability and speed are absolutely critical (in terms of life/death), and Java really doesn't quite cut it, however much it's improved.
What does compilation have to do with this? People are used to seeing slowish Java apps, I think some of that is perceived because Swing apps generally look dog. I really don't understand why you keep mixing dev/compile/run timings altogether. Different projects have different priorities, and if your company gets them consistently wrong then maybe you should leave (and yes, I've plenty of experience with rushed prototypes which are sold).
It IS slower than C++ on most operations. Evidence has been posted previously, and I'll quite happily collab to optimise some tests. The thing is, while it may be relatively negligible on some JVMs, the Sun JVM is woefully slow compared to other ones and that's what most people's experience of Java is, so yes, I think it's perfectly fair to call it slow.
Good for you. The thing is, his argument is completely irrelevant, and you claiming that Java is better because of dev-time is irrelevant as well. At the end of the day it's not how fast the language is but, as you rightly say, if it is "fast enough". For exactly the same that random optimising is stupid, complaining about language speeds when it's negligible is pointless unless you need that extra speed. If you have a company full of C++ devs who are shit hot you'll probably get better, more maintainable code than a mediocre Java coder. On the other hand if you have one stupid developer, he's less likely to do harm in your Java app. I'm trying to say it's all relative. There's a lot of stupid criticism of both languages but they both have very important usages, and if it fits your company and your requirements then there's no real reason to change it.
Admin
This is bollocks. What are you actually talking about. Idiot.
Cool, same with C++ then.
Yay, go Java! Why was it an awful idea? Try and explain it without making Java sound crap. Go on.
Well how about this, it gets faster because it doesn't have to constantly swap in and out of the JVM to run code. Logically the more Java code it runs the faster it'll get because it has to do less interfacing with a different language. Also, it'd be a kind of shit release if it didn't get faster wouldn't it.
What is actually wrong with you? If there wasn't a JVM to start up wouldn't it be a lot faster?
Why would anyone be stupid enough to try writing an applet in C++? It's like telling you to write a DirectX game in Java. Fucking dense.
So is the JVM fast or slow? Maybe if they weren't writing buggy C++ they wouldn't have to get round it.
Admin
Admin
And here we have it. Someone points out that you're a moron, but does you the service of not using the word moron and... you're off with your insults. Well, I shall hold back no more. You, sir, are a moron of the worst kind. I will answer the rest of your points below, but please note, this is purely for the interest of others. You are far too stupid to understand the reasoned discourse that has been occurring here.
So your point is that I can compile a C++ application on Linux, test it send it to my tester friend who uses windows and after he signs it off, deploy it on Solaris? No, I didn't think so. It turns out that cross-platorm applications and potentially cross-platform source code aren't the same thing.
Why would I want to do that? I'm being honest, not a trolling moron. At the time, the JVM in use didn't provide support for real-time or near real-time garbage collection algorithms which introduced more uncertainty in some operations than was appropriate - reading system-time for example.
What swapping in and out of the JVM are you talking about you buffoon (I thought I'd throw in a little of your own language there). If you had even a vague clue what the words coming from your pea-sized brain meant you'd be twice the man you are just now (hey, I can see why you like this, you shiftless fool). Everything is inside the JVM, there is nothing else.
Why would a new release be shit if it didn't get faster? That, like you, makes no sense.
If there wasn't a JVM wouldn't it be faster? Err, no. That doesn't make any sense, you demented swine. Flash applets don't have a JVM - it is also written in C++ - and it is slower at computation than a Java applet at run-time.
Why would it be stupid to write an applet in C++? Ohh, hold on. I see, you don't understand the words you're using. It turns out that you think the word applet means only a Java applet. Sorry, thank-you for playing on this weeks episode of "Let's see what the moron does with a keyboard".
In some future version of Silverlight you might actually be able to write applets in managed C++.
This is the core of your problem. Fast and slow are meaningless terms in this context (you worthless sack of excrement). As far as VMs go, the JVM is amongst the fastest. Is it fast enough for any particular application? That depends on the application and the hardware? Same with C++, C and ASM.
There is no right or wrong answer. If the application is performance sensitive, is the application suitable for parallelisation, then the JVM might be good. Is the application one where memory can be allocated and de-allocated deterministically, then C++ might be good. Does the application involved only the manipulation of very primitive types with simple algorithms, then C might be best. Is it single threaded and every instruction is vital, then ASM might be best.
Oh, and you're a fool (hadn't pointed out the obvious for a while)
Admin
But all the rest is true? Who'd have thought it, I thought I was just making a rhetorical point. My point stands, your protestations of loathing for the technologies you spend your life working in, notwithstanding. The two points of contention about common knowledge are that it is neither common, nor actually knowledge. If it was knowledge it would be built on a demonstrable foundation, which you obviously lack.
PS If you really hated the technologies you use, you'd get a better job, if you could.
Admin
Admin
This is not an issue with Java, it's an issue with the programmers who can't write a stable application. I could write a crap application in C++ that crashes all the time, but that doesn't mean that C++ performs poorly.
Admin
I've been building and deploying Java applications for over ten years, building and deploying across Windows, Linux and Solaris. I've never had any problems other than people hard-coding paths with backslashes that work on windows but not *nix. So, yeah, nothing's perfect. But I've never seen any other deviations.
Java isn't interpreted. There is no interpreter. Java is compiled to bytecode and then compiled to machine code dynamically by the JIT part of the VM. So it gets compiled twice.
Interestingly this second part can often produce faster code than an un-tuned C++ compiler because it can make use of processor specific extensions that you couldn't , or didn't, take advantage of when performing a generic "work on as many boxes as possible" build with C++. You certainly could use the same, or similar, optimisations in many cases but not all. The JVM can optimise based on run-time behaviour that a static compiler could never see. So for instance if a loop is called with a counter that is 2 most of the time, then the HotSpot compiler can unroll that loop at run-time for increased performance.
I'm not saying that Java is faster than C++ in general, but in some cases it is. There are now a very large number of potential deployment configurations, if you're only compiling for a single known platform you can get the best performance out of ASM, C, C++ and Java in ( probably ) that order. If you don't know the exact deployment platform hardware configuration then the runtime performance is not as clear. If you're creating general purpose apps, the number of potential deployment platforms is too large to create hardware optimised versions.
Interestingly the .NET model where an assembly is put through an optimising compile stage at deploy time seems like a really good middle ground.