A Proposition for Apple: Port Cocoa to Java

Apple Computer is possibly in a better shape than it has been in for a long while. With the second coming of Steve Jobs and the renewed focus on innovation, Apple scrambled back from the brink to a relatively healthy company. The question is how will Apple ensure its position, if not strengthen it going forward?

The current plan put forth by Apple is to turn the Macintosh into the hub of our digital lifestyle. To that end they currently lead in quality if not sales. It’s hard to find software that is more intuitive or feature laden than iPhoto, iTunes, iMovie, GarageBand, and iDVD in their respective domains. Certainly you can manipulate photos, listen to music, and make movies and music with Windows or Linux, but you won’t find the experience nearly as rewarding.

Has this plan worked for Apple? Is iLife the new killer application? It’s hard to tell. Certainly Apple continues to show a profit, but the company’s user base is not increasing. Maybe this is because iLife isn’t a large enough pull to the platform. It could also be the cost. While an Apple made computer is not wildly more expensive than a comparable PC (especially when you factor in the iLife products are bundled with the mac), in hard economic times many consumer PC users may not be able to afford the digital cameras, iPods, and musical keyboards required to get the most out of your iLife.

Still Apple is holding its footholds in the consumer, educational, and professional markets. The question is how will Apple go forward? It’s been suggested that Apple transition into a digital electronics company, focusing on gadgets like the iPod. There’s also the long standing suggestion that Apple give up on hardware and become a software-only company. Certainly they’ve shown that they can produce some of the highest quality software in the industry, but where does that leave Apple’s also impressive hardware business? Certainly Apple has its hardcore Mac-loving audience, but what would the hardware industry been like without those fruity iMacs and sleek powerbooks?

Apple also lacks a coherent enterprise strategy. How many Macs do you see in the office? Not many. Certainly there are the Macs in the art department or on the desks of a few executives, but how many macs do you see in the cubicles? Macs are arguably easier to maintain, use, and network, but how does Apple get a foothold in business? A Mac can play well in a Windows network, but it’s not going to run the multitude of Visual Basic and Access applications that infest every office. Even though the cost of the Mac is not significantly larger than a Windows box (and could be even less given total cost of ownership), but there is a real problem with Macs when it comes to all the software you might need to use in business.

I have a suggestion for Apple that I think could improve their standing while also helping the developer community at large. I propose that Apple port its Cocoa application framework to Java. To some extent Apple has already moved in this direction. They have already ported their WebObjects platform entirely to Java. They also have a Java to Objective-C bridge that allows the creation of hybrid Cocoa-Java applications on Mac OS X. I propose a port that will allow rich clients made with Cocoa and Project Builder that would run entirely on the Java virtual machine

Porting Cocoa to Java is an Extension of Apple’s OSS Philosophy

Moving Apple’s APIs and development tool strategy would be an extension of Apple’s open source philosophy. The underpinnings of Mac OS X is a BSD derived operating system. OS X is a hybrid system that allows Apple to leverage the work of the open source community while still providing a slick, value added upper tier that makes the Mac a polished, commercial product. This works in Apple’s favor. They don’t have the monetary resources that Microsoft is pouring into the next generation of Windows, but they can alleviate some of their development cost by building off an already stable platform.

Apple can gain the same edge by leveraging the open (though not open source) Java platform. Java has a rich collection of standard and open source libraries and APIs. Apple can take advantage of this by porting their Cocoa framework to Java. They can keep the basic Cocoa design and give OS X developers the strength of the ever growing and improving Java community.

Apple can also leverage a number of open source projects just as they did with BSD. They could look piggyback off Eclipse’s SWT project for support in porting Cocoa GUI widgets to Java and other platforms. At one point OpenStep, the forerunner of Cocoa, worked on Windows as well as NeXTStep. When Apple acquired NeXT, they killed cross platform support. When you consider that Apple is a single company and it doesn’t have the resources to develop an up to date, cross platform GUI API, this makes sense. Recognizing Apple’s other projects, could we expect the company to devote resources to making its APIs current with the state of Windows, Gnome, or KDE in addition to Mac OS X? By moving the framework to Java, they could count on the community for a lot of this support.

