Community
Participate
Working Groups
(This was formerly bug #53790.) It isn't possible to run Swing/AWT code from within an SWT-based application. The simple attached plug-in, which just provides a menu item that opens a Swing dialog, demonstrates the problem: it hangs trying to load libawt.jnilib from /System/Libraries/Frameworks/javaVM.framework/Version/1.4.2/Libraries. (The plug-in works under Windows, by the way.) Wee need to execute Swing & AWT components from within the Eclipse IDE in our Swing Designer GUI builder product (which works fine under Windows and Linux).
Created attachment 12194 [details] Plug-in defining an action that opens a Swing dialog This plug-in just adds a Sample Menu>Sample Action menu item (and corresponding tool bar button). To install, just unzip into the root Eclipse directory. The menu item should open a Swing dialog, but instead hangs. The file hung-stack.txt shows the stack trace.
Created attachment 12195 [details] Source project for attached plug-in This is a plug-in project named "Mac" from which the attached plug-in was created. It defines an action that opens a Swing dialog. To install, unzip the file into your workspace and import it. To reproduce the hanging, start up a run-time workbench that includes this plug-in, and in that workbench click on Sample Menu/Sample Action. A Swing dialog should open, but instead the thread hangs.
[Moving to platform/SWT]
This will not be implemented for 3.0.
Um, why was this changed to "enhancement"? This is hardly an enhancement. This is basic Eclipse functionality that does not work on the Mac (basic functionality, BTW, that was touted as a major feature of 3.0). The fact that this basic functionality does not work on the Mac (it works fine on Windows and Linux) completely prevents our plugin (and several others) from running on the Mac. At minimum, the severity should be "major" or "critical".
I agree - this is a critical issue. This is the kind of problem that Sun was so "worried" about with SWT... platform dependance.
Jay, feel free to chip in and help out. It's open source.
I've come across another issue with the SWT/AWT bug 67384 on Mac OS X: I am stuck trying to use two 3rd-party packages (Instantiations' Swing Designer, and now Univ. of Maryland's Piccolo package) because of the problem with Eclipse and running SWT/AWT within it on Mac OS X. The last comment here says to "chip in and help out". How can I go about doing that? I really love Eclipse, and I switched to the Mac thinking that I could continue my cross-platform development on the platform of my choice. BUT, with this error, I feel my hands are becoming tied. What is it that I need to be looking for? The Piccolo examples work from the command line, so the problem is not that SWT/AWT does not work on Mac, but that it does not work within Eclipse on Mac. When I stop the Thread to look at the problem, it is in stuck at the same spot as the original bug description: trying to load the library /System/Libraries/Frameworks/javaVM.framework/Version/1.4.2/Libraries/libawt.dylib. I'd be willing to help on this issue if someone could give me a hint on how to go about it!
More interesting facts: I was able to execute the Piccolo test examples ONLY after I deleted the swt.jar from the Classpath in Eclipse (3.0). The test example was NOT referencing any SWT classes, but by simply having that jar on the path, it hung loading the awt library. I even tested this by substituting the swt.jar that came with my platform version of Eclipse instead of the swt.jar file shipped with Piccolo, and the same hanging occurred. I also verified it with just creating the following test class: with swt.jar on the classpath, this hangs trying to load the awt library. public class TestFrame extends javax.swing.JFrame { public static void main(String[] args) { javax.swing.JFrame blank = new TestFrame(); blank.setSize(400,400); blank.show(); } } Outside of Eclipse, having swt.jar on the classpath does NOT hang it - it runs fine.
When you are running inside Eclipse, you are not using the "java" executable. You are using the "java_swt" executable, which is a modified version of the exec that changes the carbon UI thread. This is probably why you are experiencing the hang. See bug#40003 for a more complete explanation.
Bug 67384 = giving swing advocates a nice argument against SWT [btw: my personal interest to swing has increased due to this bug]. I've already detected 2 people, that are willing to assist. May i suggest that the component lead create a concrete status report and a processing-plan (e.g. a simple text document, e.g. in CVS), thus the interested parties can start to assist?
*** Bug 74288 has been marked as a duplicate of this bug. ***
Re comment #11: From the top of my head: - preliminary: MacOS X UI architecture relies on a single UI event loop in the main thread (thread 0) - we started SWT for Mac when AWT (1.3.1) was implemented in Carbon (like SWT) - SWT event loop could be run in any thread because behind the scenes the Carbon event calls talked to the "real" event loop still running in thread #0. - But it was impossible to run any Cocoa widgets. - SWT/AWT interoperability probably would have been easier at that time (same widget type, same event loop), but we never tried. - later AWT was reimplemented in Cocoa - Carbon (and SWT) event loop could no longer run in arbitrary thread but must be run in thread 0. - JVM would always start in thread #1, which would prevent any Java code from running in thread #0. - We wrote java_swt to start JVM in thread #0 and made it possible to run SWT event loop in UI thread. - Apple made Carbon and Cocoa interoperable and SWT could use Cocoa widgets (Fontdialog, Colordialog, Webkit). - later a JVM option was introduced to start JVM in thread #0 (made java_swt obsolete). - using this option prevents AWT from running from main because it now asserts that its is not running on thread #0. - running AWT in another thread hangs the JVM (probably because the AWT event thread deadlocks). It seems, that running AWT within an SWT applications will be tricky as long as both have to get their events from the same event thread. It would be much easier if multiple event threads were supported (as on the other platforms). Another idea would be to "virtualize" (multiplex) the Carbon calls we are using in the SWT event loop so that multiple loops in multiple threads would become possible. In a first step this would allow us to run the SWT event loop in any thread, and the "real" event loop (outside of the JVM) would always run in thread #0 (similar to what was possible in JVM 1.3.1). In a second step it might even become possible to support multiple SWT Displays with associated event loops (as already supported on the other platforms). However, we never tried this and we are unsure whether this is feasible at all.
I've read comment 13, and i've overflown the following article: "Thanks to its highly optimized but fully standard Java implementation, Mac OS X has garnered a reputation amongst developers as an excellent platform for developing and deploying Java applications. The most recent release of Eclipse, the well-respected open-source IDE, for Mac OS X only strengthens the case, as this flexible and highly extensible tool is a favorite of many Java developers." http://developer.apple.com/tools/eclipse.html - Some thoughts: - Apple (and it's community) should have a high interest on a running eclipse => support from apple should be expected => support from apple community should be expected - Examples for search phrases on news archives - "Enable support multiple event threads on Mac OS X UI" - "How to emulate multiple event threads on Mac OS X UI" - The phrases could be used to initialize discussion in relevant Mac forums. - Architectural limitation of Mac OS this (querying archives, groups, supports etc.) can basicly be done by any party interested to assist. - But! please realize: the cross-platform promise of eclipse is broken !!! This is very serious, thus this bug should get the P1 priority, the attention of the PMC and possibly the attention of the EMO. [please note: i've reviewed this case abstracly, without an extensive domain knowledge about SWT/MAC.]
Mike?
I'm not sure why I'm being ping'ed about this... Personally, I've never used an AWT/Swing based plug-in on any platform, so the "cross-platform promise" is certainly not broken for me. My primary Eclipse development machine is a PowerBook, and I have been very happy with Eclipse R3.0. I agree with the comment that ilias makes, however. For those who do care about this, they need to let the Apple Java development teams know that interoperability is extremely important to them. I am sure that the SWT team would love to fix the problem, but given its rather fundamental nature, I doubt much can be done without a significant commitment from Apple.
I added you because you are a Mac guy.
I would like to add a comment. We are developing a plugin that uses Java2D to do some image manipulation and rendering. Due to this bug (at least we belive so) the plugin cannot be used under MacOS X even in a headless mode. Eclipse hangs up somewhere in the java.awt.Color class (bug #41234, bug #54791). So while the use of Swing in a plugin may be questionable, considering the limitations of SWT's graphic context, the use of Java2D part of AWT is a legitimate use case.
This bug also affects all of the Eclipse Swing GUI builders that I am aware of including our Swing Designer and WindowBuilder products, the Jigloo SWT/Swing GUI Builder and (presumably) the Eclipse Visual Editor. In our case, we don't want to use AWT components in our plugin, but we do want to be able to programatically manipulate them and render them for design purposes.
Re comment #18: Last time I tried, headles AWT could coexist with SWT. Did you set the AWT headless system property?
Just to be clear, I believe that Peter and Erich are both making good arguments about the need for this. I was just claiming that *I* do not need AWT integration for my work. You need to understand though that the SWT team can make this any priority they want, but unless Apple commits real development effort to help solve the problem, it's probably not going to get fixed. There are too many other issues that the SWT team *can* make progress on for them to be spending man-years (literally) of effort trying to work around fundamental limitations in the platform. This is essentially the same issue that came up on Linux: Until JDK 1.5 provided features that made the interop possible, the SWT team could not offer the capability on Linux either. (Note: Even so, the problem was simpler on Linux. I'm not certain about this, but it's not obvious that the Mac version of 1.5 will help.)
Re comment #20: Eclipse is started using the following command line: eclipse -vmargs -Djava.awt.headless=true You can try testing this issue by installing the plugin in question and see where it hangs. (www dot jasperassistant dot com). There are no problems under linux and windows.
Apple are unlikely to address this in Java 1.5 as the problem is down deep in the operating system. In the case of Sun JDK 1.5, they threw away Motif and implemented AWT using X only (XAWT) to improve performance and fix bugs. Along the way they implemented the XEmbed protocol that is the standard way that one X application is embedded in another. SWT implemented the other side of the protocol and voila ... interop.
*** Bug 75041 has been marked as a duplicate of this bug. ***
Created attachment 14793 [details] Embeds a Java3D Canvas in a SWT frame using SWT_AWT Because of this bug Java3D combined with SWT is impossible on Mac OS X, which is a great loss. The Java3D replacements Xith3D/Jogl or Xith3D/LWJGL suffer similar problems at this moment, although SWT intergration is in development (so i'm told). In addition, for existing projects porting from Java3D to Xith3D may not be feasable. I've actually wrote this code to assist with bug 75041, but I'm posting it here in the hope that it is of any use. Running this application from eclipse results in the following exception being printed on the console: 2004-09-27 16:01:27.087 java_swt[9494] Apple AWT Java VM was loaded on first thread -- can't start AWT. Exception in thread "main" java.lang.InternalError: Can't start the AWT because Java was started on the first thread. Make sure StartOnFirstThread is not specified in your application's Info.plist or on the command line at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) at java.lang.System.loadLibrary(System.java:834) at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50) at java.security.AccessController.doPrivileged(Native Method) at java.awt.Toolkit.loadLibraries(Toolkit.java:1437) at java.awt.Toolkit.<clinit>(Toolkit.java:1458) at javax.media.j3d.MasterControl.loadLibraries(MasterControl.java:883) at javax.media.j3d.VirtualUniverse.<clinit>(VirtualUniverse.java:233) at SWTJava3D.<init>(SWTJava3D.java:35) at SWTJava3D.main(SWTJava3D.java:55)
It seems that Bug 75040 _depends_ on bug 67384. This is not a "duplicate" relation. Please verify, and reopen bug 75040 again (whilst setting the "dependency" relation). Dependency tracking is important to make the impact of a bug transparent.
sorry, meant Bug 75041 !
Just curious: Has someone filed a bug with Apple about this? Perhaps they're willing to share a thought or two about this could be accomplished...
We were moving an old legacy Swing application to Eclipse and noticed this issue, but it really didn't have anything to do with showing swing dialogs or anything. Some object happened to have stored a serialized version of java.awt.Color and Eclipse hung on OSX because when it was deserialized Color tried to load the native libraries. Its easily argueable that you shouldn't persist and pass objects like java.awt.Color, but I'm sure there are applications that do, so I think this is even bigger than the title gives it credit for: It can stop people from moving legacy applications from Swing/AWT to SWT (or at least make it harder to support OSX potentially loosing support for that platform).
Nope, the SWT/AWT interoperability problem occurs as soon as the native library is loaded, not just when a Swing dialog is opened. It has nothing to do with serials IDs. The problem is that the AWT thread deadlocks with the SWT thread. The only workaround is to run AWT in headless mode, which disables any kind of AWT event handling. As long as you are only using Colors or Image manipulation headless mode should be fine.
Created attachment 17355 [details] OSX crash log when headless=true Ok, we tried the headless=true trick, but this didn't solve anything, at least in our case. Now when awt classes were deserialized, java_swt crashes (see attachment). The only two awt classes in there are java.awt.Color and java.awt.Point.. This happens consistently. If headless=false, Eclipse hangs as reported by others.
> It seems, that running AWT within an SWT applications will be tricky as long as both have to get their > events from the same event thread. > It would be much easier if multiple event threads were supported (as on the other platforms). Unfortunately, that seems unlikely (and out of our control). If I understand correctly, the main problem is that both SWT and Apple's AWT implementation require their respective event loops to run on the UI thread (i.e. thread 0). If multiple event threads is eliminated as a practicle expectation, that leaves either SWT or Apple's AWT changing the way events are handled. I can see a possibility for SWT to "virtualize" an event loop (i.e. creating a loop that can run in any thread that then communicates with the real event loop in the UI thread). If this is possible (maybe using Carbon calls like GetMainEventQueue instead of GetCurrentEventQueue in org.eclipse.swt.widgets.Display.createDisplay(), etc), would it solve the problem? SWT wouldn't be using the UI thread event loop, directly, but would Apple's AWT (loaded from a plugin) be able to use the UI thread? Or would we still have the same problem when AWT was loaded? I know I don't currently have a clear grasp of the dynamics involved in the problem. I'm willing to learn about it and would like to help with a solution, though.
Yes, "virtualizing" the event loop seems to be one viable solution at first sight. The problem is that one motivation behind SWT was to *eliminate* AWT's event thread model in order to give full event control back to the application. So if SWT is in an event callback, it effectively stops the event loop and prevents that more events are read from the OS (the window server). This means that it is safe to assume that no new events arrive while processing an event. With a "virtualized" event loop all events would be read in the main thread and events would probably be sent into two queues, one for AWT one for SWT. The SWT event thread would read from one queue, AWT from the other. If the SWT thread blocks while processing an event, the main thread must be blocked too to preserve the SWT event processing semantics. In addition it must be blocked to ensure that the UI (Carbon) isn't accessed from two threads concurrently. Steve? Is this correct? Will this work? I don't know. Maybe somone should try...
We are also encoutering the same problem using Eclipse as a workbench for our BioInformatics framework (amaze.ulb.ac.be). We need to use external libraries that make an intensive use of AWT/Swing in their core so it's simply impossible to use it due to this bug. Of course, we tried the headless flag for AWT but it doesn't work as explained by some other people here. It may be important to indicate that, in such a growing sector as BioInformatics, many people are working with Mac OS and a lot of new developpements are made using Java technologies instead of Perl. Eclipse seems to be an excellent candidate to join together all these new tools by using its plugin management, but if the system hangs each time an external library uses some AWT/Swing, users and developpers may quickly switch to other solutions.
This bug also blocks rendering with Batik http://xml.apache.org/batik/ in an Eclipse plug-In. This includes the usage of ImageTranscoder. There is also no way to render into a BufferedImage. (Building an SVGDocument from an XML file works btw) Gerd
Sorry Andre, I've been away the last few weeks. It's OK for events to be dispatched from the user-interface to other threads while one user interface thread is blocked so virtualizing the event loop is a possibility. Since only one thread is allowed to be in the widget code, locking would be necessary. When Windows moved from 3.1 to 95, the single system event queue was virtualized in this manner. However, this type of code is low level and best supported by the operating system vendor.
I wonder wether the following hints from Apple's java-dev mailing list could help solving the problem? It looks like this person faced the same issues and found solutions for them: http://lists.apple.com/archives/java-dev/2004/Mar/msg00910.html
Thanks for the pointer, but it doesn't help. Apple's implementation of AWT is based on Cocoa which is already interoperable with Carbon.
(In reply to comment #38) > Thanks for the pointer, but it doesn't help. > Apple's implementation of AWT is based on Cocoa which is already interoperable with Carbon. Are you sure it doesn't apply? The mailing list poster mentions that Apple's AWT is Cocoa-based, and says calling NSApplicationLoad() is important *because* AWT is Cocoa-based: "2. We needed to call NSApplicationLoad() as loaded from the AppKit framework. This initializes Cocoa for the Carbon application and any related event handlers, etc. This is important since Java 1.4 AWT is Cocoa based."
AWT must run in another thread because the main thread is reserved for the Cocoa event thread (AppKit). AWT knows how to get events from the Cocoa main thread. SWT does not know how to get events from the Cocoa main thread. It uses the Carbon event mechanism directly. Therefore SWT must run on the main thread. This makes it impossible to have a Cocoa event loop running there too. One part of the problem is that MacOS X requires that there is only a single UI thread in any process and that this thread must be the main thread (thread #0). AWT can only coexist with SWT if it is running in headless mode. In this case no AWT event thread exists and no problems occur. However, the current implementation of AWT on MacOS X verifies that is in not running in the main thread even in headless mode. This check makes no sense. I've filed a radar bug against this.
Re: comment #40: I've verified that SWT and *headless* AWT are interoperable in MacOS X 10.4 (Tiger). That means that radar bug #3867646 has been fixed. I've requested that this fix needs to be applied to 10.3 (Panther) as well.
This bug is very unfortunate for many reasons indeed. My problem is that I am trying to run a SWT application from Java Web Start... a bad idea apparently on a Mac, since Jave Web Start is using AWT ... I could run java web start with all the parameters on the command line ( that way web start should not need the user AWT interface appart for displaying a progress bar for the download ).. but I get "Can't start the AWT because Java was started on the first thread" ( even with in headless mode ... which, I hope, is going to be fixed soon ). I don't know were this Java Web Start / SWT / OSX issue should be solved, but I don't really have much time for this since OSX is not our primary target platform. It would be really nice, though, if I could get our application to run seemlessly on my favorite OS ;-) ( It runs fine from eclipse ).
Our project needs to work with JOGL on the Mac. Because JOGL uses an AWT Canvas we are forced to use AWT even for the user interface. We just decided to drop SWT and use AWT instead. It's a pity.
I just noticed that Java 1.5 (aka "5.0") is now released for Mac OS X 10.4 (Tiger)...has anybody tried this and noticed any difference with these AWT/SWT issues?
Todd, does AWT headless mode work in JDK 1.5 on the Mac?
I am able now to generate JasperReports reports with OSX 10.4 (Mac Tiger), which was not possible with the previous version. This is true with the updated 1.4.2 version of java that ships with 10.4, as well as java 1.5. Previously, I'd get the "first thread" error. However, the version of SWT I am using simply throws an error that SWT_AWT is not supported when I try to actually use the SWT_AWT bridge; I have no idea if in theory it could work on 1.5 if the explicit check were removed, but I'm interested of course.
I've verified that AWT *headless* mode works on MacOS X 10.4.1 both under Java 1.4.2 as well as 1.5.0.
When I export an RCP application for MacOSX, and I specify in the .product VM arguments -Djava.awt.headless=true, I still have issues. My app does not crash (as it does if I leave the VM argument out), but I cannot seem to use the AWT classes. I have to add -Djava.awt.headless=true to the Info.plist file as well. What's the difference between the VM args in the Info.plist file and the config.ini file generated by Eclipse? (Also, Should this be in a different bug report?)
Yes, please create a new bug report for this (so that we don't spam too many people...) I'll try to explain the difference between config.ini and Info.plist there.
Is there a plan to fix this? Apple change? Swing/AWT change? SWT change? What would it take? The problem with SWT_AWT on the Mac keeps being used as a reason not to use SWT, for example, http://www.javalobby.org/java/forums/m91921485.html .
We are still waiting on Apple.
What's Apples metric for an important bug? Some years ago some apple engineer said it's the number of bug reports filed to their bug radar from independant developers for the same bug. Is this still the case? Do we all have to file a bug report to https://bugreport.apple.com/ ?
I have a problem! I can't work /w MyEclipse-UML on MacOSX like under WinXP and Linux... Please fix this bug.
Anyone know if the latest Java update from Apple affects this bug (1.3.1/1.4.2 Release 2)? http://developer.apple.com/releasenotes/Java/Java142RNTigerR2/index.html I noticed that it addresses one problem associated with headless applications accessing AWT (Radar #4097730), but it doesn't appear that this Java update addresses the fundamental issue.
No, the latest Java update does not affect this bug.
In addition to voting for this bug, I would like to register some thoughts and would appreciate an update on what is going on. It's fairly devastating not to be able to support the Mac platform because of this and causes extreme resentment and disappointment with whatever circumstances have prevented a fix for so long. We have customers in the financial services community demanding that we provide Mac support since many people are now getting them as laptops and especially as second computers at home. As an independent development shop with highly limited resources, we appreciated that we could support different platforms without additional resources, feeling that the investment in Java was starting to pay off as more platforms were starting to come into play. We are holding off the purchase of at least 20K worth of Apple hardware because of this and recommending to our customers in so far as our application is affected and a critical piece of their infrastructure not to purchase any Apple systems until this issue is resolved. If there is a specific person that can be contacted at Apple, I would greatly appreciate someone here providing at least their name and contact information if possible so that we can express the level of importance of this issue. Thanks! David Thomson david@suprasphere.com
Dave, The person at Apple you're looking for is on the cc list for this bug, so you've met your goal. Todd Brackett (tbrackett@apple.com). Todd owns the partner relationship from Apple to Eclipse. I can assure you that Todd understands the importance of this issue.
(In reply to comment #57) > Dave, The person at Apple you're looking for is on the cc list for this bug, so > you've met your goal. Todd Brackett (tbrackett@apple.com). Todd owns the partner > relationship from Apple to Eclipse. > > I can assure you that Todd understands the importance of this issue. I lead a software project at NYU School Of Medicine, and I find myself in a similar position to Dave's...presented with the opportunity to upgrade our hardware, I am sad to say that I am unable to specify Apple as our development environment. Fatal problems with the plugins we require preclude use of OS X. I sincerely hope that this problem is addressed soon. Eclipse appears to be the most popular Java IDE (as well as being my personal favorite) and I think that it is a problem of CRITICAL importance that Apple can't run this software properly while Windows and Linux can. Also please note that this discussion started in the middle of 2004, and we're still discussing it.
I'd like to voice my agreement with some things that have come up in a few recent posts. Our firm is also having to make concrete business decisions as to whether we can offer a Mac version, and this bug is the only real obstacle. To plan ahead, it would be nice to know if there is a plan in place to resolve this issue, if anyone is actively working on it (at Apple, Eclipse, or otherwise), and some idea of the progress. Because based on the limited information available in comments to this bug report, no business can rationally commit serious money towards an SWT_AWT-dependent Mac version. Interestingly, in the specific industry I'm in, there is no Mac-based product. From what I understand, even Apple itself is forced to buy and use Windows to have such a system. So until this issue is resolved, it is a lose-lose-lose situation. Apple is losing hardware sales, businesses are losing software sales, and Eclipse/SWT can only really use the term "cross-platform" with a big asterisk.
Is there any way we could get a status report on this bug and what is being done and what the community can do to get this bug resolved? I have a client who is wanting to do a lot of things that this bug is inhibiting (embedding some swing forms, using java web start on OSX with SWT apps, etc) and I'm having a really hard time explaining why these things don't work, especially when they go to the eclipse site and see that OSX is a supported platform. I'm sure this is true for quite a few others. I know you guys may be swamped at the moment, but any update on the situation would help. Thanks.
Java web start on OSX should work with SWT apps ! Maybe there is a workaround, like running java web start in headless mode ... but I never managed to get that running. This is just another posting with the hope somebody will look into this problem :-(
The issue for me is the inability to use the UML perspective provided by the MyEclipse plug in as a result of this bug. As Macintosh is my primary platform I am forced to go without full functionality in my IDE. I would have to have to acquire a Windows based workstation just to get around this bug.
J2SE 5.0 release 3 DP4 mentions: (4295773) new SWT / AWT headless mode fix Has anyone tested to see if this solves their problems? Is there a simple test case one could use?
I installed release 3 DP4 and I'm now able to use the SVG exporting feature of EclipseUML which (from what I know) was broken because of the missing headless mode (it uses Batik for exporting). So from my point of view this seems to be fixed.
Time to speak up, folks - is there anyone left for whom the latest JDK 5 developer preview *doesn't* solve this problem?
Does anyone have more info about the "(4295773) new SWT / AWT headless mode fix"? I have been running AWT headless for a long time on OS X -- so I'm confused about what was fixed. I was under the impression that the resoltuion for this bug would involve being able to run SWT_AWT *without* headless=true. I will download J2SE 5.0, but can some one clasrify what I am to test?
Dan, I think you are right. This bug is the one which inhibits the use of SWT_AWT objects on Mac OSX. So, in order to test if the issue is fixed, you should be able to run this snippet without having additional properies set: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet135.java?rev=HEAD&content-type=text/vnd.viewcvs-markup You should also be able to launch SWT applications with Apple's web start client. I've actually set up an SWT application to launch with a different web start client. It is a little tricky, but it will allow you to deploy and update an SWT application on OSX using the JNLP protocol. I'm going to write up an article about it in the next week or so as I have time, but if you would like information on it before then, just e-mail me.
It is my feeling that it will not be finished until it runs *without* headless=true being set. In addition, I am thinking about filing a new bug to move the SWT_AWT class back into the win32.*, gtk.* hierarchies until this is fixed and to make it front and center in the API documentation in the meantime. There is little documentation that this will break OSX support, as it's not mentioned in the API or in many (if any) of the examples. I think that should be a standard process, where if something completely breaks OSX (or other platform) support, it should remain in a platform specific part of the API until it works on at least the major three (OSX, Linux, Windows). Thoughts?
I think that, other than helping us vent our anger at not having SWT_AWT on the Mac, moving it into N platform specific packages would be counter-productive on almost every possible level. However, I *do* believe that the javadoc for the class should clearly identify what its limitations are.
(In reply to comment #65) > Time to speak up, folks - is there anyone left for whom the latest JDK 5 developer preview > *doesn't* solve this problem? I just tried it with the hope I could run a Swing application with SWT library in the libraries list of the current project, but it didn't work (of course, it works without SWT library) : no frame at screen, even worse, no message on the console as there used to be before this new release. I know it's a quite strange situation, but I want to make tests of SWT and Swing libraries in the same project, and there's no reason I should be obliged to create two different projects for this. On the other hand, VE seems to work better now... :-)
I spoke a little too fast about Visual Editor under Mac OS X. I tried it again ant it doesn't work correctly : - No window appears in the preview screen - In the JavaBeans view, no contentPane appears in a JFrame tree, and thus you can't add any component to the frame
(In reply to comment #65) The problem is not fixed for me; I have an application that uses jfreechart as a swing component. I get a plain "not implemented" exception. This happens in both Eclipse 3.2M3 and 3.1.1 on JDK 1.5.0_05, ppc Mac OS X. !ENTRY org.eclipse.ui 4 0 2005-11-14 09:38:29.888 !MESSAGE Not implemented !STACK 0 org.eclipse.swt.SWTError: Not implemented at org.eclipse.swt.SWT.error(SWT.java:2968) at org.eclipse.swt.SWT.error(SWT.java:2865) at org.eclipse.swt.SWT.error(SWT.java:2836) at org.eclipse.swt.awt.SWT_AWT.new_Frame(SWT_AWT.java:63) at com.trifork.p4.history.views.Graph.createPartControl(Graph.java:36) at org.eclipse.ui.internal.ViewReference.createPartHelper(ViewReference.java:305) at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:180) at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:552) at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:283) at org.eclipse.ui.internal.ViewPane.setVisible(ViewPane.java:512) at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:126) at org.eclipse.ui.internal.presentations.util.PresentablePartFolder.select(PresentablePartFolder.java: 268) at org.eclipse.ui.internal.presentations.util.LeftToRightTabOrder.select(LeftToRightTabOrder.java: 65) at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation.selectPart (TabbedStackPresentation.java:391) at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1102) at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1051) at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1256) at org.eclipse.ui.internal.PartStack.createControl(PartStack.java:576) at org.eclipse.ui.internal.PartStack.createControl(PartStack.java:528) at org.eclipse.ui.internal.PartSashContainer.createControl(PartSashContainer.java:485) at org.eclipse.ui.internal.PerspectiveHelper.activate(PerspectiveHelper.java:230) at org.eclipse.ui.internal.Perspective.onActivate(Perspective.java:813) at org.eclipse.ui.internal.WorkbenchPage.setPerspective(WorkbenchPage.java:2979) at org.eclipse.ui.internal.WorkbenchPage.busySetPerspective(WorkbenchPage.java:909) at org.eclipse.ui.internal.WorkbenchPage.access$11(WorkbenchPage.java:894) at org.eclipse.ui.internal.WorkbenchPage$12.run(WorkbenchPage.java:3102) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69) at org.eclipse.ui.internal.WorkbenchPage.setPerspective(WorkbenchPage.java:3100) at org.eclipse.ui.internal.ChangeToPerspectiveMenu.run(ChangeToPerspectiveMenu.java:91) at org.eclipse.ui.actions.PerspectiveMenu.run(PerspectiveMenu.java:331) at org.eclipse.ui.actions.PerspectiveMenu.runOther(PerspectiveMenu.java:346) at org.eclipse.ui.actions.PerspectiveMenu$3.runWithEvent(PerspectiveMenu.java:108) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection (ActionContributionItem.java:538) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:488) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java: 400) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1380) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1404) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1389) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1237) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3060) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2712) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1699) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1663) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:367) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:143) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:103) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:226) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:376) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:163) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:334) at org.eclipse.core.launcher.Main.basicRun(Main.java:278) at org.eclipse.core.launcher.Main.run(Main.java:973) at org.eclipse.core.launcher.Main.main(Main.java:948)
I get the same error when trying to use my metrics plugin (http://metrics.sourceforge.net), which attempts to embed a touchgraph panel to visualize dependencies. (In reply to comment #72) > (In reply to comment #65) The problem is not fixed for me; I have an application that uses jfreechart as > a swing component. > I get a plain "not implemented" exception. This happens in both Eclipse 3.2M3 and 3.1.1 on JDK > 1.5.0_05, ppc Mac OS X.
In the release notes of the recent Java 5.0 Release 3, I found an interesting item about SWT: http://developer.apple.com/releasenotes/Java/Java50Release3RN/ I've verified that java.awt.headless is indeed no longer necessary when using non-event based classes from AWT like BufferedImage. In addition it seems that interoperability between SWT and *HEADLESS* AWT has been improved too. I no longer see threading related console messages when terminating applications that use both SWT and *HEADLESS* AWT. This is good news, however it does *not* solve the original problem described in this bug.
I've read that in the new release 1.5.0 R3 it is possible to implement non SWT components. Is it now possible to implement Swing-Frames in a SWT composite or not? The class SWT_AWT has no implementation for embedding a awt/swing frame in SWT, isn't it? Is there an update of the eclipse-swt api for doing it or is it still an open bug?
*** Bug 122988 has been marked as a duplicate of this bug. ***
Is Apple really aware about this bug ? There's no mention about SWT in any recent release of Developer Previews of JDK 1.5 ! :(
(In reply to comment #77) > Is Apple really aware about this bug ? > There's no mention about SWT in any recent release of Developer Previews of JDK > 1.5 ! :( > They are aware of the issue, but have been frustratingly quiet about the whole topic. I had sent an enquiring e-mail about this bug to Todd Brackett @ Apple whose email was listed below (comment #57) to see if i could get any info. I got a reply back from someone at Apple saying Todd had recently left Apple (this was back in early Dec/05) and someone named Michael McMillion from the IT partners team was filling in and getting up to speed. I was told he was cc'd on my enquiry... and also the Java team would be asked about the issue and be getting back to me... but i haven't heard boo.... I'd rather not post their e-mail addresses directly to bug reply, but if anyone is interested in picking up the torch and start hounding them for some concrete answers (any answers positive or negative would be helpful !), i'd forward you the contacts i have. I've given up and am content with sacrificing some of the features i was planning which were using some advanced Swing based graph layout engines.
I had a similar experience interacting with Apple. I know that the Eclipse Foundation is trying to do the right thing, but if this is important enough of an issue, I think Eclipse should either hold back all new releases on OS X until this is at least *acknowledged* or remove SWT_AWT from the core Eclipse API. That may not be the "open source way", but Apple is not really an open source company and they are using their market share and clout to impose frustration on developers and users. This smells like a lot of politics are driving this (although it does seem like it is a very complex technical issue as well). Apple probably has its own agenda with X Code and not really wanting people to be using Eclipse in the first place. It could have something to do with Sun and their relationship with Apple. From what I understand, Sun is already upset that Apple is using Quicktime in their licensed JRE instead of the Java Media API's, or something like that. The transition to Intel and the "universal binary" might also be complicating things on their end. So unfortunately I think Apple will only respond to something more drastic than a bunch of developers complaining on an Eclipse bug list, which I don't think they even follow any more since Todd Brackett removed his name from the list a while back. Apple is showing that they want to play hard ball or at least have many more things going on that they perceive to be a much higher priority, so I think they need to realize first-hand just how important Java in general has been to their renaissance as a development platform. To the extent that Eclipse and SWT are important as well (rather than Swing specifically), I don't know, but it seems as if Apple does and is saying "buzz off" to SWT and Eclipse in general. Perhaps the final decision hinges around ascertaining the extent that SWT_AWT even matters to the success of either Eclipse as a development platform or SWT as an independent GUI/application API. From what I understand, the SWT part has always been seen as a "bonus", and what it shows is that there could never be a SWT_AWT piece embedded inside the Eclipse development platform itself. If there is no chance that it will be cross platform in the near to mid term, I think it should be removed as an API. It will just create way too many headaches long term for people who perhaps wouldn't have the awareness of the consequences of using it on the cross-platform compatibility of their application.
For the record, I could not disagree more with David Thompson's suggestion to remove OS X from the core. This paticular bug - swt_awt - is aggravating for sure. But there are many, many applications that work just fine, thank you, without the need for this bug to be fixed. I know ours does, and we depend nearly exclusively on the cross-platform nature that Java/SWT gives us for a strategic advantage over other products. There are other substantial applications being built on Eclipse that don't need this bug fixed and that will be targeted at Mac owners, e.g. "Flex," Macromedia's new Eclipse-based Flash IDE. And there are too many people who really *want* Eclipse / OSX to work as well as it can within whatever constraints it has, and removing it from the supported list disrespects their past, and ongoing efforts. Such a move would also be difficult strategically for Eclipse, which has used cross-platformness as a key plank in the platform for Eclipse goodness. I agree that this may be influenced by politics. But I suspect it's less about that than simply that Eclipse isn't yet "important" enough on Apple's radar screen of things they want/need to do. Maybe what we can do is not rely *only* on going through Apple engineers, but go to the Apple Developer Program, and see if we can find one of those evangelist-type people who can get this on Apple's radar screen. I'm short time right now, but I'll put this on my list of things to do, and see if I can help get some movement using this route.
(In reply to comment #80) > this bug fixed and that will be targeted at Mac owners, e.g. "Flex," > Macromedia's new Eclipse-based Flash IDE. not true, we do want this fixed for Flex Builder. We did manage to get this working properly under Tiger only with headless mode but we're not sure if Tiger can be the minimum system we support. I have already pushed for it with Apple several times...don't worry, when the time comes we can now throw Adobe's wieght behind this. Note I haven't been following this for a while now and am not sure of the status if anything has changed since a few months ago.
George -- Thanks for contributing. I stand corrected re: needing it fixed for Flex (though I still stand on my assertion that OS X needs to remain fully committed/supported). And I think getting Adobe's full weight behind getting this fixed is *exactly* the kind of thing that would help! I'd be happy to coordinate my contact with Apple Developer Programs to coincide at the same time as yours; if everybody did the same thing, maybe we'd get the right attention. I'll bet if you post something to this bug report when you get ready to contact Apple, *and* if Adobe can help us find the right person to push on, we'll all jump on board. Let us know.
"...not sure if Tiger can be the minimum system we support" Wow, it's spooky when other developers have EXACTLY the same thoughts as you! I have spent 10 months developing a quite complicated SWT application (see http://markmclaren.com/desktop.html), and am seriously considering re-writing it in Swing because of this bug. I have been a Java GUI programmer for 4 years and in my opinion this is by far the biggest impediment to SWT adoption. With this bug fixed, most of the arguments against SWT (and the Eclipse platform) disappear.
I don't know how extensivly the vote feature within bugzilla is used but I guess the current vote status shows dramatically, how important this feature is. This bug has the most votes of ALL bugs filed for Eclipse with 137 voters, the only other bug with more than 100 votes is the request for a tiled text editor (which I think is a great idea ;-). I know that the issues has to be fixed on Apples side but perhaps some or at least one person at Apple is monitoring this issue. I really hope that this is not a political issue and can be resolved within the next months.
As an effort to get this issue solved, we (the community) can work on raising the profile of this bug, by talking about it in public domain by blogging about it. In addition to this I think we should also identify someone in the Eclipse foundation as the 'point guy' for working our side of the issue (think of us as a special interest group :), I'm not too sure who that person is.. maybe Bjorn Freeman-Benson who is the Director of Open Source Process? Our objectives should be to lobby Apple for a detailed response on the state of this issue along with a commitment to a timeline for solving it. Right now we have nothing, no timeline, no commitment of resources, little to no communication relating to the progress of this issue (from either side). At this rate it may never be fixed, personally I’d like to know either way, so I can make an educated decision, is the Eclipse platform is the right choice for my company?
In comments 13, 33 and a few others, the idea of event loop virtualization is mentioned. It seems to me that even *if* Apple decides to work on the problem in the near future, a solution could still be a long way off. So, since there is little that any of us can do about what Apple will make a priority, I would like to see a more technical discussion of the issues surrounding "virtualization". Personally, I don't know where to begin, but if a few knowledgable people who might not otherwise have the time can point the rest of us in the right direction, we might be able to investigate it further.
At Indiana University, we are working on a large-scale scientific collaboration tool which lets scientists share unmodified research-grade code with zero-programming effort by converting them to RCP plugins using appropriately simplified templates. This is funded by the National Science Foundation and everyone has high expectations from it. We created a framework on top of RCP that lets people do this irrespective of the source programming language, persistence strategy or data model and even share visualization code written using Swing. Obviously we have run into this roadblock with SWT/AWT bridge on Mac OS X. I love RCP and wouldn't want to use something else but this bug is really much more important than people seem to realize and if something isn't done quickly, we'll be forced to recommend to the team that they find a different solution (and I really don't want to do that because it will erase the confidence people have in Eclipse technology almost instantly). Recently we went to a large conference involving leading scientists and cyberinfrastructure architects and I got really tired and frustrated from repeatedly explaining to people that this thing is written in Java but doesn't work on the Mac (and academia has a LOT of Mac users). Many scientists know that Java is cross-platform and telling them that RCP with SWT/AWT won't work on the Mac gives them the impression that "this Eclipse thing" is some hacked-up solution not yet ready for prime-time. Is this something the Eclipse team is willing to put up with? Finding a solution is important, but showing people that there is real commitment towards solving the problem is far more important. I don't know what we can do to help out, but if there's anything we can do, for example building support for resolving this issue or writing a letter to Apple, please broadcast your ideas (make it loud and noisy) so everyone can hear it. Thanks! Shashikant Penumarthy Tech Lead, InfoVis Lab, Indiana University
One of the best ways to "lobby" Apple to resolve a particular defect is to submit the defect to their bug reporting system. If those interesteed in seeing this defect resolved have an ADC account, file a defect in RADAR. If you don't have an ADC account, you can sign up for one for free. Since RADAR defects are only visible to Apple employees and the non-Apple person who filed the defect in RADAR, we could post our submitted RADAR #s here as well, so that whoever served as a "front person" for this artifact could have a list of the submitted defects.
Submitted RADAR bug #4426227 to bugreport.apple.com
Submitted RADAR bug #4426256 to bugreport.apple.com
I was a little skeptical about submitting a duplicate bug on the Apple site, but then I remembered this comment: "Comment #52 From Gerd Castan What's Apples metric for an important bug? Some years ago some apple engineer said it's the number of bug reports filed to their bug radar from independant developers for the same bug. Is this still the case? Do we all have to file a bug report to https://bugreport.apple.com/ ?" I also did some googling and it does seem the general consensus is that apple uses duplicates as a measure of importance. So with that said: Submitted RADAR bug #4426262 to bugreport.apple.com
Submitted RADAR bug #4426273 to bugreport.apple.com
Submitted RADAR bug #4426276 to bugreport.apple.com
Submitted RADAR bug #4426275 to bugreport.apple.com
Um, er... Maybe it would help to get a higher hit-rate if we coordinate our Radar postings to say as close to the same thing as possbile. (Maybe not, but I thought I'd bring up the possibility.) I've filed my Radar bug (#4426286) using the following information: - Component: Mac OS X (vs. Java, since this is really an underlying windowing system problem, not a Java problem???) - Severity: Serious bug - Reproduceable: always - Version/build: 10.4.4 (8G32) - Problem title: It isn't possible to run Swing/AWT code from an SWT-based application. - Description: Summary: Swing/AWT cannot be used within a SWT-based application because both SWT and AWT applications must get their events from the same thread. Support for multiple UI event threads should be provided. Steps to reproduce: See Eclipse bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=67384 Expected results: See above summary Actual Results: See above summary Regression: N/A Notes: See https://bugs.eclipse.org/bugs/show_bug.cgi?id=67384 for long discussion of the issue, an indication of the (very large) number of developers who are limited by this issue, and concise descriptions of possible solutions
Does anyone know of any other non-swt based applications that are not working on OSX because of this issue? Won't Apple be more likely to call this an SWT problem if it is the only example of an issue related to the single event loop? As suggested in comment #95, this problem is not necessarily limited to Java (right?), so shouldn't there be a few other apps out there that have run into the same issue? If not, I'm afraid a decision by Apple to not get involved in this issue might be viewed as reasonable by anyone outside of the Eclipse community.
Submitted RADAR bug #4426345 to bugreport.apple.com
Submitted RADAR bug #4426458 to bugreport.apple.com
Submitted RADAR bug #4426581 to bugreport.apple.com
Submitted RADAR bug #4426792 to bugreport.apple.com
Submitted RADAR bug #4427273 to bugreport.apple.com
Submitted RADAR bug #4427685 to bugreport.apple.com
Submitted RADAR bug #4427696 to bugreport.apple.com
Submitted RADAR bug #4427709 to bugreport.apple.com
Submitted RADAR bug #4427710 to bugreport.apple.com
Submitted RADAR bug #4428158 to bugreport.apple.com I have also been lobbying some of my buddies working at Aplle :-)
I just received an email from the Apple Bug Reporting team saying: "This is a follow up to Bug ID# 4426227. After further investigation it has been determined that this is a known issue, which is currently being investigated by engineering. This issue has been filed in our bug database under the original Bug ID# 3905894." So RADAR Bug ID # 3905894 is the original one, for future reference.
Can the SWT team please tell us if they are actively working on the "event loop virtualization" solution mentioned earlier? If not, is it because they determined it cannot work or because they have higher priority issues? From Apple's point of view, this is an enhancement, not a bug, and aren't showing much interest in "fixing" it. Even if they do, I expect that it will not work on older OSX versions.
We are not working on this bug right now. To fix this would require about 6 man months and detailed knowledge of the internals of all of the software in question. Since the SWT team is small, we just don't have the resources to look at this right now. To give you some idea of the work that needs to happen, consider a similar feature that was added to Windows 95. Windows 3.11 had a single system event queue. When Windows 95 came out, Microsoft implemented an event queue per thread. Can you imagine someone other than Microsoft trying to implement this?
First, I want to make it clear: the lack of progress on this bug has nothing to do with politics, or our 'agenda' with Xcode. Eclipse and Xcode don't compete. Eclipse is a great Java IDE for writing platform portable Java applications. Xcode is designed to enable developers to get the most out of Mac OS X. Many of us on the Java team use Eclipse on a regular basis. The SWT team made a decision to use the Carbon framework. This was a good decision as the event model in Carbon is similar to the event model in SWT. In a separate decision, the Apple team chose to use the Cocoa framework for the AWT implementation in order to make Apple's newest user interface features available to Java developers. Here's the problem in a nutshell. Both toolkits need an event dispatcher running on the main thread. In the SWT, the standard SWT paradigm of fetching and processing events does that work -- it uses Carbon to grab events and hand them off to each window for processing, and then waits for that event to be processed. In Apple's AWT, an instance of NSApplication runs on the main thread, and delivers user events to AWT windows, which are turned into AWT events and posted to the AWT event thread. In both frameworks, all code that interacts directly with the underlying framework must execute on the main thread. When your application creates or manipulates an AWT window Apple's implementation does that by calling performOnMainThread and waiting for the result. If the SWT is running and dispatching events, this can't work because the SWT is blocking the main thread waiting for the event to be processed. Deadlock ensues. We have looked at this any number of ways, and there is no simple fix. Steve's time estimate above is probably correct, but right now, we don't even see a complex fix, so one estimate is as good as another. What we can do right now is explain the problem, and let you know that we're considering all possible solutions. Please send us your ideas.
So as I understand it, the SWT team has not found a simple way to fix this in SWT alone, and the Apple team has not found a simple way to fix this in Apples code alone. In my perception, there is the extreme solution left: talk to each other (teams and code. Especially teams). Is there a simple way for SWT to detect early that it is not responsible for an event and feed it back to Apple's code? It's not a clean architecture, but hey, if it works?
I'd like to suggest a simple fix to this bug. I tried it with Eclipse 3.1.0 and Java 1.4.2 and it seems to work fine. The fix goes like this: 1. Don't use -XstartOnFirstThread option. Let AWT load and start dispatch on thread #0. 2. Run SWT dispatch loop and the rest of Eclipse code inside a Carbon event handler: SWT dispatch will act as nested (second) dispatch loop on same thread #0. One way to do it is to change org.eclipse.ui.internal.ide.IDEApplication.run() method to look like this: public Object run(final Object args) throws Exception { final Object result[] = new Object[2]; final int RUNAPP_CLASS = 334; final int RUNAPP_KIND = 153; final int[] outRef = new int[1]; final Callback[] callback = new Callback[1]; Object handler = new CallbackInterface() { public int runProc(int nextHandler, int theEvent, int userData) { try { OS.RemoveEventHandler(outRef[0]); callback[0].dispose(); Display display = createDisplay(); ... original code of run() ... result[0] = returnCode; } catch (Exception x) { result[1] = x; } synchronized (this) { notify(); } return 0; } }; callback[0] = new Callback(handler, "runProc", 3); int callback_proc = callback[0].getAddress(); if (callback_proc == 0) throw new Exception("No more callbacks"); int[] mask = new int[] { RUNAPP_CLASS, RUNAPP_KIND }; int target = OS.GetEventDispatcherTarget(); OS.InstallEventHandler(target, callback_proc, mask.length / 2, mask, 0, outRef); // Load AWT and let it to start Carbon dispatch loop Class.forName("com.awt.Toolkit"); synchronized (handler) { int [] event = new int [1]; int queue = OS.GetMainEventQueue(); OS.CreateEvent(0, RUNAPP_CLASS, RUNAPP_KIND, 0.0, OS.kEventAttributeUserEvent, event); OS.PostEventToQueue(queue, event[0], (short)OS.kEventPriorityStandard); OS.ReleaseEvent(event[0]); handler.wait(); } if (result[1] != null) throw (Exception)result[1]; return result[0]; } public interface CallbackInterface { public int runProc(int nextHandler, int theEvent, int userData); }
Another, even simpler, fix for this bug. But this one needs to be done by Apple. Just remove "Apple AWT Java VM was loaded on first thread -- can't start AWT" check from the code. Let it continue without starting dispatch loop. SWT will run dispatch loop and it will dispatch ALL events, including those targeted to AWT. Everything should work just fine. BTW, type in prev comment: Class.forName("com.awt.Toolkit"); should be Class.forName("java.awt.Toolkit");
The suggestion in comment #113 was implemented in Java 5.0 Update 4. If the VM is started on the first thread, the AWT goes into 'compatibility mode', in that we don't start up an NSApplication, nor do we enter AWT headless mode. This may or may not solve the problems. The AWT performs many internal checks to ensure it's not on the main thread when executing many operations, and you may see some asserts firing, but they won't kill the application. The comment in #112 looks interesting, but I don't know if you want that code at the IDE level. I think it's worth investigating, though.
It can't be this simple ... if it is ... I don't know what I'll do ... but I'll take suggestions .... from everyone on the list. SSQ and SN to investigate the proposed solution right away.
After looking at it a bit more, I think the snippet in #112 has a _lot_ of promise. Karl Hsu and I were talking about doing exactly what this change does just this last week. We were concerned that we might get a deadlock here, because the AWT will push any Cocoa call onto thread 0 and wait for the result, but NSThread's performSelectorOnMainThread will immediately dispatch the call if we're on the main thread. Some asserts will be fired, but the AWT will not abort the app.
We're on it ... stand by ...
Here is a snippet that explores Eugene's idea (comment #112) without the Eclipse complexity. It is just a main that opens an AWT Frame and a SWT Shell. Unfortunately, it does not seem to work. The AWT Frame comes up, but it does not respond to any event when running JDK build 1.4.2_09-232. And If I run it with JDK build 1.5.0_05-83, the RUNAPP event does not get dispatched, so nothing comes up. Scott, is this the deadlock you mentioned it could happen? public static void main(String[] args) throws Exception { System.out.println("Starting.."); final int RUNAPP_CLASS = 334; final int RUNAPP_KIND = 153; final int[] outRef = new int[1]; final Callback[] callback = new Callback[1]; Object handler = new Object() { public int runProc(int nextHandler, int theEvent, int userData) { try { System.out.println("handler running"); int eventClass = OS.GetEventClass (theEvent); int eventKind = OS.GetEventKind (theEvent); if (eventClass != RUNAPP_CLASS || eventKind != RUNAPP_KIND) return OS.eventNotHandledErr; OS.RemoveEventHandler(outRef[0]); callback[0].dispose(); /* SWT */ System.out.println("SWT running"); Display display = new Display(); Shell shell = new Shell(display); shell.setText("SWT Shell"); shell.setLayout(new RowLayout()); org.eclipse.swt.widgets.Button b1 = new org.eclipse.swt.widgets.Button(shell, SWT.PUSH); b1.setText("Button1"); org.eclipse.swt.widgets.Button b2 = new org.eclipse.swt.widgets.Button(shell, SWT.PUSH); b2.setText("Button2"); shell.pack(); /* AWT */ Thread thread = new Thread () { public void run() { System.out.println("AWT running = " + Thread.currentThread()); Frame frame = new Frame("AWT Frame"); java.awt.Button button1 = new java.awt.Button("Button1"); java.awt.Button button2 = new java.awt.Button("Button2"); frame.add("East", button1); frame.add("West", button2); frame.pack(); frame.setVisible(true); } }; boolean sameThread = false; if (sameThread) { thread.run(); } else { thread.start(); } shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } catch (Exception x) { x.printStackTrace(); } synchronized (this) { notify(); } return 0; } }; callback[0] = new Callback(handler, "runProc", 3); int callback_proc = callback[0].getAddress(); if (callback_proc == 0) throw new Exception("No more callbacks"); int[] mask = new int[] { RUNAPP_CLASS, RUNAPP_KIND }; int target = OS.GetEventDispatcherTarget(); OS.InstallEventHandler(target, callback_proc, mask.length / 2, mask, 0, outRef); // Load AWT and let it to start Carbon dispatch loop Class.forName("java.awt.Toolkit"); synchronized (handler) { int[] event = new int[1]; int queue = OS.GetMainEventQueue(); OS.CreateEvent(0, RUNAPP_CLASS, RUNAPP_KIND, 0.0, OS.kEventAttributeUserEvent, event); System.out.println("post event=" + OS.PostEventToQueue(queue, event[0], (short) OS.kEventPriorityStandard)); OS.ReleaseEvent(event[0]); handler.wait(); } }
We also tried the idea from comment#114 with the snippet below. It did not work either. Depending on the flag "sameThread", we get two different problems. If "false", ssq% /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Commands/java -XstartOnFirstThread -cp org.eclipse.swt/bin:Steve/bin -Dja.library.path=org.eclipse.swt.carbon.macosx.ppc/ interop.AWTandSWT AWT running = Thread[Thread-0,5,main] Exception in thread "Thread-0" java.lang.StackOverflowError at org.eclipse.swt.internal.carbon.OS.ReceiveNextEvent(Native Method) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2861) at interop.AWTandSWT.main(AWTandSWT.java:67) And if "true", ssq% /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Commands/java -XstartOnFirstThread -cp org.eclipse.swt/bin:Steve/bin -Dja.library.path=org.eclipse.swt.carbon.macosx.ppc/ interop.AWTandSWT AWT running = Thread[main,5,main] CWindow's _nativeShowFocusable:modal: encountered error : 2006-02-06 12:50:15.567 java[1110] Error (1002) creating CGSWindow In both cases, the AWT Frame does not come up. public static void main (String [] args) { /* AWT */ Thread thread = new Thread () { public void run() { System.out.println("AWT running = " + Thread.currentThread()); Frame frame = new Frame("AWT Frame"); java.awt.Button button1 = new java.awt.Button("Button1"); java.awt.Button button2 = new java.awt.Button("Button2"); frame.add("East", button1); frame.add("West", button2); frame.pack(); frame.setVisible(true); } }; boolean sameThread = false; if (sameThread) { thread.run(); } else { thread.start(); } /* SWT */ Display display = new Display (); Shell shell = new Shell (display); shell.setText ("SWT Shell"); shell.setLayout (new RowLayout ()); org.eclipse.swt.widgets.Button b1 = new org.eclipse.swt.widgets.Button (shell, SWT.PUSH); b1.setText ("Button1"); org.eclipse.swt.widgets.Button b2 = new org.eclipse.swt.widgets.Button (shell, SWT.PUSH); b2.setText ("Button2"); shell.pack (); shell.open (); while (!shell.isDisposed ()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose (); System.exit (0); }
IIRC, I've tried those approaches some time ago and they weren't successful.
Try moving the load of AWT (with Toolkit.getDefaultToolkit()) to the start of the code. No UI activity can happen on the non-main thread, or else Carbon (or Cocoa, for that matter) will not get UI events. (I have a meeting, but I will look at this too later this afternoon.)
Silenio, It's not a deadlock, but rather none of the AWT windows are getting events sent to them. The Display and Shell listen for events on the windows they create, but events not going to an SWT object aren't being handled by anything. I think we'll need to find a way for SWT to send events it doesn't handle to AppKit. Maybe by creating a catch-all event handler which forwards the event to NSApplication, so that it can then dispatch the event to the AWT windows.
>I think we'll need to find a way for SWT to send events it doesn't handle to >AppKit. Maybe by creating a catch-all event handler which forwards the event >NSApplication, so that it can then dispatch the event to the AWT windows. Scott, isn't this supposed to happen for free if I understand correctly the article below? http://developer.apple.com/documentation/Cocoa/Conceptual/CarbonCocoaDoc/Articles/CarbonCocoaComm.html
In this particular case, the SWT event loop is executing in the handler for another event, so no further events are being dispatched until that handler returns. Silenio, that link is interesting, and is, honestly, news to me. It does give me an idea about a change I can try out in the AWT. I will do that this afternoon and report back. It's interesting in the academic sense that if you take out the SWT event loop in #118, both the SWT and AWT window appear, and I can interact with either one. That confirms what that article was talking about -- the NSApplication created by the AWT is pumping events to the AWT and SWT windows. I should be able to modify the AWT to not do anything special when started up in an SWT application, and see if the SWT dispatch loop can correctly dispatch events to those windows. Currently we put the AWT into 'pseudo-headless' mode, but maybe that's not needed.
A little more info. The snippet below worked fine when running JDK build 1.4.2_09-232 (both windows receive events properly). It stills fails when running JDK build 1.5.0_05-83 with a StackOverflowError exception. Note that this is a little different from the snippet in comment#119. There is a call to NsApplicationLoad() and AWT is started later on by pressing in SWT button. The SWT event loop is dispatching events to both windows. public static void main(String [] args) { /* AWT */ final Thread thread = new Thread () { public void run() { System.out.println("AWT running = " + Thread.currentThread()); Toolkit.getDefaultToolkit(); final Frame frame = new Frame("AWT Frame"); java.awt.Button button1 = new java.awt.Button("Button1"); java.awt.Button button2 = new java.awt.Button("Button2"); frame.add("East", button1); frame.add("West", button2); frame.pack(); frame.setVisible(true); frame.addWindowListener(new WindowAdapter() { public void windowClosing(WindowEvent arg0) { frame.dispose(); } }); } }; /* SWT */ System.out.println("nsload=" + OS.NSApplicationLoad()); Display display = new Display (); Shell shell = new Shell (display); shell.setText ("SWT Shell"); shell.setLayout (new RowLayout ()); org.eclipse.swt.widgets.Button b1 = new org.eclipse.swt.widgets.Button (shell, SWT.PUSH); b1.setText ("Button1"); org.eclipse.swt.widgets.Button b2 = new org.eclipse.swt.widgets.Button (shell, SWT.PUSH); b2.setText ("Start AWT"); b2.addListener(SWT.Selection, new Listener() { public void handleEvent(org.eclipse.swt.widgets.Event event) { thread.start(); } }); shell.pack (); shell.open (); while (!shell.isDisposed ()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose (); System.exit (0); }
I didn't expect my comment #77 would wake up so much people ! ;-) I would love to help resolving this bug, but I'm more like a "pure Java solutions" guy with very little knowledge of Carbon or Cocoa and this may not be very helpful for this tricky bug. Anyway, I think that any wrong idea may give good ideas to other with a better knowledge, so here's mine. Remembering how java.awt.EventQueue is working, I wonder if the following solution could be possible : replace the default EventQueue instance by the instance of a subclass of EventQueue that would forward all AWT events to the waiting SWT dispatch thread. The SWT thread wouldn't have to read any event from the native OS but would "simply" translate all coming AWT events to SWT events. The problem would be to ensure that SWT windows can receive events if they are not children of AWT windows ?
Thanks to Silenio's suggestion, Java 5 Release 4 DP 6 now lets you bring up AWT windows in an SWT application with no modification to your SWT application. I mainly used the examples in comments #119 and #125 to test it. We also modified those examples to open up the SwingSet2 demo application and an AWT widget test in response to an SWT button click or from an arbitrary thread. The change on our part was to use NSApplicationLoad() to create an NSApplication and register Carbon handlers for the application, and then set compatibility mode (see below) to prevent deadlocks when doing AWT operations from the SWT thread. Before anybody's hopes are raised too high, let me stress this is not an implementation of the SWT_AWT package, but it gets us closer to that goal. There are also a few things to remember: -- You still need to use -XstartOnFirstThread. -- You can start the AWT from any thread, but if you're not going to load it from the SWT thread you should set the property 'apple.awt.usingSWT' to true. -- Don't use SwingUtilities.invokeAndWait from the SWT thread. You will hang the application. If you want to trigger some AWT action from SWT, use invokeLater. -- Avoid manipulating AWT objects from the SWT thread. When the SWT is in use, the AWT is loaded in 'Cocoa compatibility mode', which means that if we detect a deadlock while trying to do some Cocoa operation, we'll time out after .1 s and then do it anyway. -- JNLP applications still do not work, even with this compatibility mode. We're working on it, though.
Does this mean that we can also embed an SWT widget in a AWT window on MacOS? I guess no, since you're not talking about an SWT_AWT implementation.
No, not yet. But the Cocoa and Carbon integration step has to happen first before we get to any embedding solution.
I'm still working on this. Now that EclipseCon is done and Java 5 update 4 is pretty much done, I can devote full attention to finishing up an embedding solution for the SWT guys to use.
(In reply to comment #130) > I'm still working on this. Now that EclipseCon is done and Java 5 update 4 is > pretty much done, I can devote full attention to finishing up an embedding > solution for the SWT guys to use. > All I have to say is SWEEEEEEEEEEEET! It's gonna be a happy day when this black eye goes away. This has broken everything from MyEclipse's UML and HTML tools thru jPedal's PDF viewer and the xPath Explorer plugin. I realize there are many tools that don't rely on the SWT_AWT bridge, but the ones that do are often not replaceable with other plugins (hence it's logical to assume that the bridge is key to the task being handled by the plugin to begin with). Go Apple! I'll be able to look Windows-using colleagues in the face once more. Laterz, J
I agree it's a black eye, but it's an unsurprising one considering the SWT mixed Java/native approach to things. I'm surprised that the Eclipse team hasn't put more pressure on the SWT team to fix this since it means *no* standard Swing app can get componentized as an Eclipse plugin which will run on Mac. > This has broken everything from MyEclipse's UML [...] Off topic, but as far as MyEclipse UML goes, that's just ArgoUML renamed and wrapped as a plugin, so a workaround is to download native ArgoUML (100% Java) and run it alongside Eclipse. As an added advantage, you'll get support for a newer version of UML and a bunch of other goodies.
>I agree it's a black eye, but it's an unsurprising one considering >the SWT mixed Java/native approach to things. Not really. The mixed Java/native approach makes interacting with native code pretty simple. The issue here is that AWT is more than native code. It comes with a it's own threading model (among other things). Did you actually read this bug report?
(In reply to comment #133) > >I agree it's a black eye, but it's an unsurprising one considering > >the SWT mixed Java/native approach to things. > > Not really. The mixed Java/native approach makes interacting with native code > pretty simple. The issue here is that AWT is more than native code. It comes > with a it's own threading model (among other things). Did you actually read > this bug report? > It really is a black eye, and it really is because of SWT's part native approach. If SWT had merely extended the AWT event model or had been implemented as a Swing LAF - with optional native peers - then we wouldn't be here. This may be a matter of my opinion, but there's a lot of people sharing it. JGoodies.com has a reasonable mockup of a SWT LAF in pure Java code. As one of the earlier posts (#6) points out, this is the exact type of problem that Sun and many others were concerned about. Have YOU actually read this bug report? If you doubt that it's a black eye after reading this report, maybe you should go read the MyEclipse forums. They're pretty piping mad over there as well. And generally a lot less reserved about it. I HAVE read this bug report - many times for nearly two years - crippled and waiting for its solution. I know I'm far from alone in this. The only solution short of waiting for the SWT team and/or Apple to fix it was to rewrite large portions of SWT myself. Yes it's open source and I can do that, but it requires a lot more time than I have to devote to fixing a broken architectural choice (again, my opinion, but obviously shared by many). SWT has effectively broken the social contract of platform independence that Java promises. Even if it is fixed (along with Apple - unnecessarily IMO - having to modify their customized JVM), it's still creating unnecessary platform specific issues. There is a lot of frustration surrounding this issue, and there will be a lot of happy people when it's solved. It's obviously nearly there - thanks especially to Scott, Silenio, and Eugene for getting us this close.
I agree with Calvin that is really is a "black eye." SWT is promoted as a cross-platform toolkit for Java, and it needs to take into account things like the way AWT is implemented, or that not every OS implements threading in the same way. Blaming AWT's architecture, or Apple, and saying there's nothing really wrong with SWT's approach is just putting on blinders, IMO. (I also agree that this is exactly the kind of heavyweight/native technical problem that Sun was worried about.) Even though this isn't really a problem with Mac OS X, itself, Apple is making an effort to try and get things working. I appreciate that attitude. It's disheartening to see casual dismissal of the problem from the SWT side of the equation (where there should be *more* concern, IMO), especially when so many people are affected by, concerned with, and following this bug.
(In reply to comment #133) > >I agree it's a black eye, but it's an unsurprising one considering > >the SWT mixed Java/native approach to things. > > Not really. The mixed Java/native approach makes interacting with native code > pretty simple. The issue here is that AWT is more than native code. It comes > with a it's own threading model (among other things). Did you actually read > this bug report? > Steve - I now understand why we have seen almost no progress on this bug until Scott came on a couple of months ago. I re-read this thread yet again before I got accused of having missed critical points - paying attention especially to which posts you made. Few of them were more than a few sentences - almost all of them deflected the issue completely or were similarly callous as you were to Tom (post #133): It was your post (#7) that suggested it was open source so we should just jump in and help fix the architectural problems. I had remembered the post earlier but didn't realize that you had written it. Your later post (#109) points out the extreme complexity of the problem and also the fact that the SWT team (being small) won't be working on this problem. Another post (#36) says that it's really the job of the Operating System vendor to deal with it. I've also noticed that you're from IBM. I now also understand that you wrote the book and were one of the original architects. Now I'm not a big conspiracy theorist, but add this all that up together and add in the name "Eclipse" (of the Sun) and I really have to start wondering what really is going on here. SWT ISN'T PORTABLE - at least not in the sense that Java programs are - it doesn't run on other Java enabled platforms, including OS/2, VMS, BeOS or Solaris x86. IBM has a popular product here (Eclipse) and it's almost like it's being used to bludgeon their competition. Underlying your arguments is an expectation that others should be fixing your architectural limitations if they want to play in your sandbox. APPLE NEVER SHOULD HAVE HAD TO MODIFY THEIR JVM TO WORK WITH SWT - SWT SHOULD HAVE BEEN RE-ARCHITECTED TO WORK WITH APPLE'S JVM. Isn't SWT supposed to implement missing base functionality to give a common substrate? To create a framework for developing portable applications? From the back cover of your book: "SWT allows developers to build efficient, portable applications that directly access the user-interface facilities of the operating systems it is implemented on." We've clearly lost portability here. Even if my absurd suspicion about conspiracies is wrong, I still have to wonder if it really was necessary to have implemented SWT completely natively. If the problem is so complex to support for such a small team, then maybe it needs to be architected in a way that is truly cross-platform but doesn't require that level of support. A pure Java Swing implementation with optional native peer approach would have guaranteed base compatibility while still offering native components and integration for supported platforms. Before I re-read and saw what you had posted, I was just mildly angry at your earlier post. After realizing who you were, the responsibility you have on the project, and the other callous posts, I really am beyond angry. If you really have no idea how frustrated and angry people are about this issue you really should stop posting here. You're just adding fuel to the fire. That having been said, I'm glad Scott did the work on his end that he did. It seems like a kludge in some ways, but it also seems like it will get us there a lot quicker.
Re Comment #136: Calvin, everyone understands your frustration, and feel it to various degrees. But trust me, I know Steve and he genuinely want this solved, as much as you. A bug is not forum for that kind of personal and unwarranted attack imho. Trust me also on that one, I did in the past on other occasions and it buys you squat.
Not to start a flame war or anything, but I don't see how the lack of the ability to embed AWT/Swing within SWT on one platform is a serious flaw in the architecture of SWT. This feature wasn't a requirement when SWT was originally designed - it's a useful hack that was added in the third version of Eclipse. The design goals quoted in comment #136 - "SWT allows developers to build efficient, portable applications that directly access the user-interface facilities of the operating systems it is implemented on." holds true without this feature - if you use only SWT in your SWT app (Eclipse itself and hundreds of plug-ins and RCP apps, work fine on OS X without needing this feature). I agree that this is frustrating and a serious limitation on OS X, but I don't think it calls into question the architecture decisions made when SWT was developed. Arguing about the problem is quite pointless - the number of interested parties voices the importance of the issue. What should be focused on is coming up with a solution.
(In reply to comment #138) > Not to start a flame war or anything, but I don't see how the lack of the > ability to embed AWT/Swing within SWT on one platform is a serious flaw in the > architecture of SWT. This feature wasn't a requirement when SWT was originally > designed - it's a useful hack that was added in the third version of Eclipse. > The design goals quoted in comment #136 - "SWT allows developers to > build efficient, portable applications that directly access the user-interface > facilities of the operating systems it is implemented on." holds true without > this feature - if you use only SWT in your SWT app (Eclipse itself and hundreds > of plug-ins and RCP apps, work fine on OS X without needing this feature). I > agree that this is frustrating and a serious limitation on OS X, but I don't > think it calls into question the architecture decisions made when SWT was > developed. Pure SWT apps do run fine. But the SWT_AWT feature was touted as a major feature in 3.0, so I do disagree with that it isn't an architectural flaw. And looking at all the plug-ins that were written with the assumption of it, I'm not alone in thinking it's a major component. I understand the original architectural factors. I still think some were flawed from the beginning. I think the pure-native approach did create a divisiveness that we're seeing in this bug. The architecture broke down supporting this new 3.0 feature. At least one problem I have with it is that it wasn't extensible as originally promised. Regardless, it doesn't support this kind of feature addition now. > > Arguing about the problem is quite pointless - the number of interested parties > voices the importance of the issue. What should be focused on is coming up > with a solution. > You're absolutely right. This isn't the place for flame wars, it's a place for solutions. I didn't mean to start one. I apologize for ranting. I've just started looking at the innards of SWT to see what I can do about it. I really didn't want to do have to do that, but I don't see the SWT team getting to it according to the earlier post (#109). So I'll shut up for now and put my time where my mouth is. I still maintain though that this is a time to revisit the architecture regardless. This larger problem won't go away even if one of us can match a kludge to Scott Kovatch's to make it all work.
(In reply to comment #137) > Re Comment #136: > Calvin, > everyone understands your frustration, and feel it to various degrees. But > trust me, I know Steve and he genuinely want this solved, as much as you. > A bug is not forum for that kind of personal and unwarranted attack imho. > Trust me also on that one, I did in the past on other occasions and it buys you > squat. > I hope you're right here about him wanting to solve it, but I just don't see it in his replies. And the replies to Jay and Tom especially really just seem like rude deflections.
Calvin, I assure you that we are all just engineers here, attempting to fix a technical problem. Any information you have which is relevant to that problem is appreciated. Please don't attempt to read conspiricy theories, opinions and blame into the comments in this bug report. That *is* rude and does a disservice to everyone who is working on the problem, including me. If you are interested in any of the technical details about my original comment, ask away. Basically, SWT is appartment threaded which means that interfacing C code to it is a matter of just calling your native from the GUI thread, which is exactly what the SWT implemenation does to interface with operating system controls. Steve
I sense that there is an earnest desire to fix this bug. However, one of two things are the case. First, it's impossible to fix. Second, it's only a matter of interest and motivation, where there doesn't seem to have been an adequate level of either over the past two years relative to the high profile of the issue and the number of people who have taken an interest in it. What I think should be learned from this is that there is indeed a "social contract" of cross-platform behavior inherent in the whole premise of Java (TM). If there is anything added to SWT that will completely break it on one of its target platforms, then it should *absolutely*, *unequivocally*, be placed in a separate package hierarchy (something like .win32*, .gtk*, etc.) and never be moved until it is supported *equally* on all target platforms. This will allow for experimentation and having certain platforms lag others, but not seriously upset people who use Java primarily because it is cross-platform. That is only fair, especially to all of us who have struggled watching the apparent lack of interest and motivation to get this fixed (admittedly from the sidelines), not to mention the perception of what it is doing to the Java (TM) platform in general. I'm starting to want to see this fixed more than I wanted to see the Red Sox finally win the World Series. :)
I don't want to continue the argument of 'blame' here because this is a bug report and not a Java Lobby discussion thread. That said, a lot of decisions on both the SWT and Apple's part have gotten us where we are right now. The post-1.3 AWT has been pretty hostile to Carbon applications in general. The SWT_AWT bridge is a specific case of a larger problem we've had with our AWT working in Carbon applications. And, as Steve N. said, it's never been a political/ideological issue, certainly from Apple's point of view. We thought it was impossible to fix, and I'm happy to say that I no longer believe that's the case.
And now for something completely different -- actual progress to report. I have a prototype of an AWT Frame embedded in a Carbon window in a C application. It's not a huge leap to convert that into something the SWT can use, so I'm going to work with Silenio on writing a SWT_AWT API for it over the next couple of days, and we hope to have good things to report by the end of the week.
> its target platforms, then it should *absolutely*, *unequivocally*, be placed > in a separate package hierarchy (something like .win32*, .gtk*, etc.) and never I think you are looking at the current list of SWT platforms, and the current state of the Java on the Mac. You should be looking at those things when the bridge was created to understand why it is in the package it is in.
(In reply to comment #145) > > its target platforms, then it should *absolutely*, *unequivocally*, be placed > > in a separate package hierarchy (something like .win32*, .gtk*, etc.) and never > > I think you are looking at the current list of SWT platforms, and the current > state of the Java on the Mac. You should be looking at those things when the > bridge was created to understand why it is in the package it is in. > I don't understand your point. Would you please clarify? My point was that there should be in the future a strong precedent/procedure/requirement in place for any technology added to the "core SWT" that it is inherently cross platform on any target platforms at the time of a major release of SWT itself. Otherwise, it should be put in an "experimental" area (package) so that people don't unwittingly use an API that will break cross-platform compatibility. Furthermore, it should be 100% clear to every developer using any given API (with something stronger than a JavaDoc comment) exactly what platforms their application will be broken on as a result of using said API. How can that not make sense?
(In reply to comment #144) > And now for something completely different -- actual progress to report. I have > a prototype of an AWT Frame embedded in a Carbon window in a C application. > It's not a huge leap to convert that into something the SWT can use, so I'm > going to work with Silenio on writing a SWT_AWT API for it over the next couple > of days, and we hope to have good things to report by the end of the week. > IT WORKS HOLY SHITENING IN ME SHORTS!!!!!!!!! XPATH EXPLORER NOW RUNS AFTER THE JAVA UPDATE!!!! SILENIO AND SCOTT ARE HEROES!!!!!!!! IT WORKS IT WORKS IT WORKS!!!!!!!! (and still being up at 3AM has it's bennies too) ;)
> IT WORKS HOLY SHITENING IN ME SHORTS!!!!!!!!! Glad you're not working in my hallway!
(In reply to comment #148) > > IT WORKS HOLY SHITENING IN ME SHORTS!!!!!!!!! > > Glad you're not working in my hallway! > Ahem... it was late, I couldn't sleep, and I swung by the laptop to check mail on the way back to bed and behold, a Java update. When it worked, I (apparently) got a little (over) excited, which I can blame on raw geek energy and sleep deprivation. ;) Anyway... it's looking good at this point, but my only test case is XPath Explorer, which is a fine test case, no doubt... but a little light. Thanks Silenio and Scott... good job.
Keep that energy. I almost died laughing when I read your comment.
(In reply to comment #136) A comment on the "conspiracy theory" post: I used to think about the SWT versus Swing debate as a scenario of conflict. Supporting evidence here is the name choice ("eclipsing the Sun") and that some parts of the Eclipse API duplicate standard Java functionality (example: the file/resource API) instead of trying to fit in and extend it. But the more I reflect on this issue, the more I think there is tremendous potential for cooperation: - AWT is very limited: SWT could become a logical extension of AWT, its "migration path". - SWT has custom controls: which feels weird, because I always thought that SWT disliked custom controls and wanted native widgets. Here it might make more sense to migrate SWT's custom controls to Swing. - Layouts: Why can't layout managers be shared between SWT and AWT? - Data binding: this is such a fundamental GUI programming mechanism and yet there are competing standards being developed in both camps. - Less confusion: the partitioning outlined above would make it very clear which toolkit to use in which situation. Much like the Linux desktop APIs KDE and Gnome currently realize that it makes sense for them to work together. Obstacles: - Social hurdles: My guess is that the competition from SWT actually helped improve Swing; who knows if SwingLabs would have happened without it. Some of the current debate *sounds* like it is about cooperation, but I'm not sure that it actually is: If JFace binding invites Sun to join, it must feel to Sun like: "Give up your stuff, come to us and do it our way". I'm not sure how one can get out of this dilemma, but it is worth trying. A successful, brilliant example is the Annotation Processing API being adopted by Eclipse. - Technological hurdles: I do not know if SWT and AWT/Swing can (technically) be made work together in a more integrated fashion, but it sure would be nice if this were possible. Any comments?
(In reply to comment #151) > A comment on the "conspiracy theory" post: .... > Any comments? This seems kinda off topic for a bug report. This seems like more of a blog, forum or newsgroup kind of conversation. I, for one, would like to keep this bug focused on the technical issue at hand.
In the release notes for the most recent Java update (J2SE 5.0 release 4) there is a claim that this has been resolved. Has this been tested? Radar #3905894 AWT integration within SWT applications Description: SWT applications were unable to host AWT or Swing windows. Resolution: J2SE 5.0 allows SWT applications to host AWT and Swing windows. Java Web Start applications and Applets are unsupported. This fix is provided by using the Compatibility Mode feature of CocoaComponent and is subject to many of its limitations. Also, you cannot embed AWT and Swing components within SWT windows. Finally, there are known issues with modal dialogs. To reliably show dialogs, use SwingUtilities.invokeLater.
Some work was done by Apple to enable AWT/Swing widgets to run in another top level window. I think that's what all the "shitening in shorts" was about.
Steve, Now that Scott Kovatch has done all Apple can do to enable this bug to be addressed and has made it publicly availble in Java 5 Update 4, is there a timeline to complete the resolution on the Eclipse side? I notice this bug still has no target milestone so any work that is planned or ongoing isn't externally visible to all those interested here. Thanks in advance for any clarity you can provide.
Todd, that's not entirely correct. Java 5 update 4 simply allows SWT Shells and AWT Frames to run in the same application. That's not the same thing as what this bug involves. The current plan (I think) is that I will send diffs to Silenio and Steve that will include a new Carbon-specific version of the SWT_AWT class, which need to be rolled into the SWT. Then, Apple will release the code that implements AWT embedded frames in Carbon applications as an add-on. More details as we get there.
We are proceeding cautiously but steadily. Please stand by.
Created attachment 40363 [details] Carbon version of SWT side of SWT_AWT bridge This is the SWT portion needed to find the embedded frame class and create it.
I have attached the SWT side of the SWT_AWT bridge for Carbon. Watch this bug for details on the additional changes needed from Apple to get this up and running.
We definitely want to get this out. +1.
+1
SWT side patch released for 3.2 RC3.
Ditto getting this out. +1
I would like to serve a big round of virtual beers to Scott, Steve, Silenio, Andre and the SWT and Apple team! This was laborious and tough but exemplary collaboration Thanks guys...YOU ROCK. No pants involved here ;-) We just miss the "Apple SWT compatibility pack" I guess now :-) as from the test I made a minute ago with SWT from CVS HEAD, that seems to be the only part missing... Tne test I made was on ppc 10.4.6 with java 1.5.0_06-112 Scott: When would that be available? ie CHIViewEmbeddedFrame et al?
We (Apple) are working out the details on how we're going to release this. It's not in Java 5 release 4. We don't want to wait for a formal 1.5 update, but we also need to make sure that we do it right to save us future headaches if we do ship an update to 1.5 on Tiger. I hope to have something more concrete to say early next week.
I'll convert that round of virtual beers to real ones for Scott, Steve, Silenio, Andre and the SWT and Apple team if any of you will be at JavaOne week after next.
Great, I'll be there!
(In reply to comment #166) > I'll convert that round of virtual beers to real ones for Scott, Steve, > Silenio, > Andre and the SWT and Apple team if any of you will be at JavaOne week after > next. ....or all involved can enjoy some free beers compliments of the Eclipse Foundation at the Thirsty Bear on the Wednesday night of JavaOne. See http://ianskerrett.blogspot.com/2006/05/eclipse-party-at-thirsty-bear.html. Just send an email to thirstybear@eclipse.org if you can make it.
It is sinful to have this bug unsatisfied since 2004. I am delighted to see it resurected and hope to see it resolved so I can use my Mac with Eclipse as needed.
Fixed > 200605 17 Thanks Scott (and Silenio). I'm shitening in nme' shorts!!!
To get the SWT Compatibility LIbraries, go to http://connect.apple.com and then select the Downloads selection. If you don't have an account, you can create one for free. This is a ~180k download. Please read the release notes for any limitations. File bugs here in the Eclipse bug system, and I will track them here and in Apple's internal system.
Is it really working? I am still getting error "java.lang.ClassNotFoundException: apple.awt.CHIViewEmbeddedFrame"
This fix does not work on the Mac. Please reopen this bug until it is fully tested and verified by live users. Using Eclipse as a cross platform tool is not possible on the Mac.
Please re-read the comment in #172. The SWT team has done all that they can do, and the remainder of the fix is available as a download from Apple at connect.apple.com. Steve, you may want to add a link to connect.apple.com on the SWT page.
I have downloaded and installed SWT compatibility library and all required updates (Java and Mac) and I can find that there is jar added to the "ext" directory. However I am still getting error about not found class... I just want to know, can someone confirm that it is really working?
I've the same problem as Egidijus. Using SWT_AWT in a Eclipse plugin causes a ClassNotFoundException: apple.awt.CHIViewEmbeddedFrame The same plugin works on Windows. SWT compatibility library is installed! Mac OS X 10.4.6 PPC, Java 1.5.0_06, Eclipse 3.2RC4 Seems that the problem occurs only in Eclipse plugins that use SWT_AWT. I've tried the SWT stand-alone application Snippet154.java from http://www.eclipse.org/swt/snippets/ and it works. Here is the error from the Eclipse Error Log view: eclipse.buildId=I20060512-1600 java.version=1.5.0_06 java.vendor=Apple Computer, Inc. BootLoader constants: OS=macosx, ARCH=ppc, WS=carbon, NL=en_US Framework arguments: -keyring /Users/charly/.eclipse_keyring -showlocation Command-line arguments: -os macosx -ws carbon -keyring /Users/charly/.eclipse_keyring -consoleLog -showlocation Error Tue May 23 16:49:24 CEST 2006 Not implemented [need SWT compatibility pack from Apple] (java.lang.ClassNotFoundException: apple.awt.CHIViewEmbeddedFrame) org.eclipse.swt.SWTError: Not implemented [need SWT compatibility pack from Apple] (java.lang.ClassNotFoundException: apple.awt.CHIViewEmbeddedFrame) at org.eclipse.swt.SWT.error(SWT.java:3400) at org.eclipse.swt.awt.SWT_AWT.new_Frame(SWT_AWT.java:104) at com.jformdesigner.vq.a(SourceFile:43) at com.jformdesigner.lj.createContents(SourceFile:43) at com.jformdesigner.CC.createContents(SourceFile:27) at org.eclipse.jface.preference.PreferencePage.createControl(PreferencePage.java:233) at org.eclipse.jface.preference.PreferenceDialog.createPageControl(PreferenceDialog.java:1403) at org.eclipse.jface.preference.PreferenceDialog$12.run(PreferenceDialog.java:1162) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) ... Caused by: java.lang.ClassNotFoundException: apple.awt.CHIViewEmbeddedFrame at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:407) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:352) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:164) at org.eclipse.swt.awt.SWT_AWT.new_Frame(SWT_AWT.java:102) ... 56 more
I am getting the same error with Eclipse 3.2rc5 / java version "1.5.0_06" with the Apple SWT Compatibility Libraries. Has anyone gotten this to work? (In reply to comment #177) > I've the same problem as Egidijus. > Using SWT_AWT in a Eclipse plugin causes a ClassNotFoundException: > apple.awt.CHIViewEmbeddedFrame
It looks like we'll need to modify eclipse.ini on the Mac. Add the line -Xbootclasspath/a:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/frameembedding.jar to Eclipse.app/Contents/MacOS/eclipse.ini. Once I did this, I was able to get MyEclipse 5.0m1 to load. I know I tried Eclipse plugins that use the bridge, but apprently not recently enough.
I am running RC5, Java build 1.5.0_06-112 and compatibility patch. I have tried the example application at the beginning of this bug and the plugin example still hangs eclipse. I also tried the following code and can't seem to get any awt/swing embeded in swt. Any ideas? I do see the following in the console : 2006-05-23 22:13:30.968 java[1579] [Java CocoaComponent compatibility mode]: Enabled 2006-05-23 22:13:30.968 java[1579] [Java CocoaComponent compatibility mode]: Setting timeout for SWT to 0.100000 import java.awt.event.*; import org.eclipse.swt.*; import org.eclipse.swt.widgets.*; import org.eclipse.swt.layout.*; import org.eclipse.swt.awt.SWT_AWT; public class SwingAWTClass { public static void main(String[] args) { final Display display = new Display( ); final Shell shell = new Shell(display); shell.setText("Using Swing and AWT 1"); shell.setSize(350, 280); Composite composite = new Composite(shell, SWT.EMBEDDED); composite.setBounds(20, 20, 300, 200); composite.setLayout(new RowLayout( )); java.awt.Frame frame = SWT_AWT.new_Frame(composite); java.awt.Panel panel = new java.awt.Panel( ); frame.add(panel); final javax.swing.JButton button = new javax.swing.JButton("Click Me"); final javax.swing.JTextField text = new javax.swing.JTextField(20); text.setText("THIS IS A TEST"); panel.add(button); panel.add(text); button.addActionListener(new ActionListener( ) { public void actionPerformed(ActionEvent event) { text.setText("Yep, it works."); } }); shell.open( ); while(!shell.isDisposed( )) { if (!display.readAndDispatch( )) display.sleep( ); } display.dispose( ); } }
The plugin example above will always hang Eclipse on the Mac because the JOptionPane it displays is blocking the SWT event dispatch thread. As for your sample code, I see you also filed a Radar, which is good, but I don't have an answer right now.
Scott, I have added frameembedding.jar to bootclasspath but still get ClassNotFoundException. Have anybody successed in using SWT_AWT on Mac?
I've succesfully run the dependency analysis view of metrics plugin (http://metrics.sf.net). I'm running Eclipse 3.2RC5 and I've applied the compatibility patch. java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) and this is my eclipse.ini : -vmargs -Xdock:icon=../Resources/Eclipse.icns -XstartOnFirstThread -Xbootclasspath/p:../../../plugins/org.eclipse.jdt.debug_3.2.0.v20060518/jdi.jar -Xms40m -Xmx256m -Dorg.eclipse.swt.internal.carbon.smallFonts -Dorg.eclipse.swt.internal.carbon.noFocusRing
The class is not found in Eclipse because it was provided in a extension jar and the plugin class loader does not have the extension directory in the classpath. See this bug#143482 for info. The class is found when running a standalone SWT app.
That's great! I wrote that plugin but have not had a chance yet to try all this out. Thanks for trying it with my metrics plugin, and it is fantastic news that that now works. Even better news that it works out of the box without changes...This renewed my motivation to continue working on that :-) Many thanks to everyone involved for fixing this, Frank Sauer (In reply to comment #183) > I've succesfully run the dependency analysis view of metrics plugin > (http://metrics.sf.net). > I'm running Eclipse 3.2RC5 and I've applied the compatibility patch.
Hi all. This is my first posting here. I am working on a 'x-platform' "Swing Browser". I embed a Browser into a Canvass which is placed onto a JPanel. Since SWT Browser 3.1.2 I have been testing on Windows. I have no runtime issues with Win. I am now using 3.2 build 32 (3232) because I need Mac OS X support on Intel. My shiny new Mac (Core Duo Intel, OS X 10.4.6, Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) is giving me grief with a 'not implemented' error. The code runs fine on Windows with the same version SWT binaries for Winblows. Here's the stack: Exception in thread "Thread-22" org.eclipse.swt.SWTError: Not implemented at org.eclipse.swt.SWT.error(SWT.java:3400) at org.eclipse.swt.SWT.error(SWT.java:3297) at org.eclipse.swt.SWT.error(SWT.java:3268) at org.eclipse.swt.awt.SWT_AWT.new_Shell(SWT_AWT.java:158) And here's the code: //a method called on the event dispath thread in a class that implements Runnable and extends JPanel private void initializeOnEventDispathThread() { _swtUIThread = new Thread(this); _swtUIThread.start(); } //the thread work public void run() { synchronized(_lock) { if (_display == null) { _display = new Display(); } _lock.notifyAll(); } // start the SWT runner Runnable swtRunnable = new Runnable() { public void run() { try { //_canvas is a java.awt.Canvass already constructed on EDT //this call breaks the Mac _shell = SWT_AWT.new_Shell(_display, _canvas); //...some other code here to bring up the browser } catch (Exception e) { log.debug("new_Shell error:"+e.getMessage()); } } }; display.syncExec(swtRunnable); } All of the 3232 libs are on the PATH as expected. There is no java_swt on the PATH.
Did you see comment 172?
Thanks for that Steve. I installed the package after downloading from connect.apple.com. I still get the same error, but there is now a subtle difference. The error org.eclipse.swt.SWTError outcome is the same and the browser fails to function. BUT, my Java Application's 'Application Menu' (the one just to the right of the Apple Menu) now says "SWT". Maybe this was the case previously, but I didn't notice it until now. Maybe the Menu swap is just a side-effect of something breaking on the AWT EDT because of the SWT_ERROR (???) . Or, could it possibly suggest a bug in the either the Apple update I just installed or the SWT libs for Mac ? In all other regards, my Java Application continues to work as it should. At System.exit(), I eventually get an error spat out to the console: Invalid memory access of location ffd9d9f1 eip=92efa503 239 Segmentation fault along with a Mac System dialog telling me that "The application SWT quit unexpectedly", allowing me send a report, which I have already done. FYI, I also placed the jnilib and the jar (which ship with the update) firectly onto my PATH and CLASSPATH, respectively, just be sure the app had access to the new functionality.
Ok, I have been working some more on this. I think that the issue is Swing related. Having already installed the Mac 10.4 JVM5 patch earlier from connect.apple.com, I then installed this version of Eclipse: Version: 3.2.0 Build id: I20060602-1317 from the 3.2RC7 download area. Here's a snippet from my Eclipse Configuration: org.eclipse.swt (3.2.0.v3232l) "Standard Widget Toolkit" [Resolved] org.eclipse.swt.carbon.macosx (3.2.0.v3232l) "Standard Widget Toolkit for Mac OS X (Carbon)" [Resolved] file:/Applications/eclipse 3.2RC7/plugins/org.eclipse.swt.carbon.macosx_3.2.0.v3232l.jar file:/Applications/eclipse 3.2RC7/plugins/org.eclipse.swt_3.2.0.v3232l.jar Within Eclipse (no Swing) the internal browser executes just fine. So...to a Swing client... With a PATH pointing to the SWT jnilibs and the Apple patch libembedding.jnilib and a CLASSPATH also containing the RC7 jars and the Apple resource, frameembedding.jar when I run a Swing Swt-Browser test case (code from my previous posting), I get: Exception in thread "Thread-2" org.eclipse.swt.SWTError: Not implemented at org.eclipse.swt.SWT.error(SWT.java:3400) at org.eclipse.swt.SWT.error(SWT.java:3297) at org.eclipse.swt.SWT.error(SWT.java:3268) at org.eclipse.swt.awt.SWT_AWT.new_Shell(SWT_AWT.java:162) at au.com.practica.common.SwtBrowserPanel$4.run(SwtBrowserPanel.java:267) at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:152) at org.eclipse.swt.widgets.Display.syncExec(Display.java:3825) at au.com.practica.common.SwtBrowserPanel$3.run(SwtBrowserPanel.java:195) at au.com.practica.common.SwtBrowserPanel.doDisplaySyncExec(SwtBrowserPanel.java:212) at au.com.practica.common.SwtBrowserPanel.displaySyncExec(SwtBrowserPanel.java:177) at au.com.practica.common.SwtBrowserPanel.run(SwtBrowserPanel.java:283) at java.lang.Thread.run(Thread.java:613) [Incidentally, I execute this test application from within Eclipse]. So....any thoughts anyone ?
Hi Julian, let's move the discution of your problem to a new bug report. Please open a bug report adding a simple testcase that shows the problem. Thanks!
Hi Silenio and others.... https://bugs.eclipse.org/bugs/show_bug.cgi?id=145890 has been created with a source attachment.
I don't suppose anyone would know how to request an eclipse bugzilla admin to transfer the 148 votes on this bug to #145890 ? Or do votes not really matter much anyway?
> I don't suppose anyone would know how to request an eclipse bugzilla admin to > transfer the 148 votes on this bug to #145890 ? Or do votes not really matter > much anyway? You have an interesting concept of how electoral systems work ;) Nobody but the voter can or should be able to change what that person votes for. Votes certainly matter, especially when there are a hundred or more on a single bug. Since this bug is marked FIXED, anyone with a vote attached to this bug should certainly consider moving that vote elsewhere. Votes on a fixed bug no longer have any value.
(In reply to comment #193) > > I don't suppose anyone would know how to request an eclipse bugzilla admin to > > transfer the 148 votes on this bug to #145890 ? Or do votes not really matter > > much anyway? > > You have an interesting concept of how electoral systems work ;) Nobody but > the voter can or should be able to change what that person votes for. Votes > certainly matter, especially when there are a hundred or more on a single bug. > Since this bug is marked FIXED, anyone with a vote attached to this bug should > certainly consider moving that vote elsewhere. Votes on a fixed bug no longer > have any value. > I think what he really means is that this bug was filed with the intention that SWT_AWT stuff would work on Mac OS X when it was fixed. Since for some reason this bug was closed while the problem wasn't fixed and a new bug was opened to get the fix completed more than likely everyone who voted for this bug would vote for the other bug. You have to admit the other bug appears to be a subset of this one: Bugzilla Bug 67384 SWT_AWT not implemented for Mac Bugzilla Bug 145890 AWT side of SWT_AWT bridge unimplemented on OS X
