Hi everyone!
I was wondering, I've been doing some work with GridBagLayout, and have
noticed my overuse of
"= new GridBagCostraints". I decided to create a new class,
ReusableGridBagComponents, inherit from
GBC, and make a reset method. This reset method would reset the GBC's public
fields to their default values,
so I can use the same GBC to position a new component. (I'll just pass that
same RGBC to the getContentPane().add() method.)
Does this have any consequences to it? I had the mentality that more objects
== more heap use, so it was best to conserve that heap space.
Thanks in advance!
Jon A. Cruz - 28 Feb 2004 05:26 GMT
> "= new GridBagCostraints". I decided to create a new class,
> ReusableGridBagComponents, inherit from
> GBC, and make a reset method. This reset method would reset the GBC's public
> fields to their default values,
> so I can use the same GBC to position a new component. (I'll just pass that
> same RGBC to the getContentPane().add() method.)
Sounds like you were doing some good refactoring there.
Personally, instead of going with a subclass of constraints, I'd
probably make a static function to reset one.
Class SomeUtils
{
...
public static void resetGBConstraints( GridBagConstraints cnstr )
{
...
}
Doug Pardee - 28 Feb 2004 22:09 GMT
> I was wondering, I've been doing some work with GridBagLayout, and have
> noticed my overuse of
[quoted text clipped - 7 lines]
> Does this have any consequences to it? I had the mentality that more objects
> == more heap use, so it was best to conserve that heap space.
Although this seems like a logical thing to do, it is usually
counterproductive.
You save very little by keeping the object around. Sun claims that the
cost of allocating a new object is about 10 machine instructions.
Resetting the fields to their default values will take more than that.
Hanging onto the object when it isn't in use reduces the amount of
heap available to other objects. This is not usually a problem, but
for large objects it could be.
Hanging onto the object increases the time that each garbage
collection cycle takes, because the object has to be copied into the
new survivor space. The same applies to any objects referenced by the
retained object (Insets being the only one in a GridBagConstraints).
Dealing with the referenced object(s) adds another layer of work for
the garbage collector.
When the retained object has been around for long enough, the garbage
collector will decide that it is a "permanent" object and move it into
the tenured generation. This adds another layer of complication for
the garbage collector if the GridBagConstraints in the tenured
generation is assigned an Insets object that is in the new generation.
It is the nature of Java that temporary objects are created and
discarded at an awesome rate. The last time that I counted, reading a
simple text line in from System.in resulted in creating and discarding
no less than a *dozen* temporary objects. The Java object allocation
and garbage collection systems are heavily optimized for that kind of
behavior, and do not perform as well for objects that stick around.
You might also find "Java theory and practice: Garbage collection and
performance; Hints, tips, and myths about writing garbage
collection-friendly classes" --
http://www-106.ibm.com/developerworks/library/j-jtp01274.html -- to be
enlightening.