Hydrogen fuel cells might become viable in the future, who knows. That doesn't mean we shouldn't develop the technology, but in the meantime, we need alternate energy today, and you can buy and drive an electric car now. I plan to look closely at electric cars for my next vehicle. By the time (5-10 years) I'm ready for another, if fuel cells are available, I'll consider those too, but they don't help me now.

You're talking about the party that screams about deficits and the federal debt when they do not control the white house, yet passes measures that raise the deficit when they are in power.

Thinking logically won't help you understand politics. Here are the rough priorities of the GOP party (and Dems for that matter):

- Tell voters whatever it takes to get (re)elected,
- Promote legislation that satisfies their campaign contributors (i.e. big business),
- Do whatever it takes to block the other party from getting elected (into *any* office).

Do these priorities sometimes conflict? Sure. Is that a problem? Only if you make it a problem. You see?

Thanks. When you say:

That is the definition of a JIT I have always used, thus my confusion. All of the reasons you state are performance arguments against JIT, but there are other reasons for JIT compilation, including architecture independence. But since all the world's an x86 these days, that feels less important now than it did 15+ years ago.

Speaking of dynamic recompilation, back in 1998 or so I was running Windows NT on a Digital Alpha. Since there were few native apps, Digital included a translator to run Windows apps (Office etc.) compiled for x86 natively on Alpha, and I'm sure it was some sort of JIT. Those apps would run slowly the first time, but get noticeably faster the next 2-3 times they run. And it legitimately translated and ran the apps faster than a good Pentium Pro machine of the day. That was due to an edge that Alpha had over Intel, rather than software, but the hardware advantage didn't last long.

1) Sure. When I said "performs very well" I mean within an order of magnitude. I've heard claims that JIT technology will surpass ahead-of-time compilation. I don't quite believe that either, and at any rate it's clearly not there yet. I didn't claim the JIT was equally fast or faster, but it's close enough that there just wasn't a ton of people interested in using a compiler like gcj.

2) I'm skeptical that JIT requires a GC (in the general case, though for Java it is clearly required by the JVM). Do you have a reference for this claim?

3) Yes, and of course real Java code does bounds checking too. Back when I was using gcj extensively, I was finding examples of duplicate array bounds checks, one added by the developer and one inserted by the compiler. A good compiler should be able to eliminate the redundant check. At times this is hard, such as when the caller does the bounds checking, and does so in a different translation unit.

4) Interesting. There are examples, such as the complex type, that would be far more efficient as a value object. But I agree with your point that passing objects that are too large as value objects is probably counter-productive.

Mostly I agree with your points. Especially that Perl is dog slow.

A good JIT actually performs very well compared to ahead of time compiling, and can take advantage of execution profiling (for things like branch prediction) by deferring compilation until the bytecode runs a few times.

The main advantages of gcj are improved startup times, porting to unusual architectures, and maybe for memory constrained targets.

When comparing C++ performance to Java, there are many things to keep in mind aside from the JIT compiler:

- Java also has GC overhead. You get a fairer comparison by adding garbage collection to your C++ app. The performance effects of garbage collection are complicated, but one of the difficult problems is that it tends to fill the processor data cache with useless entries.
- Java adds overhead required by the JLS such as array bounds checking or class initialization tests.
- Exception handling can also impact code generation. Java requires null pointer dereferencing (for example) to be trapped and handled, which adds abnormal edges to a CFG which places restrictions on e.g. instruction scheduling. Strict expression evaluation order, required by the JLS, has the same effect.
- Java has a more limited type system. In particular objects other than primitive types cannot be passed by value, which tends to result in more frequent memory allocations, more garbage collection, and more pressure on the memory cache than languages that can make more efficient use of the stack.

The biggest reason worked stopped on gcj was the release of OpenJDK, since one of the main reasons for gcj in the first place was to have a fast and free Java runtime. OpenJDK satisfies both.

Alpha and MIPS are completely different than IA64. Alpha was a true RISC chip with a fixed 32-bit instruction length, superscalar, out-of-order execution. IA64 was a VLIW chip with in-order execution that relies on the compiler to do anything efficient.

