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 to AWT. 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 AWT/Swing threading. 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 fine points. 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) ======================================================================
|