Apple can also leverage open source projects in their development tools. Project Builder could adopt Ant for build management, XDoclet for code generation, AspectJ for aspect oriented programming, and various other projects. Apple’s Project Builder IDE already supports Ant and XDoclet for J2EE development. Why not extend that to fat clients? Considering Apple’s success in creating a slick front end over BSD and GNU development tools, imagine what they could do with open source Java tools.

Porting Cocoa to Java Solves the Java Community’s Fat Client Dilemma

Any Java developer can rattle off a list of reasons why Java is great for server side development, but that list is very short when it comes to fat clients. The current GUI API for Java applications, Swing, is lacking.

Swing applications are slow. There is debate over whether this is perceived or actual performance, but it doesn’t change the fact that most Swing apps feel sluggish compared to native applications. Furthermore, developing Swing applications is generally more complex than developing GUI applications in other frameworks.

Swing is over-designed, requiring too many objects to accomplish simple tasks. Layout is also a problem. Layout managers solve some problems but introduce many others. There is also a critical lack of WYSIWYG editors for Swing interfaces. While some of these development tools exist, developers frequently have to streamline generated code to make the application efficient and responsive.

Swing’s final problem is the look and feel. The native Swing skin, while functional, feels very different than the underlying operating system and can cause dissonance. While Swing provides skins that imitate the native system, they are often not quite right. Also, these look and feels are emulated; they don’t change as the operating system changes.

Eclipse’s Standard Widget Toolkit (from the Eclipse project) is another option for GUI Java applications. SWT applications are far more responsive than Swing applications, but SWT has its own problems.

There is a similar lack of WYSIWYG tools for SWT. Also writing GUI applications with SWT requires programming the event loop and managing memory directly; something not common among modern object oriented GUI frameworks. SWT is also a work in progress. While it is stable on some platforms (Windows for example), it is still immature on other operating systems.

Porting the Cocoa application framework to Java would benefit the entire community. It’s simpler than Swing and more encapsulated than SWT. It’s also stable and proven; the framework has been around since the NeXTStep days. Cocoa was originally designed to be cross platform. Considering it has already been ported to Windows, I bet they can make it work on the Java virtual machine. Apple’s Interface Builder is also a first class WYSIWYG tool for rapid, quality GUI development. It’s arguably better than Microsoft’s visual tools.

Java is already accepted in the server space but it is lagging far behind in the client space. The reason is because of performance and development time. It’s far too easy to throw together apps in Visual Basic and assume they will never need to run anywhere but Windows. This is big reason why businesses are chained to Windows. While increased processor performance and more memory will tame Java GUI performance, there is still a very real lack of GUI development tools and frameworks to facilitate rapid development. Apple could step in with their interface expertise and put Java GUI applications on the map. With the benefits of Cocoa, Java can be a serious GUI platform. With the ease of Apple’s development tools, Java could even be used for rapid prototyping and development.

Why should Apple devote resources to port Cocoa to Java? Obviously they recognize that Java developers and the Java language are important, otherwise they wouldn’t have created the Java-Objective-C bridge. But the bridge allows developers to leverage Java know-how to create Mac OS X only applications. Why should they port their framework and give it away to the Java community?

What’s in it for Apple?

For starters it would give Apple a foothold in the Java community. If they become the stewards of Java fat clients they would gain some influence on the evolution of the language and the platform. They can push it in ways that’s beneficial to their company and Mac OS X. As far as GUI applications go, the Java community would benefit from Apple’s input. Apple would benefit by increased visibility in the community. They would make Mac OS X and OS X Server first class platforms for Java applications.

