Re: Font size
Another question if I may: Java has automatic garbage collection.
In my applet I have this complicated class Mass_Spring_System
which is instantiated by
springs = new Mass_Spring_System (Nmasses, timestep);
You should eschew underscores in class names, method names and non-constant
variable names. Variables like "Nmasses" should begin with a lower-case
letter (unlike classes) and begin each subsequent compound word part with an
upper-case letter ("camelCase"), thus, "nMasses".
If I want to change e.g. the number of masses, I now do
springs = null;
You don't need to set springs to a throwaway null value.
springs = new Mass_Spring_System (newNmasses, timestep);
This will suffice.
It works, it is extremely simple, it has not produced problems so
far, but I am a little bit worried about it. Can the automatic
garbage collector really handle this?
Mass_Spring_System contains a lot of other things (like arrays of objects). To avoid memory
leaks, shouldn't I make them "null" separately through some kind
of "destructor" method in Mass_Spring_System?
What you should do is make sure those elements are not separately reachable.
For example, if you have a class:
public class Foo
private Bar bar;
public void setBar( Bar b )
bar = b;
public Bar getBar ()
and some other routine does:
Foo foo = new Foo();
foo.setBar( obtainABar() );
List<Bar> bars = new ArrayList<Bar>();
foos.add( foo.getBar() );
now the bars List contains a reference to the Bar. While the Foo can be
cleaned up, the Bar cannot until that reference is gone.
Setting elements to null is usually useless; for one thing that won't get rid
of the other references. For another, it falsely documents the algorithm.
Give up thinking of "destructors" in Java. You may think of "dispose()" or
"cleanup()" operations if the object manages a resource such as a database
Java actually favors short-lived objects that are allocated and quickly abandoned.
Scour around the java.sun.com site for articles on garbage collection. Also
IBM DeveloperWorks has a series of articles by Brian Goetz, some of which
address these matters.