Two years ago, I raised a few points about some of the short comings of SWT. Because of it’s native bindings, SWT makes the Java mantra of “write once, run anywhere” quite a bit more daunting. For the most part, SWT’s cross-platform support is actually quite good and it is a decent in terms of performance. And, if weren’t for SWT’s existence, we probably wouldn’t have seen Sun address Swing’s performance issues like they did in Java 6. Unfortunately, when a minority platform like OS X makes some steep architectural changes, SWT-based applications end up with more work on thier hands.
As most folks know, Java 6 on Mac OS X 10.5 was a long time coming. It took Apple over a full year after the initial release of Java 6 to get it running on Mac OS X. Now that it’s here and working pretty much “ok”, I decided it was time to start running Java 6 as my default JVM. Then the surprise: Eclipse won’t run under Java 6 on the Mac. Why? Because Java 6 under Leopard is 64-bit. The current version of SWT on OS X relies on Carbon, which is 32-bit and we won’t be seeing 64-bit Carbon anytime soon. Support for 32-bit Cocoa is planned for later next year, but I didn’t see word on when 64-bit Cocoa or even just Java 6 support might arrive.
Eclipse is still a great IDE even if I have to continue to run it under Java 5. However, this is one of those things that is annoying each time a platform needs to make significant changes. But this time, you can’t put all of the blame on the Eclipse crew. Apple did an absolutely terrible job keeping the Java community abreast of what thier plans were with Java 6. In fact, it almost seemed that Java 6 would never appear on Leaopard. Coupled with the fact that Java 6 was now going to be only 64-bit and Carbon was not goning to see 64-bit support. But long story short, SWT and therefore Eclipse is always going to be hindered by OS changes to a greater degree than say NetBeans or IDEA.