HP made a fatal mistake cancelling PA-RISC and Alpha in favor of IA64. The could have picked either of the other two as a successor, and have been better off as a result. Instead they chose a dead-end, probably because (at the time) it looked like the entire hardware industry would go that way. Before SGI, IBM, Dell and others backed out.

I was a little surprised by GvR's answer to this. RHEL 6 ships with Python 2.6, last I checked, and we don't normally deviate from Red Hat packages without good reason. Getting the masses off pre-2.7 versions of Python will also entail releasing newer OS distributions and retiring older ones, both of which happen slowly.

Not everyone can keep up with the latest/greatest versions out there, especially when they have hundreds of servers and big legacy applications to support.

Why are you still using prefork? You have at least two good alternative MPMs, one of which can use epoll().

Alright, I'm with you. I'll bet that any apps you get from those "large" vendors are going to suck, Java or otherwise.

And "enterprise" software? Our company is arguably an "enterprise", though I have yet to use any enterprise software that felt it was designed for us. I don't get that market at all. Don't sell me software that does everything, give me instead something simple that integrates cleanly with all the other software I already use.

Try hanging out in the open source circles, like some of the Apache Java projects, if you want another perspective. Then again, you probably don't. Just trust me... lousy software that happens to be written in Java isn't a reflection of Java.

Perl faster than Java? Perl faster than .NET?

You've never benchmarked any of these yourself, have you? (Please tell me you're not talking about benchmarking some "Hello World" application that can be measured in microseconds...)

I won't go into details now, but Perl 5 is really *spectacularly bad* at runtime performance. Pretty much at the other end of the spectrum from C/C++/.NET/Java (all of which compile to native, whether ahead of time or JIT, and all of which perform in the same ballpark for typical applications).

Wow, this is new. A rational, reasonable argument from a self-described Java hater... not just another "Java is slow because it's interpreted" or "Java is insecure" bullcrap post.

I've seen legions of developers grow frustrated with the gigantic frameworks and libraries that have grown up around Java, and react by abandoning Java and building something insanely simple in another language.

I wish just one of those guys would have instead tried abandoning the bloated frameworks and instead build something insanely simple in Java. I've done that, and found it very satisfying. But I'm aware I'm firmly in the minority having tried that, and in more than one case some other engineer grabbed my small code and bloated it up again.

"...by experience with Java apps is that they are incredibly slow, rather unresponsive and crash often."

Then you have no experience with Java application development. Or you're trolling, whichever.

Or possibly you're talking about browser applets, but that's not what this story is about.

If you don't have knowledge on the topic to contribute, why post at all?

You're kidding, right? We've been using MySQL replication for 10 years in production. Multi-master replication, statement-based and row-based. We've replicated between servers adjacent in a rack and servers that are separated by thousands of miles. And for the most part, everything Just Works.

The product may not be as academically pure, or whatever, as Postgres but that doesn't matter in a business setting. We use the tools that get the job done. On the other hand our team has been trying for the past month to get a Postgres (actually EnterpriseDB) instance to run in multi-master replication, or replicate DDL, without success. As far as we can see those are not supported features which make it almost useless to us.

It's comical how envious Postgres backers seem to be of MySQL's commercial success. And the quality of intelligent, thoughtful discourse on this forum is discouraging. Guess slashdot isn't what it used to be :(

Stop judging MySQL users. We use it because it has simple, foolproof replication. Period. And that's a damn good reason.

I know also what Oracle and pgsql can do. I've used both.

Can't really agree more. My challenge is the "cool kids" come along and rebel against anything from the 90's. I've seen newcomers build in Python, Ruby, and (the latest) Node.JS.

All of those are interesting in their own right, but for what we do I don't see them really solving practical problems that we haven't solved before. Except for stroking someone's ego--that they seem to solve nicely.

And as pointed out elsewhere on this topic, it's not as though Java has stood still. The most common complaint I've heard is that Java is verbose and Java code has far too much boilerplate "junk" (I tend to agree for legacy code--things like useless getter/setter methods and needless interfaces drive me bonkers). Then I ask them, what have you tried in Java lately? If you try to write compact, readable, maintainable code, you'll find it's not only possible but straightforward. Pick a few patterns that work well for you and stick to them (like chaining methods together as a builder pattern--one of my favorites).