Apple investing in Java is an investment in OS X’s future. Some say that processor speed is increasing, but we haven’t found a use for that new processing power. We have, though it’s not readily visible. We now have systems fast enough to facilitate running software on virtual machines without sacrificing the end user experience. Currently there are two competing VM platforms- .Net and Java. The Java platform is portable across a wide number of operating systems and devices, including Mac OS X. .Net runs on Microsoft platforms. While the lower level of the .Net platform has been ported to BSD and there are various open source initiatives to reimplement .Net, it is naive to assume .Net applications will run on a variety of platforms. Not only might Microsoft restrain other implementations of .Net with copyrights and lawsuits, but we should expect that the .Net APIs will become tightly coupled with the new version of Windows- Longhorn. In short, we should not expect that Microsoft will lay down its stranglehold on APIs. By making Java a viable GUI technology, Apple can ensure that the next generation of business applications and many future shrink-wrapped applications are OS X compatible.

Another boon to Apple is developer exposure. Currently a small number of developers are familiar with Cocoa. If Cocoa was ported to Java and adopted by Java developers, Apple would gain millions of developers familiar with the basics of Mac OS X development. This would have to increase interest in Apple’s platform.

Lifting up Java would increase Apple’s hardware sales. Apple is in the peculiar position of being a company that creates not only system software and applications, but also the hardware. In fact Apple’s computer business is based on hardware sales, not software sales. This is the reason why experts have predicted Apple’s eventual downfall. Apple can turn that into their saving grace.

Steve Jobs likes to say that Apple is the BMW of computer companies. It could be, but it’s currently not. Take a look at BMW, Harley Davidson, Bose, or any other company that sells stylish equipment for premium prices. All things being the equal, enough people will pay a premium for the higher quality (perceived or actual) that these companies deliver. The key point here is that all things are otherwise equal. A Harley Davidson motorcycle uses the same roads as every other bike. A Bose radio plays all the same music as any other radio. If you are looking for higher quality or a status symbol, you can pay the premium for a premium brand. When it comes to computing, all things are not equal when it comes to Mac and Windows PCs. Apple has made progress by incorporating standard PC components in their computers. They’ve also adopted or pioneered port standards like USB and Firewire. They’re even leveraging open standards and open source software that lets Macs run X Windows applications, Unix Daemons, and cohabitate with Windows PCs on networks. In spite of this, Microsoft still owns the APIs that most GUI applications depends on. Quite simply all things are not equal. There is too much software that will not run on a Mac. In the business world this is only intensified by in-house Visual Basic apps and Access databases. By making GUI Java applications widely acceptable to the most businesses, Apple removes the biggest barrier to Mac adoption. If you can run your applications anywhere, you have incredible freedom in your choice of operating systems. This changes the rules of the game and allows Apple to compete with its strengths and not its weaknesses. Apple can survive in a world of consolidation and free software by providing an intuitive and easy to use, complete system. Instead of being a niche platform, OS X will be the slickest operating system that can run the next generation of portable applications. It would be a premium platform. Freeing the industry from Microsoft dependence will allow Linux to consume business desktops on the low end and Macs to consume the high end. In short, they both win.

Finally, Apple has the potential to be the premiere Java development platform. While I’m suggesting that Apple port its Cocoa framework to Java, they don’t need to port their development tools to other platforms. If Apple gives away the APIs they can still retain their tool set. The open source community already has a wealth of Java development tools (Ant, Eclipse, NetBeans, etc.) Given a better way to create responsive and robust GUI apps, they’ll adopt it, but Apple can retain ownership of the best development tools.

I think this would increase Apple’s market share, especially in the business sector. Apple currently bundles its developer tools with each copy of OS X, and therefore each Mac. If you could buy a Mac and it came with the best business development tools out of the box, don’t you think someone would take them up on the offer? When you consider the cost of quality development tools (Microsoft and others), buying a Mac is not that great of a burden. In fact, you get actual hardware for your investment! Again, this allows Apple to compete based on their strengths. It also allows Apple to continue to develop software that might otherwise be commoditized by free solutions. After all, Apple gets its bottom line from pushing hardware not software. They can use their development tools as a way to sell computers, not software. Certainly any other vendor or open source project could create a compatible IDE or WYSIWYG designer, but Apple can bank on its software engineering and design prowess to keep them ahead of the pack.


