Community
Participate
Working Groups
Embedding an SWT Browser in Swing on Mac OS X >= 10.4 with 1.5 JVM leads to an error "org.eclipse.swt.SWTError: Not implemented". Here's the stack trace: 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 SwtBrowserTest$1.run(SwtBrowserTest.java:112) at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:152) at org.eclipse.swt.widgets.Display.syncExec(Display.java:3825) at SwtBrowserTest$2.run(SwtBrowserTest.java:137) at SwtBrowserTest.run(SwtBrowserTest.java:155) at java.lang.Thread.run(Thread.java:613) This bug has some history from a previous thread: https://bugs.eclipse.org/bugs/show_bug.cgi?id=67384
Created attachment 43811 [details] A Java source file that demonstrates the issue Read the Java class comments on how to run this class to demonstrate the error
adding myself to CC list
The fix from Bug #67384, while technically allowing you to embed Swing in SWT, seems to deadlock as soon as an application uses any invokeLater calls in its Swing code. Since invokeLater calls are typically used throughout most Swing applications, they would have to be rewritten to make use of the changes from bug #67384. However, even a rewrite of this nature would cause the application to execute completely synchronously, and that would make them extremely inconvenient to use, or unusable, on all platforms. So while the bug #67384 is marked "fixed", the core issues still don't seem to be resolved because you still can't fully utilize Swing on a Macintosh; you can only use a very specific and restricted subset of it. My first inclination is to simply reopen bug #67384, but since there seems to be a lot of sensitivity to that, I'm posting the comments here so that this can become the "new" 67384.
It is correct not to reopen bug #67384, because that bug is about the fact that SWT_AWT was not implemented. This bug is tracking SWT_AWT.new_Shell() issues. If you are seeing a deadlock using SWT_AWT.new_Frame(), please open a new bug for that and provide some code that shows the problem. Thanks!
If you look at the source code contributed by Apple to fix bug 67384, only embedding AWT within SWT was implemented. The reverse, SWT within AWT, was not. This bug should more than likely be retitled "AWT side of SWT_AWT bridge unimplemented on OS X" (or similar) to better reflect the underlying problem, but I'll leave that up to the author of the bug. From the bug #67384 Patch: public static Shell new_Shell(final Display display, final Canvas parent) { if (display == null) SWT.error(SWT.ERROR_NULL_ARGUMENT); if (parent == null) SWT.error(SWT.ERROR_NULL_ARGUMENT); SWT.error(SWT.ERROR_NOT_IMPLEMENTED); return null; }
Is there a radar bug for this yet? Where does this issue stand?
adding myself to the CC list
We need framework support from the Carbon and Cocoa teams to do this. We have two radars tracking it -- one for the Cocoa team and one for the Java team (me) to hook it up.
FYI, I noticed this in the most recent MyEclipse Newsletter: "Though Matisse4MyEclipse is fully integrated into MyEclipse, Macintosh users will be unable to utilize the Matisse4MyEclipse, MyUML, JavaScript debugger, Web 2.0 browser and MyEclipse Image Editor functions due to the long-standing Eclipse SWT_AWT bug #145890." Lingering Eclipse/SWT problems on Mac, whether founded in fact or FUD, often crop up in discussions, blogs, and marketing that mention Swing or NetBeans. It would be really good for Eclipse and Apple to apply whatever resources and tweaks that are needed to eliminate this issue once and for all.
(In reply to comment #9) What about using more of SWT and less of AWT? :-D
*** Bug 163629 has been marked as a duplicate of this bug. ***
I cannot even begin to descibe how frustrating this bug is to many of us ISV's.
Progress anyone? What is going on with this? Can someone from somewhere who knows please post an update?
There is no short-term or quick fix here. The core of the problem is that there is no way to put an HIView inside an NSView. Granted, we did the other direction for putting AWT inside SWT, but that's because we had the benefit of WebKit, which did this to support WebViews inside Carbon windows. We have a request into the Carbon and Cocoa teams to do this, but it isn't a high priority for them right now. But, in the interest of being helpful, I see a couple of ways to proceed, from least to most complicated: -- I get the impression that the main use case that is driving people to embed SWT in an AWT window is the SWT Browser widget, based on this example. Even if we had SWT-in-AWT, you would have an NSView hosting an HIView hosting an NSView, which isn't supported. Would there be any value in a JComponent-based Browser widget that used the API of SWT's Browser? org.eclipse.swt.browser.Browser is the only class in the browser package that relies the underlying SWT control hierarchy, but all of the other supporting classes don't. -- A motivated individual with the time could work on a Carbon event-to-Cocoa event converter for view-level embedding. Using the WebKit open source project, you should be able to get a lot of ideas on how to proceed. -- The biggest project of all involves a Cocoa-based SWT, which feels like using a sledgehammer to kill a wasp, and I know Steve N. is not keen on doing it. However, if you started from the Shell level and worked all the way through the controls, basing them off equivalent AppKit objects, it could fit in to the existing SWT architecture, since we already have Carbon and Cocoa support for Cocoa windows in a Carbon app. This is probably not the right place for this kind of discussion, but I wanted to get the issues on the table.
JDIC is the AWT/Swing browser story. Can that be used instead of the SWT browser by those people who are embedding only to use the browser?
Genuitec uses this bug as a claim why they cannot support the ArgoUML editor (which they repackage as MyEclipse UML) in MyEclipse. See http://tinyurl.com/y4jt5q Steve, can you shed any light on whether your description of the issues (and possible resolutions) relates to the difficulty with supporting ArgoUML? I'm anxious to see ArgoUML/EclipseUML added to (My)Eclipse to support Plone/Zope programming, but seem to be forever stuck with Genuitec claiming this bug as a blocking item.
We're getting pretty far afield now, but ArgoEclipse is an open source Eclipse plugin which is based on a more modern version of ArgoUML than the MyEclipse UML closed source version. My impression was that the resolution of the previous half of this bug provided enough support so that we could now run on a Mac, but I don't have one to test with. Since ArgoEclipse is open source it may be easier to make progress on any remaining bugs if someone wants to help with testing.
I have a little time to help test. I've installed the latest argoUML plugin from the update site: http://argoeclipse.tigris.org/update_site As soon as I attempted to create a new ArgoUML file, eclipse crashed. I've saved the error report that mac os x generated if that would be helpful to you. Please let me know how else I can help get this fixed. -Ben
Please attach the error here.
Created attachment 56996 [details] error report generated by mac os x when I try to run argoUML from eclipse
This is a GP, not "org.eclipse.swt.SWTError: Not implemented".
I know I suggested renaming this bug once before (sorry), but I believe some of the FUD/confusion regarding this bug may be due to its vague title. 1. It seems to be misinterpreted as "the new Bug 67384," which from the comments on that bug was primarily focused on SWT_AWT.new_Frame(). In my experience with two large RCP applications that bug really is fixed. I'm using Java3D within multiple ViewParts on OS X without deadlocks or major issues. I believe that SWT_AWT.new_Frame() covers the vast majority of SWT_AWT use. 2. Correct me please or provide examples if I'm wrong, but I can't imagine an instance in which *this* bug should prevent a 3rd-party eclipse plugin from working. Any eclipse plugin has a top-level SWT component available to embed other SWT components into. Embedding a swing component within an SWT view, only to turn around and embed another SWT view within that swing component (i.e. SWT View->Swing view->SWT view) seems unnecessarily complex. I see no reason this bug should prevent a 3rd party Eclipse plugin developer from supporting OS X? JDIC does seem to provide the browser functionality cited, though I've not used it myself. 3. I propose renaming this bug: "SWT_AWT.new_Shell() unimplemented on OS X" (or similar) to avoid confusion and/or misinterpretation by 3rd parties.
Re comment #21, download Java 5 update 5 DP 2 from connect.apple.com, and also install the native library attached to bug 162687. That should clear up this crash.
Re comment #23 -- Ian, I agree completely.
Re comment #24: yes Scott, that did resolve the issue I had in comment #21. Re comment #18: Tom - ArgoUML appears to work now under mac os x. Anything specific I should be trying to cause it to crash? Re comment #23: Yeah there does seem to be a lot of FUD surrounding this issue. Does anyone know whether the claim from MyEclipse is legitimate (that MyEclipse can't do certain graphical tasks on mac os x due to this issue)?
Greg from MyEclipse says that comment #3 is the problem that prevents their product from working fully on Mac OS X. He has not had a chance to test with the DP2 JVM, and native library (comment #24). Hopefully Greg will update us all when he has time to test it out. Read about it here: http://www.myeclipseide.com/index.php?name=PNphpBB2&file=viewtopic&p=71595#71595&sid=8b4d5e2e7025f11dce95e18f499607f6
The claim in comment #3 is that invokeLater() deadlocks. If this is true, please open a bug report with some sample code that deadlocks on the Mac but works elsewhere. Thanks!
this might be related: https://bugs.eclipse.org/bugs/show_bug.cgi?id=171105 This affects JBoss IDE and its integration of SoapUI.
(In reply to comment #23) > JDIC does seem to provide the browser functionality cited, > though I've not used it myself. Since posting this bug, I have been successfully deploying JDIC to Windows, OSX and Linux with Java 5. The browser-in-swing performance is robust and the performance is good. No major issues :)
Ok Julian, glad you could get the problem solved. Hope is works out for you.
(In reply to comment #15) > There is no short-term or quick fix here. We've noticed :-) > -- A motivated individual with the time could work on a Carbon event-to-Cocoa > event converter for view-level embedding. Using the WebKit open source project, > you should be able to get a lot of ideas on how to proceed. How about a motivated company that sells billions of dollars of MacOS X machines? > -- The biggest project of all involves a Cocoa-based SWT, which feels like > using a sledgehammer to kill a wasp, and I know Steve N. is not keen on doing > it. However, if you started from the Shell level and worked all the way through > the controls, basing them off equivalent AppKit objects, it could fit in to the > existing SWT architecture, since we already have Carbon and Cocoa support for > Cocoa windows in a Carbon app. Either a Cocoa based SWT or a Swing based SWT (so mostly a shim on top of a shim on top of Cocoa from the MacOS perspective). I'm a proponent of the Swing port, but even a Cocoa port would be a better choice than the kludged Carbon port. This seems like it would solve this problem and other future problems. It would probably be overkill, but it's a cleaner architecture and would facilitate new platform support much easier (assuming an existing JVM/Swing port already exists, a native SWT port could be done at leisure). Apple should really consider putting either some resources (maybe Steve K and/or others) or contract someone like Dieter Krachtus to do it for them. (EOS: http://eos.sourceforge.net/index.html).
(In reply to comment #32) Sorry - this conversation really does belong somewhere else. I'm just not sure where. Any suggestions?
Calvin, I know I shouldn't, but ... what exactly is "kludged" about the Carbon port? Specifically, which widgets draw wrong or have the wrong behavior?
(In reply to comment #34) > Calvin, I know I shouldn't, but ... what exactly is "kludged" about the Carbon > port? Specifically, which widgets draw wrong or have the wrong behavior? > You're absolutley right - you shouldn't and neither should I. At least not here. The "kludge" is a fundamental architectural one, not a component level one (well, Carbon itself has some internal event handling complexities using Carbon that make the SWT_AWT nigh impossible to resolve without Apple's commited involvement). There's probably a better place for this argument. These symptoms of the architecture have been going on for almost 3 years with this strain of bugs alone. More are inevitable. I really think it should be discussed in some other forum rather than the bug reports, but then I go back and reread this bug, https://bugs.eclipse.org/bugs/show_bug.cgi?id=67384 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=69930 and realize there's too much resistance internally to bother with any other discussion. So I'll shut up again and go help Deiter over at EoS. Maybe that will make a difference instead of spinning wheels here.
Neither of the bug reports that you provided have anything to do with a carbon widget behaving or drawing wrong. Bug 67384 deals with interop with AWT/Swing. When Apple changed AWT from carbon to cocoa, everyone who had any native carbon C code was broken. That bug is fixed. Bug 69930 asks for a port of SWT to Swing, which would certainly help with this bug report (embedding SWT in Swing), since the underlying SWT widgets would be Swing.
Any reasons why SWT not base on cocoa ? What I know is carbon much more easier to develop and very close to Win32. Is that the reason ? Any future plan port SWT over to cocoa ?
FYI, As of 18mar2007, MyEclipse 5.1.1 is out and still says "Though Matisse4MyEclipse is fully integrated into MyEclipse, Macintosh users will be unable to utilize the Matisse4MyEclipse, MyUML, and MyEclipse Image Editor functions due to the long-standing Eclipse SWT_AWT bug #145890." MyEclipse 5.1.1 is based off of Eclipse 3.2.2.
(In reply to comment #38) > FYI, As of 18mar2007, MyEclipse 5.1.1 is out and still says "Though > Matisse4MyEclipse is fully integrated into MyEclipse, Macintosh users will be > unable to utilize the Matisse4MyEclipse, MyUML, and MyEclipse Image Editor > functions due to the long-standing Eclipse SWT_AWT bug #145890." Could the folks from myeclipse help then?
I talked to their director of marketing (I believe) at EclipseCon this year, and asked what they were trying to do that wasn't working. He wasn't fully aware of what the problems were, but said he would follow up with his engineers. I haven't heard back yet, but I also have been extremely busy with Leopard work.
As another data point, I'd like to mention that with the changes that were made (thank you!) our Swing Designer tool (the Swing portion of our WindowBuilder Pro product - http://www.windowbuilderpro.com) now works very nicely under OSX, and we have added OSX to our list of supported platforms.
Changing OS from Mac OS to Mac OS X as per bug 185991
Would someone who is being impacted by the scenarios covered by this bug please indicate what their situation is (or point at the comment where it is already described). In the mean time, many of the original problem cases have been fixed, so I am lowering the severity to normal. If people are still blocked, feel free to raise it again.
(In reply to comment #43) > Would someone who is being impacted by the scenarios I produce a set of tools to provide native capabilities to Swing. Several users have asked for an OSX compatibility which I cannot provide as I need SWT_AWT.new_Shell() to be implemented.
Well, by definition then, I'd say you're still blocked. :-) Re-raising the severity.
(In reply to comment #45) > Well, by definition then, I'd say you're still blocked. :-) > > Re-raising the severity. > Does raising the severity actually make any difference? It's been on "blocked" for years now (2 years for this, at least 4 if 67384 is included - this is the spinoff bug after that was "fixed"). At 140 votes, it's the 3rd most popular bug. MyEclipse features at least as of 6.0 are still blocked. I believe that will be true for 6.1. I gave up on MyEclipse - the features they have that aren't in Ganymede already don't work on MacOS X. I believe it is still blocking parts of ArgoUML/ArgoEclipse. I downloaded a recent copy to verify this, but I haven't isolated to confirm yet.
Is this issue really a blocker ? If so, shouldn't it be planned for 3.4.1 ? If it was only critical, it imagine it could wait until 3.5 maybe ? In any case, if it remains blocker or critical, it should be have its target set.
This bug cannot be fixed as long as the SWT is written in Carbon and the Mac AWT is written in Cocoa. You cannot embed a Cocoa control (web view) inside a Carbon control (HIWebView) and then embed that inside another Cocoa control (Swing Container) -- the native toolkits don't support it. If a Cocoa-based SWT makes it into 3.5, this bug can be targeted for that release. Reiterating an earlier comment, if web browser support in a Swing/AWT application is what you need to do, please look at JDIC.
As another option to JDIC you can use MozSwing to embed a browser inside of Swing. http://mozswing.mozdev.org and http://sf.net/projects/mozswing
I'll take this. I have the basics of new_Shell working in the cocoa version, but lots of bugs are left.
Created attachment 112144 [details] Initial work for new_Shell in Cocoa Here's the patch for the initial work I've done on this. It doesn't crash or throw exceptions, but embedded controls don't seem to be appearing. I'm stopping here temporarily and moving on to drag and drop.
A side comment from me, the bug originator: First, a belated thanks for the title update. Now the real point... The whole Carbon issue is a train wreck in the making. People should keep in mind that Apple has announced that Carbon will be dropped altogether in the next super-duper revision of OS X (OS X 11 ?). And I'm guessing that's coming sooner, rather than later. Otherwise, what are all the other Apple developers who aren't dedicated to the 10.6 bug/performance update working on? So, at some point the carbon implementation is dead regardless. Since this bug has existed in one variant or another for 4 years or so, time may be better spent on a Cocoa implementation.
(In reply to comment #52) > So, at some point the carbon implementation is dead regardless. Since this bug > has existed in one variant or another for 4 years or so, time may be better > spent on a Cocoa implementation. You may not have noticed that I changed the OS field to 'Mac OS X - Cocoa'. As noted before, this can't be fixed in the Carbon port, and is targeted for the Cocoa port in 3.5. The patch above is a Cocoa implementation of new_Shell, which is vastly simpler when the whole environment is Cocoa.
David, please see http://www.eclipse.org/swt/cocoaport.php.
I suppose, strictly speaking, we should leave this bug open and use a new one to track SWT_AWT.new_Shell() not implemented on cocoa. That might clear up some of the confusion. Scott, you decide.
On second thought, I should probably move this back to the Carbon/OS X category, close it as wontfix/can't fix and open a new bug for the Cocoa port. I'll update this one when I make the new bug.
Cocoa version of this bug is #246929. As noted, this is architecturally not doable in the Carbon port, so I'm marking it WONTFIX.
