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

Question

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

Answer 1

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

Answer 2

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.