The IT industry is very different then it was just a few years ago. Companies are cutting costs and the rise of open source software is forcing companies to find ways of giving away some of their product for free while still maintaining sales.

Apple already knows how to survive in tough markets; they’ve survived as a niche platform for over a decade. They’ve survived by building brand loyalty and offering high quality products. In order to survive in the future and to regain industry leadership in more than just industrial design, they need to act. If Apple can make Cocoa a reality for Java GUI applications, it will succeed not only in lifting up the entire industry, but Apple will secure its spot as one of the few tech companies that will survive the changing market.

About the Author:
I currently work as a system architect of J2EE applications implemented on and with open source technologies. I also dabble with OS X and Cocoa.


  1. 2004-02-17 8:41 pm
  2. 2004-02-17 8:42 pm
  3. 2004-02-17 8:44 pm
  4. 2004-02-17 8:51 pm
  5. 2004-02-17 8:53 pm
  6. 2004-02-17 8:54 pm
  7. 2004-02-17 8:56 pm
  8. 2004-02-17 9:00 pm
  9. 2004-02-17 9:08 pm
  10. 2004-02-17 9:08 pm
  11. 2004-02-17 9:13 pm
  12. 2004-02-17 9:16 pm
  13. 2004-02-17 9:23 pm
  14. 2004-02-17 9:24 pm
  15. 2004-02-17 9:25 pm
  16. 2004-02-17 9:28 pm
  17. 2004-02-17 9:35 pm
  18. 2004-02-17 9:36 pm
  19. 2004-02-17 9:41 pm
  20. 2004-02-17 9:41 pm
  21. 2004-02-17 9:45 pm
  22. 2004-02-17 9:52 pm
  23. 2004-02-17 9:56 pm
  24. 2004-02-17 10:05 pm
  25. 2004-02-17 10:22 pm
  26. 2004-02-17 10:26 pm
  27. 2004-02-17 11:00 pm
  28. 2004-02-17 11:07 pm
  29. 2004-02-17 11:14 pm
  30. 2004-02-17 11:38 pm
  31. 2004-02-17 11:51 pm
  32. 2004-02-17 11:55 pm
  33. 2004-02-17 11:57 pm
  34. 2004-02-18 12:15 am
  35. 2004-02-18 1:05 am
  36. 2004-02-18 2:39 am
  37. 2004-02-18 2:41 am
  38. 2004-02-18 2:46 am
  39. 2004-02-18 4:16 am
  40. 2004-02-18 5:47 am
  41. 2004-02-18 6:29 am
  42. 2004-02-18 6:35 am
  43. 2004-02-18 7:47 am
  44. 2004-02-18 9:29 am
  45. 2004-02-18 9:39 am
  46. 2004-02-18 10:43 am
  47. 2004-02-18 11:12 am
  48. 2004-02-18 11:22 am
  49. 2004-02-18 11:51 am
  50. 2004-02-18 12:41 pm
  51. 2004-02-18 12:43 pm
  52. 2004-02-18 2:02 pm
  53. 2004-02-18 4:28 pm
  54. 2004-02-18 5:20 pm
  55. 2004-02-18 5:39 pm
  56. 2004-02-18 6:26 pm
  57. 2004-02-18 6:36 pm
  58. 2004-02-18 7:21 pm
  59. 2004-02-18 7:27 pm
  60. 2004-02-18 7:53 pm
  61. 2004-02-18 8:45 pm
  62. 2004-02-18 9:37 pm
  63. 2004-02-18 9:44 pm
  64. 2004-02-18 10:31 pm
  65. 2004-02-18 10:47 pm
  66. 2004-02-18 11:03 pm
  67. 2004-02-18 11:17 pm
  68. 2004-02-19 3:22 am
  69. 2004-02-19 5:23 am
  70. 2004-02-19 6:54 am
  71. 2004-02-19 8:53 am
  72. 2004-02-19 3:22 pm
  73. 2004-02-21 1:19 am
  74. 2004-02-21 4:54 am
  75. 2004-02-21 5:05 am