JDK-6201171 : Resizing a textarea repeatedly throws a ClassCastException on XToolkit
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2004-11-29
  • Updated: 2011-01-19
  • Resolved: 2005-05-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6Resolved
Related Reports
Relates :  
JDK-5065001 - awt TextArea crashes HotSpot on winXP when frame is closed
Description
I have written an application having a frame that will be maximized and restored repeatedly from another thread. This frame contains a textarea. I am running this application on Solaris9 (CDE) using XToolkit. When the robot maximizes and restores the frame repeatedly, the following exception is thrown:

Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException: 
sun.awt.X11.XTextAreaPeer cannot be cast to java.awt.peer.ContainerPeer
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:464)
at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:114)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:589)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:234)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

This is reproducible only on XToolkit since 1.5. Not reproducible on win32, Motif.

Execute the application on XToolkit. Just watch it. Do not move the mouse or do any operation. The robot will go and click on the maximize button repeatedly. After few seconds, you will notice the above exception on the console.
Comments
EVALUATION The exception is thrown in RepaintManager.paintDirtyRegion() method. This bug is reproducible (not always) in builds before 32. In build 32 the bug is fixed. Namely, see 4967886 (Swing should provide full double buffering per window). Before fix for bug 4967886 there was this code: if (rect.x == 0 && rect.y == 0 && rect.width == dirtyComponent.getWidth() && rect.height == dirtyComponent.getHeight()) { Container parent = dirtyComponent.getParent(); ComponentPeer parentPeer; if (parent != null && !parent.isLightweight() && (parentPeer = parent.getPeer()) != null) { // Cancel any pending paints on the heavy weight peer. // This avoid duplicate painting. *((ContainerPeer)parentPeer)*.cancelPendingPaint( dirtyComponent.getX(), dirtyComponent.getY(), rect.width, rect.height); } } And in the test case attached to bug 6201171 the possible dirtyComponent are: 1) sun.awt.X11.XTextAreaPeer$AWTTextPane 2) sun.awt.X11.XTextAreaPeer$AWTTextPane$XAWTScrollBar In the second case the parent of the peer is instanceof XTextAreaPeer, so the exception is thrown at the time of ((ContainerPeer)parentPeer). Anyway, after the integration of the fix for bug 4967886 (see diffs in attached files: 1.62-1.63-RepaintManager.diffs) the method paintDirtyRegion() was changed (there is no (ContainerPeer)parentPeer now). Seems it would be a good idea to close bug (not reproducible). ###@###.### 2005-05-31 12:49:28 GMT
31-05-2005