JDK-6848852 : PIT:test/javax/swing/JComponent/6683775/bug6683775.java on linux with RuntimeException.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6u18,7
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS:
    linux,linux_redhat_5.0,linux_ubuntu,os_x linux,linux_redhat_5.0,linux_ubuntu,os_x
  • CPU: generic,x86
  • Submitted: 2009-06-08
  • Updated: 2017-01-06
  • Resolved: 2014-03-12
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 8
8-poolResolved
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
Bug Info
=========
test/javax/swing/JComponent/6683775/bug6683775.java test fails and throws the following exception for pit b60.

java.lang.RuntimeException: Transparent frame is not transparent!
	at bug6683775.main(bug6683775.java:56)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:623)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
	at java.lang.Thread.run(Thread.java:717)

It works fine on other platforms like windows and solaris.

Steps to Reproduce:
====================
Set the following envrionment on linux and run the test.

1. Set JTREG PATH
2. Set JDK HOME
3. Set WORK DIR and REPORT DIR
4. Set the SUITE(ex: SUITE=/net/sqindia.india/export/disk01/vinay/src/jdk/test/javax/swing/JComponent/6683775/bug6683775.java)
5. Run the following command once set the above environment.

ksh ${JTREG_PATH}/bin/jtreg -v -jdk:${JDK_HOME} -r:${REPORT_DIR} -w:${WORK_DIR} ${SUITE}

JDK Info
=========
java version "1.7.0-internal"
Java(TM) SE Runtime Environment (build 1.7.0-internal-administrator_2009_06_01_0
1_18-b00)
Java HotSpot(TM) Client VM (build 16.0-b03, mixed mode, sharing)

Comments
Test fails in 7u65 b09 as well on Mac x64
29-04-2014

EVALUATION To make this tes work on Linux the panel added to the testFrame must be non double buffered: p.setDoubleBuffered(false); however the bug #6903034 prevent this test from fixing Note that this test works only if there is no toolbar on the top of the workspace, to make the test work in this case this line: BufferedImage capture = robot.createScreenCapture(new Rectangle(100, 100)); should be fixed to capture the rectangle with the backgroundFrame's bounds
19-11-2009

EVALUATION The fix for 6794764 removed the calls to the setDoubleBiffered(false) method from the Window.setLayeresOpaque() private method. Ealier the double buffering was turned off for the glass pane, the root pane, and the content pane when a frame went non-opaque. When double buffering was enabled, the painting was performed incorrectly, thus requiring to turn off the functionality. This, however, had mainly been tested on MS Windows platform due to some issues with the XToolkit implementation of non-opaque windows. Currently the toolkit-related issues are fixed. However, transparent windows on X11 work incorrectly. If one restores the calls to the setDoubleBuffered() method in the setLayeresOpaque() method, then the windows start displaying OK on X11. It looks like the fix for 6683775 does not fix the double-buffering issue completely. As to why this is only reproducible on X11: most probably because, contrary to WToolkit, the XToolkit.needUpdateWindow() returns false. This slightly changes the logic in the RepaintManager class (and, maybe, some other classes in Swing), thus making the painting a bit different. Since AWT does not explicitly depends on the double-buffered property of components, the painting artifacts are most likely caused by the Swing painting code. The bug is reassigned to Swing for further evaluation.
23-09-2009

EVALUATION It should be some differences in native platforms or in window manager settings, reassigned to the AWT pals
22-09-2009