Eclipse on Mac Java 6 Reveals More SWT Shortcomings

/ damnhandy

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.

12 thoughts on “Eclipse on Mac Java 6 Reveals More SWT Shortcomings”

  1. @Pete
    Apple is a business, with finite resources, their own business priorities and shareholder obligations.
    They do a huge amount of Java on the serverside and, ironically, use Eclipse for WebObjects development.
    Generally speaking, IMHO Apple has a good track record for backwards compatibility. Take Universal binaries and the Rosetta runtime for example.
    They avoid obsoleting hardware: its common to be able to run major OS X releases on >=5 year old machines. I can’t say the same for Windows.

    Your point about SWT volunteers “porting a Cocoa version to a platform with less than 10% market share.” implies that there’s some special altruism involved that isn’t merited by the size of the installed-base. Yet, Linux has an order-of-magnitude less market share than OS X. What does that mean for the people who worked on SWT-GTK? They all deserve credit – but its fair to assume that the motivation they have in common is to be able to use SWT on their platform of choice: Macs are popular at IBM.

    Just as there’s nothing to stop the SWT-Cocoa volunteers from pursuing their goal, there’s nothing to stop the community from developing an open source JDK 1.6+ with support for Swing on Cocoa and for earlier OS X versions. Hence: SoyLatte and the OpenJDK BSD Port: http://openjdk.java.net/projects/bsd-port/

    Like

  2. @Pete
    Apple is a business, with finite resources, their own business priorities and shareholder obligations.
    They do a huge amount of Java on the serverside and, ironically, use Eclipse for WebObjects development.
    Generally speaking, IMHO Apple has a good track record for backwards compatibility. Take Universal binaries and the Rosetta runtime for example.
    They avoid obsoleting hardware: its common to be able to run major OS X releases on >=5 year old machines. I can’t say the same for Windows.

    Your point about SWT volunteers “porting a Cocoa version to a platform with less than 10% market share.” implies that there’s some special altruism involved that isn’t merited by the size of the installed-base. Yet, Linux has an order-of-magnitude less market share than OS X. What does that mean for the people who worked on SWT-GTK? They all deserve credit – but its fair to assume that the motivation they have in common is to be able to use SWT on their platform of choice: Macs are popular at IBM.

    Just as there’s nothing to stop the SWT-Cocoa volunteers from pursuing their goal, there’s nothing to stop the community from developing an open source JDK 1.6+ with support for Swing on Cocoa and for earlier OS X versions. Hence: SoyLatte and the OpenJDK BSD Port: http://openjdk.java.net/projects/bsd-port/

    Like

  3. @Pete, It is an issue with SWT because of it’s dependencies on native code. Granted, I agree with a lot of your points, but of you happen to have a current Mac, Java and Swing support work just peachy. X11 is a sucky solution, the reason anyone gets a Mac is because they want a UI that works 😉

    Like

  4. @Pete, It is an issue with SWT because of it’s dependencies on native code. Granted, I agree with a lot of your points, but of you happen to have a current Mac, Java and Swing support work just peachy. X11 is a sucky solution, the reason anyone gets a Mac is because they want a UI that works 😉

    Like

  5. I switched to IntelliJ about 2 years ago and never looked back. When I was occasionally using Eclipse on my Mac, I was frustrated with the clunkiness of the SWT Carbon implementation. At the time, I looked at the EOS plugin (SWT implemented in Swing). I wonder is it still usable?

    Like

  6. I switched to IntelliJ about 2 years ago and never looked back. When I was occasionally using Eclipse on my Mac, I was frustrated with the clunkiness of the SWT Carbon implementation. At the time, I looked at the EOS plugin (SWT implemented in Swing). I wonder is it still usable?

    Like

  7. Hmmm. This is a problem of SWT, how exactly?

    Blame Jobs, not the wider software community.

    Apple doesn’t update Java for non x86_64 platforms, then breaks backward compatibility by not updating Carbon. planned obsolescence. Not to mention forcing you to always buy the latest OS to run a new version of Java.

    it sounds like Apple is hostile to (a) people who run old equipment (b) people who write/use software created in Java (c) people who program in anything other than Cocoa.

    SWT volunteers (Some employed by IBM?) graciously are porting a Cocoa version to a platform with less than 10% market share.

    Meanwhile, client developers can’t use Java 6 to target as a baseline because there are still Mac users running 32 bit or ppc hardware. Depending on your industry the choice might be to abandon macs for swing or swt entirely.

    sorry Ryan but you bought a mac. Run the X11 version in virtualbox!

    Like

  8. Hmmm. This is a problem of SWT, how exactly?

    Blame Jobs, not the wider software community.

    Apple doesn’t update Java for non x86_64 platforms, then breaks backward compatibility by not updating Carbon. planned obsolescence. Not to mention forcing you to always buy the latest OS to run a new version of Java.

    it sounds like Apple is hostile to (a) people who run old equipment (b) people who write/use software created in Java (c) people who program in anything other than Cocoa.

    SWT volunteers (Some employed by IBM?) graciously are porting a Cocoa version to a platform with less than 10% market share.

    Meanwhile, client developers can’t use Java 6 to target as a baseline because there are still Mac users running 32 bit or ppc hardware. Depending on your industry the choice might be to abandon macs for swing or swt entirely.

    sorry Ryan but you bought a mac. Run the X11 version in virtualbox!

    Like

Comments are closed.