Community
Participate
Working Groups
Due June 15'th. Need to determine if embedding AWT/Swing widgets is possible in SWT. NOTES: KH (4/12/99 9:24:15 AM) Follow on commitment for decision on Java 2D support Due July 1'st. Depends on outcome of AWT/Swing interop. McQ (27/11/2000 1:46:39 PM) - This is being worked on for this release. Mark PR fixed when changes are released. VI (11/12/2000 3:05:50 PM) AWT inside SWT and SWT inside AWT work on Windows under the JDK. AWT inside SWT works on photon. The other direction has not yet been tested. There is a problem on the Motif platform: When trying to create an MEmbeddedFrame from an SWT Handle, I get the following error. The error goes away when we use statically linked X libraries. Warning: Widget must be a VendorShell. SIGSEGV 11 (*) segmentation violation stackpointer=0xbffc1d08 Full thread dump Classic VM (J2RE 1.3.0 IBM build cx130-20000623, native threads): "Image Fetcher 0" (TID:0x402e8548, sys_thread_t:0x834ea38, state:CW, native ID:0x1c08) prio=8 at java.lang.Object.wait(Native Method) at sun.awt.image.ImageFetcher.nextImage(ImageFetcher.java:167) at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:216) at sun.awt.image.ImageFetcher.run(ImageFetcher.java:189) "AWT-Motif" (TID:0x402e8590, sys_thread_t:0x832dc28, state:CW, native ID:0x1807) prio=5 at sun.awt.motif.MToolkit.run(Native Method) at java.lang.Thread.run(Thread.java:498) "SunToolkit.PostEventQueue-0" (TID:0x402e85d8, sys_thread_t:0x8308ff8, state:CW, native ID:0x1406) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:421) at sun.awt.PostEventQueue.run(SunToolkit.java:496) "AWT-EventQueue-0" (TID:0x402e8630, sys_thread_t:0x8306fa8, state:CW, native ID:0x1005) prio=6 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:421) at java.awt.EventQueue.getNextEvent(EventQueue.java:320) at java.awt.EventDispatchThread.pumpOneEvent (EventDispatchThread.java:107) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:99) at java.awt.EventDispatchThread.run(EventDispatchThread.java:90) "Finalizer" (TID:0x402e8708, sys_thread_t:0x80d3118, state:CW, native ID:0xc04) prio=8 at java.lang.Object.wait(Native Method) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:114) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:129) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:168) "Reference Handler" (TID:0x402e8750, sys_thread_t:0x80cf4b8, state:CW, native ID:0x803) prio=10 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:421) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) "Signal dispatcher" (TID:0x402e8798, sys_thread_t:0x80cab88, state:CW, native ID:0x402) prio=5 "main" (TID:0x402e87e0, sys_thread_t:0x8050008, state:R, native ID:0x400) prio=5 at sun.awt.motif.MEmbeddedFramePeer.NEFcreate(Native Method) at sun.awt.motif.MEmbeddedFramePeer.EFcreate(MEmbeddedFramePeer.java:43) at sun.awt.motif.MComponentPeer.init(MComponentPeer.java:190) at sun.awt.motif.MWindowPeer.init(MWindowPeer.java:86) at sun.awt.motif.MFramePeer.<init>(MFramePeer.java:66) at sun.awt.motif.MEmbeddedFramePeer.<init>(MEmbeddedFramePeer.java:35) at sun.awt.motif.MToolkit.createEmbeddedFrame(MToolkit.java:213) at sun.awt.motif.MEmbeddedFrame.<init>(MEmbeddedFrame.java:38) at com.ibm.swt.awt.SWT_AWT.new_Panel(SWT_AWT.java:28) at com.ibm.swt.examples.awt.AWTAndSwingInSWT.main (AWTAndSwingInSWT.java:51) Monitor pool info: Initial monitor count: 32 Minimum number of free monitors before expansion: 5 Pool will next be expanded by: 16 Current total number of monitors: 32 Current number of free monitors: 21 Monitor Pool Dump (inflated object-monitors): sys_mon_t:0x0804f678 infl_mon_t: 0x0804f250: java.lang.ref.Reference$Lock@402F01E8/402F01F0: <unowned> Waiting to be notified: "Reference Handler" (0x80cf4b8) sys_mon_t:0x0804f6f8 infl_mon_t: 0x0804f290: java.lang.ref.ReferenceQueue$Lock@402EFE38/402EFE40: <unowned> Waiting to be notified: "Finalizer" (0x80d3118) sys_mon_t:0x0804f778 infl_mon_t: 0x0804f2d0: java.awt.EventQueue@403964C0/403964C8: <unowned> Waiting to be notified: "AWT-EventQueue-0" (0x8306fa8) sys_mon_t:0x0804f7b8 infl_mon_t: 0x0804f2f0: sun.awt.PostEventQueue@402E85D8/402E85E0: <unowned> Waiting to be notified: "SunToolkit.PostEventQueue-0" (0x8308ff8) sys_mon_t:0x0804f7f8 infl_mon_t: 0x0804f310: java.util.Vector@4039BD80/4039BD88: <unowned> Waiting to be notified: "Image Fetcher 0" (0x834ea38) sys_mon_t:0x0804f8b8 infl_mon_t: 0x00000000: java.lang.Class@402D5BD8/402D5BE0: <unowned> Waiting to be notified: "AWT-Motif" (0x832dc28) JVM System Monitor Dump (registered monitors): ACS Heap lock: <unowned> System Heap lock: <unowned> Sleep lock: <unowned> Method trace lock: <unowned> UTF8 Cache lock: <unowned> Heap lock: <unowned> Rewrite Code lock: <unowned> Monitor Cache lock: owner "main" (0x8050008) 1 entry JNI Pinning lock: <unowned> JNI Global Reference lock: <unowned> Classloader lock: <unowned> Linking class lock: <unowned> Binclass lock: <unowned> Monitor Registry lock: owner "main" (0x8050008) 1 entry Thread queue lock: owner "main" (0x8050008) 1 entry Thread identifiers (as used in flat monitors): ident 9 "Image Fetcher 0" (0x834ea38) ee 0x0834e86c ident 8 "AWT-Motif" (0x832dc28) ee 0x0832da5c ident 7 "SunToolkit.PostEventQueue-0" (0x8308ff8) ee 0x08308e2c ident 6 "AWT-EventQueue-0" (0x8306fa8) ee 0x08306ddc ident 5 "Finalizer" (0x80d3118) ee 0x080d2f4c ident 4 "Reference Handler" (0x80cf4b8) ee 0x080cf2ec ident 3 "Signal dispatcher" (0x80cab88) ee 0x080ca9bc ident 2 "main" (0x8050008) ee 0x0804fe3c Java Object Monitor Dump (flat & inflated object-monitors): java.lang.Class@402D5BD8/402D5BE0 locknflags 00020000 Flat locked by threadIdent 2. Entrycount 1 sun.awt.PostEventQueue@402E85D8/402E85E0 locknflags 80000700 Monitor inflated infl_mon 0x0804f2f0 java.lang.ref.ReferenceQueue$Lock@402EFE38/402EFE40 locknflags 80000400 Monitor inflated infl_mon 0x0804f290 java.lang.ref.Reference$Lock@402F01E8/402F01F0 locknflags 80000200 Monitor inflated infl_mon 0x0804f250 java.awt.EventQueue@403964C0/403964C8 locknflags 80000600 Monitor inflated infl_mon 0x0804f2d0 java.util.Vector@4039BD80/4039BD88 locknflags 80000800 Monitor inflated infl_mon 0x0804f310 SIGABRT 6 (*) abort process stackpointer=0xbffc19bc Full thread dump Classic VM (J2RE 1.3.0 IBM build cx130-20000623, native threads): "Image Fetcher 0" (TID:0x402e8548, sys_thread_t:0x834ea38, state:CW, native ID:0x1c08) prio=8 at java.lang.Object.wait(Native Method) at sun.awt.image.ImageFetcher.nextImage(ImageFetcher.java:167) at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:216) at sun.awt.image.ImageFetcher.run(ImageFetcher.java:189) "AWT-Motif" (TID:0x402e8590, sys_thread_t:0x832dc28, state:CW, native ID:0x1807) prio=5 at sun.awt.motif.MToolkit.run(Native Method) at java.lang.Thread.run(Thread.java:498) "SunToolkit.PostEventQueue-0" (TID:0x402e85d8, sys_thread_t:0x8308ff8, state:CW, native ID:0x1406) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:421) at sun.awt.PostEventQueue.run(SunToolkit.java:496) "AWT-EventQueue-0" (TID:0x402e8630, sys_thread_t:0x8306fa8, state:CW, native ID:0x1005) prio=6 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:421) at java.awt.EventQueue.getNextEvent(EventQueue.java:320) at java.awt.EventDispatchThread.pumpOneEvent (EventDispatchThread.java:107) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:99) at java.awt.EventDispatchThread.run(EventDispatchThread.java:90) "Finalizer" (TID:0x402e8708, sys_thread_t:0x80d3118, state:CW, native ID:0xc04) prio=8 at java.lang.Object.wait(Native Method) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:114) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:129) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:168) "Reference Handler" (TID:0x402e8750, sys_thread_t:0x80cf4b8, state:CW, native ID:0x803) prio=10 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:421) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) "Signal dispatcher" (TID:0x402e8798, sys_thread_t:0x80cab88, state:CW, native ID:0x402) prio=5 "main" (TID:0x402e87e0, sys_thread_t:0x8050008, state:R, native ID:0x400) prio=5 at sun.awt.motif.MEmbeddedFramePeer.NEFcreate(Native Method) at sun.awt.motif.MEmbeddedFramePeer.EFcreate(MEmbeddedFramePeer.java:43) at sun.awt.motif.MComponentPeer.init(MComponentPeer.java:190) at sun.awt.motif.MWindowPeer.init(MWindowPeer.java:86) at sun.awt.motif.MFramePeer.<init>(MFramePeer.java:66) at sun.awt.motif.MEmbeddedFramePeer.<init>(MEmbeddedFramePeer.java:35) at sun.awt.motif.MToolkit.createEmbeddedFrame(MToolkit.java:213) at sun.awt.motif.MEmbeddedFrame.<init>(MEmbeddedFrame.java:38) at com.ibm.swt.awt.SWT_AWT.new_Panel(SWT_AWT.java:28) at com.ibm.swt.examples.awt.AWTAndSwingInSWT.main (AWTAndSwingInSWT.java:51) Monitor pool info: Initial monitor count: 32 Minimum number of free monitors before expansion: 5 Pool will next be expanded by: 16 Current total number of monitors: 32 Current number of free monitors: 21 Monitor Pool Dump (inflated object-monitors): sys_mon_t:0x0804f678 infl_mon_t: 0x0804f250: java.lang.ref.Reference$Lock@402F01E8/402F01F0: <unowned> Waiting to be notified: "Reference Handler" (0x80cf4b8) sys_mon_t:0x0804f6f8 infl_mon_t: 0x0804f290: java.lang.ref.ReferenceQueue$Lock@402EFE38/402EFE40: <unowned> Waiting to be notified: "Finalizer" (0x80d3118) sys_mon_t:0x0804f778 infl_mon_t: 0x0804f2d0: java.awt.EventQueue@403964C0/403964C8: <unowned> Waiting to be notified: "AWT-EventQueue-0" (0x8306fa8) sys_mon_t:0x0804f7b8 infl_mon_t: 0x0804f2f0: sun.awt.PostEventQueue@402E85D8/402E85E0: <unowned> Waiting to be notified: "SunToolkit.PostEventQueue-0" (0x8308ff8) sys_mon_t:0x0804f7f8 infl_mon_t: 0x0804f310: java.util.Vector@4039BD80/4039BD88: <unowned> Waiting to be notified: "Image Fetcher 0" (0x834ea38) sys_mon_t:0x0804f8b8 infl_mon_t: 0x00000000: java.lang.Class@402D5BD8/402D5BE0: <unowned> Waiting to be notified: "AWT-Motif" (0x832dc28) JVM System Monitor Dump (registered monitors): ACS Heap lock: <unowned> System Heap lock: <unowned> Sleep lock: <unowned> Method trace lock: <unowned> UTF8 Cache lock: <unowned> Heap lock: <unowned> Rewrite Code lock: <unowned> Monitor Cache lock: owner "main" (0x8050008) 1 entry JNI Pinning lock: <unowned> JNI Global Reference lock: <unowned> Classloader lock: <unowned> Linking class lock: <unowned> Binclass lock: <unowned> Monitor Registry lock: owner "main" (0x8050008) 1 entry Thread queue lock: owner "main" (0x8050008) 1 entry Thread identifiers (as used in flat monitors): ident 9 "Image Fetcher 0" (0x834ea38) ee 0x0834e86c ident 8 "AWT-Motif" (0x832dc28) ee 0x0832da5c ident 7 "SunToolkit.PostEventQueue-0" (0x8308ff8) ee 0x08308e2c ident 6 "AWT-EventQueue-0" (0x8306fa8) ee 0x08306ddc ident 5 "Finalizer" (0x80d3118) ee 0x080d2f4c ident 4 "Reference Handler" (0x80cf4b8) ee 0x080cf2ec ident 3 "Signal dispatcher" (0x80cab88) ee 0x080ca9bc ident 2 "main" (0x8050008) ee 0x0804fe3c Java Object Monitor Dump (flat & inflated object-monitors): java.lang.Class@402D5BD8/402D5BE0 locknflags 00020000 Flat locked by threadIdent 2. Entrycount 1 sun.awt.PostEventQueue@402E85D8/402E85E0 locknflags 80000700 Monitor inflated infl_mon 0x0804f2f0 java.lang.ref.ReferenceQueue$Lock@402EFE38/402EFE40 locknflags 80000400 Monitor inflated infl_mon 0x0804f290 java.lang.ref.Reference$Lock@402F01E8/402F01F0 locknflags 80000200 Monitor inflated infl_mon 0x0804f250 java.awt.EventQueue@403964C0/403964C8 locknflags 80000600 Monitor inflated infl_mon 0x0804f2d0 java.util.Vector@4039BD80/4039BD88 locknflags 80000800 Monitor inflated infl_mon 0x0804f310 CM (3/17/01 9:23:29 PM) The PR number for this PR used to be: 1PQ8PA5 McQ (26/06/2001 9:44:56 AM) - We need to reach some kind of closure on the Swing interop story. I would like to see this working on all platforms, including the light widget focus issue. JB (28/08/2001 12:16:11 PM) On Win32, AWT/Swing interop has been substantially improved but requires fixes to the Activate mechanism that are only present in the 1.0NL code stream. On Motif we are encountering difficulties with the JDK's libawt.so library as it is statically linkd to Xm. The only workable solution is to obtain a new libawt.so that is dynamically linked to libXm (tried a number of variations on SWT's linking but it always fails while initializing Xm in SWT). Noted that AWT is quite happy with XInitThreads(). On Photon with the our AWT implementation on J9, java.awt.Toolkit contains a disabled getDefaultToolkit2() method that would permit interop. There is apparently no way to access this short of changing code or adding a foreign class. SSQ?
Will revisit after R2.0
Post 2.0. Re-opening bug reports for review.
Renamed from AWT/Swing Interop Example (1FBPKCF) because example exists and works on Windows.
Created attachment 3744 [details] Java and C code that shows the GP
I have attached example code that shows the GP. MainM, test.c and build.sh show the GP that results without using JAWT. MainM2, test2.c and build2.sh show the GP using JAWT. Obviously, the paths that are hardcoded into the shell scripts will need to be changed in order to build the shared libraries.
Running the code on Solaris works. This indicates that were AWT dynamically linked and the library made available in the JDK the GP would go away. I believe there are still locking issues. Both AWT and SWT cannot be in X/Xt/Xm at the same time. We need to determine whether the JAWT API to lock is enough to lock everyone out of X. For example, the JAWT Lock/Unlock() call requires a drawing surface. Will any drawing surface do?
There's no need any longer for the awt to be statically linked to the motif libraries, as motif has gone open source and is freely available (see http://openmotif.org). I suppose that originally, this was not the case and the lib was statically linked for legal/fiscal reasons, not technical reasons. IBM of course may be in a position to produce such a version of the JRE, it is certainly worth checking with the group that builds it to see if there remain any legal reasons necessitating a static build.
We need both Sun and IBM to ship their versions of Java on Linux linked this way.
Steve wrote: "We need both Sun and IBM to ship their versions of Java on Linux linked this way." Ultimately yes, but there's no reason waiting for Sun. There are plenty of people who would be happy to install the IBM Linux JRE, if they could get Swing support in SWT, including me. This is outside the scope of pure Java anyway and doesn't break anything in Java, so I can't image anybody being tied up by Sun _not_ to do it. I guess we now also want the similar change for OSX (or is it already dynamically linked there?). Please let me know when a test version of the IBM JRE with dynamically linked AWT is available, I'd like to test EmbeddedSwing on it before such a new JRE is released. (EmbeddedSwing being my fully working replacement for the experimental SWT_AWT). We know of course that once this is solved, full Java2D is available in SWT programs. BTW, I can confirm that this statically linked AWT is exactly what is stopping EmbeddedSwing on Linux SWT.
Adding Veronika as she will be watching this PR while I'm on vacation.
*** Bug 25683 has been marked as a duplicate of this bug. ***
Adding code for SWT_AWT on Motif and an example that uses it. NOTE: This code does not GP on Solaris but doesn't really work because it ignores locking issues.
Created attachment 4469 [details] The SWT_AWT bridge class for Motif.
Created attachment 4470 [details] AWTinSWT (hangs on Solaris, GP's on Linux)
Created attachment 4471 [details] AWTandSWT ("works" on Solaris, GP's on Linux)
Ok, the attatchments are in but there seems to be two copies of the source in each file. Whatever! Let me describe the state of the world. On Solaris, where AWT is dynamically linked, the AWTandSWT example works but the low level locking issues in SWT and AWT have not been resolved. This example runs AWT in one shell and SWT in another. On Solaris, the AWTinSWT example hangs. This example embeds AWT in SWT, the thing that would need to be done for Eclipse. On Linux, when AWT is dynamically linked, we expect that we will get the same behavior as Solaris. This mean that we can move on to the locking and hanging problems.
When I run the SWT_AWT bridge class on Solaris, it looks like Motif is sending a fake XFocusChange from the wrong thread. The event appears to be coming in on the SWT thread from the AWT thread. I hacked SWT to get rid of the thread check (this is wrong) and got farther to another hang. Also, funny things are happening with the X and Xt error handlers, depeding on the load order of the AWT or SWT .so. It seems that we will need the source for AWT in order to debug this because we are just guessing and what AWT is doing.
Created attachment 4681 [details] SWTInSWT ("works" on Motif only, tested on Linux) Embedding one SWT in another SWT within the same process is similar to embedding AWT in SWT. In the example, the "Inner SWT" is created from a handle provided by the "Outer SWT", simulating an inner AWT created from an outer SWT. This code currently works on Motif only. While SWTInSWT is hardly a comprehensive test case, it seems to work well enough and provides a good start, showing that it is possible to embed two one window in another where each window is serviced by a different event loop. NOTE: You will need the latest SWT from HEAD to run the example.
SWTInSWT tested on Solaris.
Working on a project that is using Eclipse technology as it's base. It has recently become a requirement to be able to embed Java Swing JComponets inside of eclipse views. Specifically, we need to take existing JPanels that contain other Swing JComponents and embed them in an Eclipse view. The JPanel will be the only contents of said view (i.e. we don't need to mix and match AWT, SWT and Swing compoents in the view). Could someone answer the following questions: What is the current status? Is this functionality going to make it into Eclipse 3.0 and released in June 2004? Will there be support for Windows XP and Linux GTK? Thanks for your help. Brandon Brockway brockway@us.ibm.com
> What is the current status? We have something working but largely untested on Windows. On Motif and GTK, we have something working that supports the XEmbed protocol. Should AWT implement this protocol, then we would interop with AWT/Swing as well as any other X Windows based toolkit. I encourage you to browse the Sun web site to determine whether they are planning to support XEmbed. > Is this functionality going to make it into Eclipse 3.0 and released > in June 2004? We are currently stuck on the Mac.
The interop code has been released in org.eclipse.swt.awt. The code works for Windows. For GTK and Motif, JDK 1.5 is required.
I'm going to mark this fixed. Bug 67384 covers the Mac.
*** Bug 69725 has been marked as a duplicate of this bug. ***
