There will likely never be a completely satisfying solution for this. In order to be portable you have to create a completely function portable GUI widget set. It will never look fully native because each platform has a different subset of features. Java ends up with a least common denomonator of them.

I suffer a noticable problem along these lines on Mac OS X. Java apps have their own menu bar. They don't use the Mac menu bar.




Is it safe to assume you had the exact same amount of memory on both platforms? You should have been able to troubleshoot better on Linux. How much VM was in play? Was it thrashing? What did the JVM pmap/pfiles look like? Being slow after exiting is likely caused by a bunch of swap space being in use. You shoved a bunch of idle pages out to the disk, and they don't come back until the MMU trips on them. If you were playing with one of the big Java dev apps, you probably have an app server hiding in the proc table somewhere.


Java memory managemant is kind of disingenious too. They teach new people that the garbage collector just takes care of things, but it's implementation dependant. System.gc() is a hint, not a mandate. If I had a nickel for every time I've had a developer say "but we called System.gc()".


Anyhow... I'm not much of a Java coder, or any other kind of coder for that matter. But I spend a lot of time doing server side QA on large highly scalable web apps. It can be made to work, and then it works well. I just wish it was easier to make it work well in the first place.


BTW - You've probably discovered a clue as to why I'm playing with 8051's. :-)


Rob