Latest @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
Java, the OLPC, and community responsibility
The "One Laptop Per Child" project has a great device ready to ship, but there's no Java on there. Let's think about working together to put Java on OLPC!
Equinox, Mac OS X and Swing -- an unhappy combination
At 5:50 PM on Apr 13, 2007, Alex Blewitt
wrote:
Bug 181698 is tracking this issue, and it's related to this tech note on the Apple website. The basic problem is that the GUI/Carbon event thread needs to be on the first thread created in the process, and if the JVM is created on this thread then the GUI/Carbon event thread can't run.
This isn't an issue if you launch with the java command line option (e.g.
java -jar equinox.jar) -- it's only if the JNI process 'eclipse' is used as the launcher.Still, this is unlikely to affect most people, since they're working with Eclipse/RCP which uses SWT most of the time. It may be the case that for 3.3, there will be an extra flag on the command line for the native launcher to fire up either a second JVM or process to solve the problem; but if you're interested in the resolution, then add yourself to the bug.
PS It is possible to use OSGi with Swing, if you want to. Neil and I put together a demo using Swing and OSGi with Knopflerfish to show how you can build dynamic Swing applications. You can even listen to me via the screencasts that we did of the demos
14 replies so far (
Post your own)
Re: Equinox, Mac OS X and Swing -- an unhappy combination
> Mac OS X has always been problematic when it comes to> SWT, owing to the way that the Mac handles GUI
Not to be pedantic, but I'd have to reverse that.
So long as you stick to Java, OS X is just as compatible as platform Y. It's only when you try SWT that things go awry. Enjoy SWT as much as I do, in the Java sphere, it is the minority and frankly violates the java "write once, blah, blah, blah" spirit.
My biggest issue with this bug (the reason I submitted it in the first place) was because launching an OSGi runtime from within PDE will not work with Swing (and no errors are ever displayed - a wonderfully silent mystery).
While the commandline launching does work - by default on the Mac, JNI is always used. Although, I do concede that from an aesthetic and user perspective the old launching behavior was heinous. Better to let the developer struggle to figure out what's going on than the user.
I'm just pleased that this bug got such quick attention, unlike some others that plague the Mac. Knowing there is a solution makes waiting for the next milestone that much easier.
Re: Equinox, Mac OS X and Swing -- an unhappy combination
> > Mac OS X has always been problematic when it comes to> > SWT, owing to the way that the Mac handles GUI
>
> Not to be pedantic, but I'd have to reverse that.
>
> So long as you stick to Java, OS X is just as compatible as platform Y.
> It's only when you try SWT that things go awry. Enjoy SWT as much as I do,
> in the Java sphere, it is the minority and frankly violates the java
> "write once, blah, blah, blah" spirit.
I meant the other issues in the past, like the uber popular SWT_AWT bridge etc.
The problem is that Mac OS X works in a subtly different way when it comes to event handling than other systems. The event-handling thread must be on thread 0 of the process, and there can only be one of them
It also doesn't help that SWT uses (the older, more deprecated) Carbon, whilst the AWT launcher that Apple's JVM uses is based on Cocoa. In fact, IIRC there are hooks that would allow other event threads to co-exist if SWT were Cocoa-based, since the Cocoa event thread could then farm the events out to either of the SWT/AWT threads. (This is mere speculation; SWT isn't a Cocoa app, and is unlikely to be for some time.)
Having said that, I do agree that the Mac is a good developer platform for both Java, and indeed, many other languages. I've been developing on it from the time before it was Mac OS X. And it's also worth noting that when launched with a standard 'java' command, developing Swing applications is no problem; it's just a (minor) bug in the intersection of Swing|Equinox that is the problem. I largely posted this here in case anyone else is having problems with it.
BTW there's a bunch more platform-specific stuff other than SWT, you know. Have a look at the OS X specific features in the plugins/ directory. This allows Eclipse to have hooks into e.g. filesystem notification events, and other things that are just not possible in Java at this time. If EFS were adapted to allow arbitrary attributes (and not just the minor set of int flags that it currently supports) then it would be possible to browse the spotlight metadata on files, something that Java won't allow you to do.
And lastly, whether something is in the 'standard' JVM or not isn't necessarily a good/bad thing. Although having a standard feature in a JVM might be seen as a good thing, it means that you can't run it on older JVMs. Or there might be bugs in it that you can do nothing about. The fact that the JVM isn't modular doesn't help either; a fact noted by others as well as me in the past. Indeed, Apache Harmony is building a modular JVM which will allow sub-sets of the Java libraries to be used (though obviously, it's only Java-compatible if it ships all of them).
The point is, as long as there's a standard interface that you can write pure Java code for, it really should be of no relevance whether it's implemented pure Java or a mixture of Java and native code (or even fully native code). After all, there are more than enough 'native' methods in the Java libraries themselves (e.g. the bindings to OpenGL and the 'acceleration' for Java2D are enabled by native code). But as long as you write pure Java on top of those standard libraries, what's the problem?
Alex.
Re: Equinox, Mac OS X and Swing -- an unhappy combination
Anthony,It all depends on your point of view. SWT makes carbon calls on thread 0 to drive the GUI in exactly the same way that a carbon or cocoa program does. This is in accordance with the documentation for the platform and normal for C or Objective C programs. What is Java's problem?
Here it is: AWT/Swing that plays games with threads, forwarding messages back and forth from thread 0 to get GUI work done and resond to events from the user. Is this threading behavior part of the Java language?
The "violates the java write once, blah, blah, blah," comment is pure FUD. Where did you hear it?
There is another point of view which you seem to hold that says basically, "Java that comes from the platform vendor is correct, no matter what it does, by definition." There is some validity in this. Like I said, it all depends on your point of view.
Steve
Re: Equinox, Mac OS X and Swing -- an unhappy combination
Alex,Please provide a link to the cocoa calls that can save the day. I suspect the hooks about which you talk also exist in carbon and address only part of the problem.
Given that you can farm out events, who do they go to? There are events for the menu bar, which thread controls it? What about the events that are generated when the mouse is over the desktop?
There is always two side to GUI: You kick the GUI and it kicks you. In order for you to "kick the GUI" you need to execute GUI calls on the farming out thread. If you wait for the answer, you hang the application but you must wait for some calls to complete to get the result.
There are lots of interesting and hairy problems in this area, problems that the other operating system vendors have solved a long time ago. Heck, even X/Motif gets this right.
Carbon vs. cocoa doesn't enter into it ... unless I am missing something which I would love to be the case.
Steve
Re: Equinox, Mac OS X and Swing -- an unhappy combination
> get GUI work done and resond to events from the user.> Is this threading behavior part of the Java language?
Well, as a Java developer, I shouldn't have to concern myself with how the JVM interacts with the host environment. But if I load the SWT then suddenly I do.
> The "violates the java write once, blah, blah, blah,"
> comment is pure FUD. Where did you hear it?
I wouldn't go so far as to call it FUD, but I understand your point. The last thing that I want to get into is a SWT/Swing flame, the SWT bug listings are full of them. I'll finish this thought in a second..
> that says basically, "Java that comes from the
> platform vendor is correct, no matter what it does,
> by definition." There is some validity in this.
That was your inference, not my implication
Venders can screw things up as much as the next developer. However, there is a TCK for Java that every implementation has to pass (although the fine folks at Harmony might have hit a snag there ). If you pass it, you're good to go.
I have not (and will not) download the TCK - so someone will have to fill me in on this one. But if the javax.swing packages are covered in the TCK, then on the Mac, running with -XstartOnFirstThread (-X should be the first warning), would result in the failure of the TCK, and violates the write once mantra (which is, of course, more of principle than a reality).
If, on the other hand, the TCK doesn't include the javax.swing packages then my statement was indeed FUD, in so far as it specifically entails the SWT.
But that doesn't actually change the primary point.
The point was that the Equinox launcher was by default using -XstartOnFirstThread for the single purpose of supporting the SWT. This is definitely a violation of OSGi's goal of being universal middleware . Equinox, like OSGi, can rely upon any contributed libraries they want, but they probably shouldn't be forcing those dependencies on the components that are relying upon them. And definitely shouldn't be forcing those dependencies on the components if it will render them inoperable.
Now, if this were just the Eclipse launcher, hey, who cares? (other than all the folks who rely on the SWT_AWT bridge) It explicitly uses the SWT. But it's not, it's Equinox.
Again, don't get me wrong - I love contributed libraries and platform specific ones too (I'd kill for access to the Core* libraries on the mac (I miss my Cocoa-Java bridge)) - but the use of them should never prevent the use of standard Java. (although, again, since swing is in javax, pedantically my argument may have no merit - but Swing has become a defacto standard for what that may be worth).
I'm just happy it's being fixed.
Re: Equinox, Mac OS X and Swing -- an unhappy combination
The problem is that the Java application launcher (inc Swing) uses Cocoa, and whilst there are hooks in at that level, the Carbon event chain goes down a different route. The documentation on Event handling is at:http://developer.apple.com/documentation/Cocoa/Conceptual/EventOverview/index.html
Specifically, the chain showing how the events are sent differ depending on whether Carbon or Cocoa is used:
http://developer.apple.com/documentation/Cocoa/Conceptual/EventOverview/EventArchitecture/chapter_2_section_2.html
The main loop for the Cocoa NSApplication forwards events from the sendEvent: message, so if you wanted to perform your own event forwarding in an NSApplication, you'd just override this. Since the Java/Swing/AWT uses the same NSApplication to do the same processing the NSApplication's thread is always going to be thread 0.
I doubt that under the covers the code does anything significantly different, but the NSApplication offers a bunch of hooks to put in your own processing routines, and that this might help solve the problem.
Remember, Carbon was essentially only a compatibility API meant for running pre-OS X apps; Cocoa is the future of Mac OS X. (Sadly, as Anthony noted, the Java-Cocoa bridge is deprecated ... there's even a big message that comes up to tell you when you look at the Java NSApplication class ...)
http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Java/Classes/NSApplication.html
Alex.
Re: Equinox, Mac OS X and Swing -- an unhappy combination
>Well, as a Java developer, I shouldn't have to concern>myself with how the JVM interacts with the host environment.
>But if I load the SWT then suddenly I do.
This is a restatement of "Java that comes from the platform vendor is correct, by definition".
Anyone who writes native GUI code in Java on the Macintosh, has thread problems. Anyone who tries to write a JVM launcher must know whether they java code they execute invokes AWT/Swing and stay off thread 0. The C code they write is portable between Windows, Linux and other environments but not the Mac. It compiles but fails at runtime.
If you read http://developer.apple.com/technotes/tn2005/tn2147.html#TNTAG25, you'll see all sorts of thread restrictions, even for JNI code that makes cocoa calls.
SWT itself, even though it is carbon, doesn't have any of these problems. We run on the "right" (wrong?) thread to make GUI calls. Want to mix SWT and operating system calls? Go ahead, no thread issues. No wierdness.
All of this doesn't matter if by definition, whatever Java is and does on the Mac is correct.
Steve
Re: Equinox, Mac OS X and Swing -- an unhappy combination
Thanks for the links (I've been there before). The fact remains that thread 0 is still the "main event loop" in both carbon and cocoa. While it is possible to foreward events around in both toolkits and play games, the operating system support needed for multiple GUI threads is not part of either toolkit.Steve
Re: Equinox, Mac OS X and Swing -- an unhappy combination
I'm probably dreaming here ....I'd be really nice if Apple would step up support for Eclipse to provide a Cocoa version of SWT which might require changes to Cocoa. Then, provide some of the Mac specific features of XCode as Eclipse plug-ins ultimately making Eclipse their development platform
Ok, I'm done dreaming.
Bryan
Re: Equinox, Mac OS X, Swing, future toolkits: could we fix it now?
> SWT itself, even though it is carbon, doesn't have> any of these problems. We run on the "right"
> (wrong?) thread to make GUI calls. Want to mix SWT
> and operating system calls? Go ahead, no thread
> issues. No wierdness.
To have a complete picture of event dispatching threads, consider what happens in the SWTSwing port of SWT. There are 2 approaches to event dispatching: "best-effort" and "real".
The default is to have the user code controlling the UI usually in thread 0, which is incompatible with the dispatching of Swing (in thread S), hence a "best-effort" approach with synchronization mechanism.
The real approach requires a special way of launching the user code in Swing's UI thread, which is the best way to use SWTSwing but cannot be the default when a user simply switches the SWT ports.
It would be great if the user code in SWT was taken care by some SWT launching method, so it could be on thread 0, thread S, or any thread that the toolkit of the platform wants. Some switches could even be specified to alter that behavior (in case the user intends to use some AWT stuff and not SWT stuff for example).
So, would it be possible to let SWT spawn the UI thread? Something like:
Display.runSWTThread(runnable uiThreadRunnable)
Note: it would have to be the last call of the main method as this call could be synchronous or asychronous depending on the SWT implementations.
Cheers,
-Christopher
Re: Equinox, Mac OS X, Swing, future toolkits: could we fix it now?
Even if we spawned the thread, all operating system UI calls need to run on thread 0, not just the event loop.Steve
Re: Equinox, Mac OS X, Swing, future toolkits: could we fix it now?
I never said that only the loop had to be spawned, I mentioned "the user UI code", implying usually whatever goes to thread 0.Usually, users put their code in the main method and this thread at some point starts pumping. I don't see it as a big problem to change programs from:
public static void main(String[] args) { ... }to:
public static void main(final String[] args) { Display.runSWTThread(new Runnable() { public void run() { main_(); } }); } public static void main_(String[] args) { ... }And then, non-thread-0-based toolkits would be happy. Old code would still work for toolkits where thread 0 works, but the new scheme could be the official way of starting an SWT program.
-Christopher
Re: Equinox, Mac OS X, Swing, future toolkits: could we fix it now?
What I'm trying to tell you is that I this is unrelated and won't help. Making an OS call in main_() would fail exactly the same way on the Mac.Steve
Re: Equinox, Mac OS X, Swing, future toolkits: could we fix it now?
Thanks for the clarification. I understand now.On the other hand, my request still holds at least for the Swing port, and I fear that the "best-effort" dispatching approach will remain forever.
-Christopher