Actually, I wonder why that is. I always thought that it is Java itself which makes Java applications feel slow. But I haven't noticed this in Cyberduck. So maybe it is just AWT.

I wonder why that might be. Maybe because AWT does all the drawing itself, which is much slower compared to the native toolkit?

My belief is that apart form some overhead in AWT against native toolkit, 90% of the laggish experience in java apps is due to poor coding.

In turn, this is probably a byproduct of the java platform/language (abuse threads cause they are easier than an event loop, abuse locking cause synchronized is more obvious than util.concurrent, avoid thinking of memory management cause you have a GC, do not pay attention to proper data structures cause you can get away with builtin collections etc)

Specific examples from your experience?

First one I think of (cause I redid it today, in ruby :) is:

you need to keep a list of lines you already processed in a large log analysis. I'd just use a Set (which is a hash underneath) and get done, although I'd have saved a bunch of overhead (memory allocations, gc pressure) using a bloom filter.

Using a (hash)set instead of a bloom filter caused memory usage to explode, which in turn led to memory thrashing/swapping which in turn led to slow processing times.

The rest of the code runs in constant time (well, linear in the size of the item, with num(items) >> size(items[n]) ) and it did work fine for smaller inputs.