Not totally. We support a number of java applets at work. The clients still take "way too long" to load and feel bloated. "Way too long" is a subjective measure based on the current hardware/OS. For a JVM to not feel slow it would have to speed up relative to itself...and I haven't seen them do that.

If it's specific apps, usually it is just bad coding. 'Enterprise Java' style coding where performance is not even tested for, let alone designed into the algorithms.

Usually culprits are things like downloading multiple data files in a single threaded block, or insanely deep object graphs with thousands of memory fetches per real operation.

That's not really anything to do with the technique (code in browsers) or the runtime (JVM) or even the programming language (Java) -- and everything to do with poor development.

They're not really enterprise apps. They're just betting odds displays. But I hear you on the criticism of enterprise software still. I just don't think it's the thing here.

Why would betting odds displays escape from Enterprise Java? Seems like the kind of thing that would get it in spades for regulatory and CYA reasons.

They could still be enterprise apps. From what I've seen of them, they appear to be little more than what you'd get off espn if espn were 100% betting. My point is it's not the system that they use to sync up lines and whatever...I think.

This outlook is why lots of people have to go to work and deal with absurdly slow trash software written to run on absurdly fast hardware.

No. I'm not saying terribly designed, lazily coded enterprise apps are ok, I'm saying if Java can be fast on a $200 mobile phone, it can be fast on a desktop.

> I'm saying if Java can be fast on a $200 mobile phone, it can be fast on a desktop.

It's not fast on a $200 mobile phone though. It's still pathetically slow.