Is Java's Swing really a "memory hog"?

I frequently hear that Java's Swing toolkit is considered a "memory hog" (s开发者_开发问答uch 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).

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".

I often use the word "bloated" for Swing to mean something slightly different:

Swing bundles everything it needs with itself, rather than using what's already provided.

What does that mean? It means that anything you use/see with Swing is drawn and entirely handled by Swing. By contrast, SWT actually uses the operating system's windows, so naturally it has less memory usage and less work to do on its own. The "windows" in Swing aren't really "windows", they're just made to look like windows. By contrast, SWT uses "real" windows, and lets the OS do a lot of their management.

Please see attached the test show it to be a draw in many cases:

Conclusion

It is hard to give a rule-of-thumb where SWT would outperform Swing, or vice versa. In some environments (e.g., Windows), SWT is a winner. In others (Linux, VMware hosting Windows), Swing and its redraw optimization outperform SWT significantly. Differences in performance are significant: factors of 2 and more are common, in either direction.

It is questionable how often Swing's capability of suppressing successive redraws is effective. It is very likely that in practice this is not a frequent occurence, as repeated update requests in a short period of time may be uncommon. In this case, results of the Swing Text Field (sync) test should be considered with greater credibility than those of the Swing Text Field test, as they approximate the resource usage more closely.

Initial expectation before performing this benchmark was to find SWT outperform Swing. This expectation stemmed from greater responsiveness of SWT-based Java applications (e.g., Eclipse IDE) compared to Swing-based applications. However, this expectation could not be quantitatively confirmed. It is possible that perceived responsiveness is a consequence of smaller time required to respond to user interaction, which involves not only drawing, but also detecting and responding to the user's action. Also, determinism (smaller standard deviation) could result in greater perceived responsiveness.

Source: "SWT Vs. Swing Performance Comparison" by Cosylab d.o.o