> The slowness in loading an applet is not to do with the disk cache.

I thinkn it's more correct to say that the disk cache is not the only startup problem. I believe it's the most egregious, since the startup at first launch time is something like an order of magnitude slower than startup when the VM is warmed up.

I should also point out that for this comment:

> having run eclipse and lots of other Java apps has no effect on applet start times

you're not necessarily comparing the right things here. For example, if you run a Java app with its own JRE (for example, I assume that Eclipse uses its own private JRE), then having loaded that VM has nothing to do with loading the VM of the default JRE for the browser. So you can run these other Java apps all day and not affect the coldstart/disk-cache issues mentioned in the interview.

However, the other factors mentioned are also important.
- Plugin: There is extra overhead to loading the plugin itself, beyond loading the VM. In practice, this tends to be on the order of a second. I would like to see this improve, and some work that we're doing for the next JDK should help here. But I would still argue that this second is less significant than the ~5-10+ seconds for a coldstart launch of an applet.
- freeze: The current plugin model in Internet Explorer loads the plugin in the native thread of the browser itself, which causes the browser to hang during loading. I agree that this ends up with a pretty awful experience, especially in the coldstart cases I mentioned (any app hanging for 10 seconds for no obvious reason is Not Good). The work going on for plugin above also includes looking into changing this model to separate the plugin thread from the browser thread; I hope that we can do this successfully. But in the meantime, the work on improving coldstart as well as plugin loading overall should make any browser freezing during load less of an issue.