Classpath developer guidelines
Index
Contents
java.lang.OutOfMemoryError problem
- Last edit: 2007-05-08 audriusa
Description: With GNU Classpath getting bigger, and especially after adding the 1.5 features, some compilers started to fail with the OutOfMemoryError during compilation. This frequently happens also if there is enough memory on the machine, as some compilers use only 64 Mb by default.
The problem arises when the compiler itself is written in Java and runs on some virtual machine. If no extra keys are given, some virtual machines (Cacao and also many proprietary implementations) terminate after the memory use exceeds 64 Mb. Usually more memory can be used if the -Xmx switch is given. For instance, the compiler startup line in the ecj compiler startup script (/usr/bin/ecj or some similar location) frequently looks like:
- java org.eclipse.jdt.internal.compiler.batch.Main "$@"
With Cacao or Sun's jre this may fail but can easily fixed by adding something like -Xmx400m after "java".
Some compilers support the -J-Xmx key (-J-Xmx512M, for instance). Such keys can be added to lib/Makefile's JCOMPILER for that particular compiler. Unfortunately, ecj seems currently ignoring this option.
The problem was never observed with gcj as it is has no such memory limitations. However gcj currently cannot compile generics and, to build the CVS version, must be replaced by ecj.
How to avoid Swing programming errors
EventQueue loops
- Last edit: 2005-10-19 rkennke
Description: Some method calls in the wrong place can cause serious traffic or even endless traffic on the AWT event queue. Most notably this is JComponent.revalidate() and JComponent.repaint(). Some background: both methods cause the RepaintManager to queue a work request on the AWT event queue. When the work request is dequeued and gets executed, the RepaintManager calls validate on all components that had revalidate() called before and paintImmediately (and thus more or less all the paint* methods in JComponent and the UI classes) for all components that had repaint() called. This also affects all the children of those components. Now what happens when you place a repaint() call within the scope of the validate() call? When the revalidate is dequeued and executed, it pushes the repaint request on the event queue, causing more work to be done. Now if the paint methods call a revalidate(), we have a loop, causing CPU load go up to 100% for nothing.
Here are some rules how to avoid this:
- Don't place repaint() or revalidate() calls within the scope of painting methods. This affects the JComponent.paint* methods as well as the UI paint* methods and all helper methods that are possibly called by one of those methods.
Don't place repaint() or revalidate() calls within the scope of the validation and layout methods. This affects mostly the layout managers. LayoutManagers should never trigger a repaint() or revalidate() themselves.
- Also avoid calling methods, that may call repaint() and or revalidate() in both of the above call scopes. Of course, the layout managers must call certain methods, that trigger repaint (like setSize()), that is ok, but for instance the paint methods should not fiddle with the sizes of components.
- As a general rule you should put revalidate() and repaint() calls only in property setter methods. When a property is changed that affects the look of a component (like backgroundColor) but not its layout/size, then you only need to call repaint() in the setter method. If the property change also affects the layout, then also call revalidate() before a repaint().
Chose non-conflicting field and method names
- Last edit: 2006-10-03 rschuster
- Description: While the Java Language specification allows that a field and a method may have the same name this will conflict with CNI header generation as it is done to every class in GCJ. In order to make importing of Classpath into GCJ easier take care that your classes do not have identical field and method names.