Community
Participate
Working Groups
Build Identifier: 20110218-0911 FileDialog.open() is silently returning false without opening for our code under the recent 1.6 update 26. - true for our use of FileDialog.open(), - not true for Eclipse's use of FileDialog.open() - true on two Windows 7 Pro 64-bit machines - true for JDK 1.6 update 26, both x86 and x86-64 (32- and 64-bit) - not true for 1.6 update 25 on same machines - not true on XP running 1.6 update 26 We are thus far unable to isolate a small test case (20K-line application), but we're working on it. - Changing call parameters has no effect - Removing all listeners to the implicit Shell deactivation event has no effect This is a high priority for us since it happens with code that is deployed to customers. Do you have any tracing/debugging options for the SWT peer? Reproducible: Always Steps to Reproduce: 1. test case under development, but it might take days. 2. 3.
Created attachment 197994 [details] Screen grab of trace and variable context Screen grabs of debug stack trace and variable view. Goal would be for you to identify obvious corruption e.g., in display Shell. Sorry about the format.
I still don't have a small test case. I have noticed a point during plugin initialization where a plugin is loading/initializing a static field of java.awt.Color. If I comment that out, the bug goes away (i.e., the dialog appears). I did verify that no Color instance is created before attempting to load the dialog when there is a bug. As per Java (!), the static Color instance is initialized before the Color class initialization completes, when some native libraries are loaded. Nothing I do to the load library path seems to prevent or induce the bug. I do notice more dll's loaded where there is no bug, but nothing obviously related to AWT.
we confirm the bug. All of our customers who did the last jdk update to 1.6.0_26 under win7 professionanl and ultimate x86_64 bit versions, have the same problem. The FileDialog never opens and returns "null". We tested it with swt-3.6.1 and with the current devel version swt-3.7M7. You can reproduce the bug with the swt homepage's own samples app (started through jws) under http://www.eclipse.org/swt/jws/controlexample.jnlp after launching, go to the tab "Dialog" and try to create a FileDialog. The creation fails, and the dialog result is null (shown in the debug pane on the left). Creation of any other dialog, such as ColorChooser etc, works fine. Due to the deployed applications to the customers it is a high priority for us.
Created attachment 198180 [details] Screengrab of the samples app (controlexample) to reproduce the bug
It seems to me that 1.6.0_26 changed something the way AWT is initialized that broken file dialog. Did anyone report a bug against java for this ?
For a workaround, try to find and remove accesses to java.awt classes. We found that we access a static field of java.awt.Color early in plugin initialization, and avoiding java.awt.Color until later avoided the problem. Note that pre-initializing the Color class didn't work. Of note: - on first-use of java.awt.Color.BLACK, the instance initializer completes before the class static initializer completes ("normal" java) - when the ..Color class <clinit> is completing, it loads native libaries and calls initIDs() - it does not help to avoid the instance <init> ordering issue by running the class initializer first (e.g., java.awt.Color.class.toString()) - I did not see any difference in the order in which libraries were loaded from 1.6u25 to 1.6u26. I saw minor differences in the order of native calls. - I did see that "." on the java.library.path is displaced to the end under 1.6u26 - but forcing that under 1.6u25 had no effect - Though 1.6u26 is mainly security fixes, there is a change to URLUtil in deploy.jar that affects the handling of file: url's that might affect ClassLoader. - A bug has been submitted to Sun, but they have not posted it yet. (Many, many thanks to dshingiz@gmx.de for finding an accessible test case)
Is there some way to bump the priority from P3? This is a complete functionality failure. (I thought I submitted as P1 - sorry.)
Sun/Oracle bug was given a priority of 4: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7056092
(In reply to comment #7) > Is there some way to bump the priority from P3? This is a complete > functionality failure. (I thought I submitted as P1 - sorry.) Agreed. This is a complete functionality failure in our published application, and probably breaks all previous versions. Understood it appears to be Sun/Oracle responsibility. Workaround strongly needed and will be reported by us if found.
Interested parties note there are no votes as yet at the Oracle bug (see above).
Created attachment 198602 [details] This unit test reproduces this bug every time. I've created a unit test for this bug. It appears right after the JDK loads the awt native library.
FYI, JDK 7 b146 works fine.
Is there anything SWT could do to fix/workaround this problem ?
The only work around is to not use any class that loads awt.dll.
On a whim, I decided to see if using IFileOpenDialog (http://msdn.microsoft.com/en-us/library/bb775834(v=VS.85).aspx) would have any effect. It didn't.
This is also happening to my application under windows 7 pro and Java 1.6 update 26 Needs to be fixed quickly because my application is going into production in a few weeks. I have also noticed around the same time that all SWT ToolTips have stopped being displayed when your mouse cursor hovers over a widget that has tool tip defined on my application under the above versions. Has anyone else seen this or is it another bug completely different.
(In reply to comment #17) > I have also noticed around the same time that all SWT ToolTips have stopped > being displayed when your mouse cursor hovers over a widget that has tool tip > defined on my application under the above versions. Has anyone else seen this > or is it another bug completely different. Yes, I can reproduce that problem too. TabFolder is also broken: https://bugs.eclipse.org/bugs/show_bug.cgi?id=351372
Artem, do you know what changed in Java 1.6 update 26 that can be causing all these problems ? is the new java including a manifest file ? Initially I thought that java was loading a manifest file (similarly to bug 327476) and that was causing all the problems. I tried to remove the manifest file from SWT but that didn't fix anything.
(In reply to comment #19) > Artem, do you know what changed in Java 1.6 update 26 that can be causing all > these problems ? This is what Steve and I are currently looking to... Is it 6u26 or 6u25 regression?
(In reply to comment #20) > This is what Steve and I are currently looking to... Is it 6u26 or 6u25 > regression? Thank you for looking at this. as far as I can tell the problem only happens with 6u26 (I tested with x86). In an app SWT, once the code touches AWT, it can be as simple as this: java.awt.Color c = java.awt.Color.BLACK; Several problems start to happen: - FileDialog#open() returns null without showing the dialog - Control#setToolTipText() stops working - TabFolder uses classic look let me know if there is anything I can do to help.
Can everyone vote for the sun bug. I'm sure that it's something that they changed.
I'd like to thank everyone that voted for this bug. It's priority was elevated to very high and has been fixed in JDK 1.6 update 27.
closing as not eclipse
*** Bug 352801 has been marked as a duplicate of this bug. ***
BTW, we have found, that open/close dialog on win7 and java6u26 works when you disable visual effects for this app. (right mouse button on app icon / properties / compatibility / disable visual effects).
Glad to hear it only occurs in 1.6.0_26. I had the no tooltips problem too (bug 355541) when deploying an RCP app with Webstart. In my case the problem seems to only start when AWT's Toolkit.getDefaultToolkit() is called before the workbench is opened.
