Name: ddT132432 Date: 09/04/2001
java version "1.4.0-beta_refresh"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta_refresh-b71)
Java HotSpot(TM) Client VM (build 1.4-internal, mixed mode)
This is a feature request, not for regular functionality of the JDK but for
better support for Java developers. Filed against Swing, though applies equally
In JDK 1.4 there is the assertion facility which helps developers ensure that
their code is functioning properly, with zero overhead for production users. One
place I have found where this would be extremely helpful is in the area of
In simple GUI applications with no special threads, it is hard to mess up with
threading since everything happens in the event thread. However large, complex
GUI applications (in my experience: NetBeans/Forte for Java) do many things in
special threads, such as slow I/O or background processing. In principle all
interactions should then use e.g. SwingUtilities.invokeLater() to safely
synchronize with the event thread. In practice you never catch all such cases
and it is often forgotten.
Unfortunately symptoms of forgetting are extremely obscure. In many cases
everything seems to work just fine, 99% of the time. When it fails, the failure
may take a form that does not help trace the problem. For example, a
NullPointerException may be thrown, with a stack trace thirty calls deep, almost
all methods being inside JDK code--perhaps because the application code changed
some GUI component's property from outside the event thread and various internal
state is corrupt.
Since these problems are so hard to find indirectly, it would be very helpful if
there were an assertion category (which could be enabled in bulk with a
commandline switch) that would begin checking thread usage for all API calls
into AWT or Swing. Probably instrumentation of only a selected handful of
methods would be enough: say, Component.getPreferredSize or other
layout-manager-related calls. If such methods are called outside the event
thread, it probably means trouble.
Another place to insert checks would be anything which adjusts focus--we have
had terrible Swing-related focus bugs, which might be our fault for asking for
focus from the wrong thread or otherwise making focus-related calls in the wrong
order or under the wrong circumstances, but in a large body of code it is very
difficult to trace where something like this might have happened.
To date I have seen colleagues manually create test versions of JDK classes
(private of course) with System.err.println()'s every time something bad
happens. Naturally it would be far nicer to be able to just turn on a standard
assert and find violations; the JDK team can know for sure what is and is not a
legal use of a method, since they are in control of the API and understand its
Good use of assertions here could also potentially reduce the bug burden on the
JDK team: incoming reports with suspicious-looking stack traces indicating
possible data corruption could be evaluated according to whether the application
run under assertions is clean.
(Review ID: 131265)