The Sun Also Sets

Recently, a couple articles caught my attention. Triggered by news of the lack of Java on the iPhone, these articles go on to address Java’s failure on the desktop in general. Check out Duncan Davidson’s post here as well as Jens Alfke’s here. In the spirit of these articles, I’d like to tell a story, one that many have not heard and that, after all these years, should be told. It’s a story not only about what was, but about what might have been.

Years ago, I worked at a company called Lighthouse Design (I refer you here for a brief history and background). Sun bought Lighthouse in 1996. While we were officially Sun, we were somewhat separate. We enjoyed some level of autonomy and even got to stay in our own offices, avoiding a move to Sun’s campus.

It was an odd transitional time for Lighthouse. The codebase for our apps was in Objective-C and Sun was pushing Java. The notion was to possibly port the apps over to Java thus giving Sun an instant desktop suite. Yes, Sun also had OpenStep but Java was shiny, new and all the rage and besides, Sun was slowly killing OpenStep. At the time, the AWT was the only option for doing UI with Java. I don’t think I need to elaborate on why that was a problem. We developed an Openstep-like framework in Java to make porting easier and for the most part we were successful. The Lighthouse Foundation Classes (LFC) were not an exact implementation but they were close enough to make porting more of a mechanical process.

As a result of this, we became another party in the Java GUI Toolkit war. In addition to us, there was Netscape’s IFC also done by NeXT-inspired developers as well as the threat of Microsoft’s AFC. JavaSoft recognized they had to do something about this. The result: they got us and Netscape to discontinue our toolkits in favor of their upcoming project, in order to provide a common front against Microsoft. JavaSoft asked us, along Netscape and Taligent (I forget how they got tangled in this), to join them in the design and implementation what would become Swing.

It quickly became evident that the people involved from the JavaSoft side had little to no experience with OO and/or GUI programming. I realized that if these were the people in charge of implementing the GUI toolkit for a platform, then the project is going to be a mess. Various design discussions ensued with the people who didn’t have any real experience with OO programming or developing and shipping real desktop apps overriding those who did. I soon dropped out. The other LFC team members managed to stick around long enough to do some coding but over time they left as well.

In a nutshell, Sun had at least two toolkits with superior APIs that were ready to go. NIH syndrome was in full effect. Politics and territorialism won.

It’s worth mentioning that Sun is sitting on the Objective-C codebase for all of Lighthouse’s apps; another casualty of war resulting from their hubris. It’s sad how they could ignore those who were experienced (but considered “outsiders”) and how they thought they could figure out this whole desktop experience thing themselves. Sun does make great system-level software but history has shown time and time again that they do not “get it” when it comes to end users and the desktop.

One can only imagine what could have been. A Java GUI framework that was quite similar Cocoa. Or possibly a whole suite of productivity apps for OS X. I can’t say whether it would have been a success for Sun, but at least they would have been taken seriously. Sun “coulda been a contenda.” Sun had the technology and talent to become a force on the desktop and managed to squander both. The code is locked away somewhere in Sun’s vaults and most of the people have moved on to better things (some to places in the Mac sphere). The only thing they seemed to really get out of the Lighthouse deal was a CEO.

P.S. I apologize if I skimped on details concerning the death of OpenStep. If anyone from that team wants to tell that story, let me know and I’ll link to it. Likewise for the IFC team.

Update: Terrence Talbot of Karelia has put up a great writeup of the history from his perspective of being a member of the OpenStep team at Sun with some background on the IFC thrown in as well. It fills in a lot of holes and goes much more into the specific details concerning the politics at Sun. An essential read.

Category: Java 19 comments »

