I frequently hear that Java’s Swing toolkit is considered a “memory hog” (such as this answer).
Is this…
A due to Swing’s architecture;
B inherent in Java’s memory management; or
C an unfounded claim that stems from a lack of understanding how memory allocation works (e.g. just because the Task Manager says an application has allocated x MB, it does not actually mean that it is actually using all of it)
I’m trying to find a concrete, objective analysis about Swing’s true memory requirements as compared to similar GUI toolkits (not necessarily Java).
Advertisement
Answer
Swing uses quite a lot of memory that’s true, but i would not qualify it as a “memory hog”.
As one reply says, in Swing, every component is painted by itself (no use of the OS original widgets), this is what makes Swing portable across platforn.
The Look’n’Feel concept is, from my viewpoint, very good, but it has of course some disadvantages (memory consumption). But I find this disadvantage largely counter-balanced by the possibility to instantly change the look and feel of an application with just one line of code. There are plainty of 3rd-party look’n’feels out there (some commercial, some open source) that can give some “friendly” look to your application.
Also, memory usage is also originated in the way JDK (until 6 at least) loads (or pre-loads) classes in memory: as far as I could see, at the second you run some Swing API in your code, the whole Swing library gets loaded altogether, even though you may not need to all widgets. That may possibly change in JDK7 (which I haven’t tested) and “Jigsaw”.