19 Responses to “The Sun Also Sets”

  1. Conor

    Thank you for the post, quite interesting; especially for those of us that weren’t old enough to know Lighthouse’s applications. The ironic (and sad) thing is that we haven’t learned from history. But things are getting better – hopefully.

  2. Ken Anderson

    I have thought many times about the loss to the general user community of great apps that could have been available if it weren’t for people who didn’t “get it”. The Lighthouse apps are a HUGE example (Sun never seems to capitalize on great software assets). Diagram! was awesome! For me, the loss of JavaSafe (another Sun acquistion) was a really bummer. Thank goodness Omni has fought the good fight and still makes great apps.

  3. Jesse Tayler

    Great article! Thanks for sharing.

    There were so many amazing applications on the NeXT machine, not to mention the http://WWW.app itself and the whole idea of the web!

    Stone Design is still around:

    http://stone.com/

    And so are the OmniGroup folks so there is hope for great software to have its day again!

  4. Stephane Savard

    I have used and owned all Lightouse applications. Though it was all great stuff. Diagram! Concurence, Quantrix TaskMaster.

    Still miss it!

    :-(

  5. Rudy Blazek

    Oh yes, Quantrix. Wrote HTML table export plug-in for it, with help from Scott Anguish. Great apps, all of the Lighthouse stuff…

  6. jburka

    Thanks for the story. I was in grad school when Java made it’s initial big splash, and I was busy writing my thesis on my white NEXTSTEP machine. Honestly, I would never had made it through my thesis defense if not for Diagram! and Concurrence. So…thanks for those, too!

  7. Lewis

    Couldn’t leave a note on Terrence’s page, or could’t figure out how to; but I think this URL has a shot of Constructor.

    http://archiv.tu-chemnitz.de/pub/1997/0032/ifc.html

    Course, it’s in German, so might not be that useful to some.

  8. Allen

    What would it take to buy the Lighthouse apps from Sun and port them to Mac OS X? Would it be worth the effort?

  9. cjwl

    This must have been frustrating, thanks for sharing more of the history. Java _did_ have a chance on the desktop, a lot of people from the NeXT arena were jumping all over it with significant experience and technology, IFC was a huge improvement over AWT. Jonathan S. told me at the time that I would be able to port OpenStep based code to Java easily, they (Sun/Lighthouse) had everything that was needed. I kept waiting for what he told me about to hit daylight, but as you tell and we all know, it didn’t happen.

    For a while there it seemed like Objective-C was headed for complete obscurity, odd that in some ways Sun ended up saving it by screwing up Java’s total potential.

    It is unfortunate they don’t even open source the Lighthouse apps and the apps that Lighthouse acquired, a lot of stuff there…

  10. Leo Richard Comerford

    There’s an older (and pretty bilious) account of Swing’s history out there, allegedly by an anonymous SWTeer. Would you like to comment on its accuracy?

  11. Tim

    The Archive still has the IFC 1.1 distribution, as well as Constructor:

    http://web.archive.org/web/19970615200826/http://developer.netscape.com/library/ifc/

    and a screenshot:

    http://web.archive.org/web/19970615123220/developer.netscape.com/library/ifc/constructor/screens.html

    If you download the code and copy the 3 folders under ifc11/netscape/ from the IFC distribution into constructor10b3/Constructor.applet/netscape in the Constructor distribution, then open index.html with Safari, Constructor will actually run. It also works with the Mac OS X Applet Launcher.

  12. mr_noodle

    Thanks for the responses. It’s always great to see an outpouring for Lighthouse.

    Unfortunately, getting the Lighthouse apps back is not really an option. Reasons:

    - It’s very possible the code has disappeared beyond the ken of man. Sun didn’t seem to care about it and the Lighthouse people left so it’s unclear if anyone kept it somewhere safe.
    - As noted by Terrence, a lot of the code was pre-Openstep. It would require some work. In addition, the Cocoa APIs have diverged a bit since then. Not as much an issue if the work was done when all this was fresh in people’s minds but it’s been almost 10 years.
    - I’ve heard rumors that various parties (including Apple) have tried to negotiate for the code to no avail.

    Fortunately, others have come in to fill the void.

    Diagram: OmniGraffle (Omni Group)
    Concurrence: Keynote (Apple) / OmniOutliner (Omni Group)
    TaskMaster: OmniPlan (Omni Group)
    Quantrix: no Cocoa equivalent but Pete Murray, one of the original authors, has re-written it from the ground up in Java (and it runs on OS X). Check it out at http://www.quantrix.com.

    Of course, I think it’s more than a coincidence that ex-Lighthouse people are involved with the above apps. In addition, the Omni guys had a close relationship with Lighthouse (OmniWeb on NEXTSTEP was sold by Lighthouse) and were considered kindred spirits. I even recall some Quake matches with Wil Shipley.

    If you find that somehow the OS X versions above don’t quite satisfy your itch, I recommend contacting the authors and letting them know what it is you want. The torch has been passed and a new foundation has been established. I think the best thing now is to build upon that.

    Leo: Haven’t read that before. Thanks for the link. Most of it seems to be after my time at Sun but from my perspective their angle on Swing is a bit off. It could just be the perspective of someone seeing it afterwards and from the outside who was fed different info from different people at Sun.

  13. mr_noodle

    Tim: Great links. Terrence updated his post with a screenshot. (http://talblog.info/archives/2007/01/sundown.html).

  14. Andy Lee

    Sun’s cluelessness in this story reminds me of my early experiences with Smalltalk.

    In the 90′s when Smalltalk was trying to break into the mainstream, some colleagues and I went to PARC to look at their windowing toolkit. I had high expectations, because these were the people who had invented object-oriented programming *and* GUIs. But I was flabbergasted at how crude their visual tools were. I don’t remember specific flaws. I just remember thinking it was clear these guys had never seen NextStep. All the power and elegance and *history* of Smalltalk, and that was the best they could do?

    One of my colleagues wanted to mock up a simple IB-like thing, and asked if there was any way to draw a connecting line between two windows, like IB does when you connect an outlet. They said no, it couldn’t be done. Well, my colleague sat down and showed them it *could* be done, the way NextStep did it, by making “lines” out of windows one pixel wide.

    It’s a testament to Smalltalk’s other great qualities that on balance I still loved it. NextStep and Smalltalk *both* spoiled me.

  15. Ulrich Hobelmann

    Would you care to elaborate what’s so groundbreakingly different about Cocoa vs Swing?

    The two GUI toolkits I happen to know are Swing and Cocoa, and I wouldn’t say they’re fundamentally different. Both are MVC, both have GUI builders (Apple IB, NetBeans Matisse), both support object instantiation (IB, JavaBeans). Maybe the only real difference is that in Swing, a menubar is always part of a window (conceptually; I know about the Apple hack that puts in its real place).

    Well, no key-value coding or bindings for Swing (so far), but that’s not really a killer for me.

  16. Jim deVos

    Ulrich has some good points. Could you be identify some of the key areas where Swing differs from Cocoa? I’m not trying to come off as cynical — I’m relatively ignorant of both frameworks and I’d geniunely like to know.

    Every programmer I know has a story of a superior idea losing out to an inferior idea. You see it all over the place. CP/M losing to DOS, OS/2 losing to Windows, Objective C losing to C++, Smalltalk losing to Java, you name it.

    However, the thrust of all of these stories always boils down to “life is so unfair” or “things were better back then”. I think this is a bitter oversimplification. The truth is that ideas don’t thrive on their brilliance alone. And it’s a cop out to say that an idea is “before it’s time” or that people “just don’t get it”.

    Even good ideas need to be sold. It’s ironic that programmers think that marketing is worthless. Most of these sob-stories are testaments to the value of marketing.

  17. mr_noodle

    Hi, thanks for the responses. I’ve been a bit busy so sorry if I’m a bit late with this.

    Jim: I appreciate your points though I think you are reading a bit too much into my motivations. I’m not really sulking about the loss (I had time enough back then to do so) so much as trying to show some of the factors which led to Sun’s failure on the desktop and that much of that was in their control. I’m not sure where you are going with your marketing point. This was internal politics and it didn’t matter how it was marketed. The mere fact that it was not their (JavaSoft’s) idea cemented the decision. The main thing I am lamenting now is that my Sun stock is still stuck in single digits.

    And things are much better now. These better ideas still exist and have been expanded upon in the Cocoa frameworks which I have been happily using since Apple revived them by buying NeXT. I think the quality of the apps built on the respective frameworks tells a lot of the story.

    Also, I don’t hate Java (not that you implied that at all; just trying to head off any such notions). I have been coding servers in Java for quite a number of years and Objective-C could learn a few things from Java on the language level. I just feel that the frameworks leave much to be desired when it comes to GUIs.

    Ulrich: There are significant differences in how they operate. They are not items that appear on a check list. Hopefully, we can go beyond the notion that having the same list of features somehow makes them equivalent. Execution is everything. Also, read Jens Alfke’s article (it is linked up top).

    A quick example of how they fundamentally differ: Sun avoids dynamism. Though it can be achieved via reflection in Java, they avoid it at all costs. One of the areas where this becomes apparent is the huge class bloat when using Java. You end up coding tons of “glue” classes just to connect objects since you are stuck with a very specific method signature/interface. Inner/anonymous classes make it a tad more palatable but it’s still tedious. A whole class just to have one method call another method on another object. To me, that sounds like a workaround for a bad decision. Compare that to the use of selectors (method pointers for those that don’t know Objective-C) and you can see how cumbersome the Swing way is.

    Frameworks and APIs should not just be ways to access functionality. “Adequate” is not enough. The framework should inspire, encourage the good things and discourage the bad. It should allow you to express what you want to program and not get in the way. If all that matters to you is whether it has the widgets you want and has the requisite tools, then there’s probably little I can say that will sway you.

  18. rankin

    How difficult is it to port a fully function os2 application to osx / cocoa?

  19. bitoolean

    OK this article is old and maybe I don’t know my place (or my place is not here) but this article definitely made me become more interested in Objective-C (I’ve always hated C++ simply for being an ugly language requiring one to be too specific and repeat, say, class names when defining and assigning simple variables, for example) and even less interested in Java. I’ve been doing .NET development as a hobby ever since it appeared and it just seems nicer to code for it than for Java (again, less, smarter coding). I know this probably seems out of place, but thanks.


Leave a Reply



Back to top