Sun and Apple Team Up for StarOffice for Mac OS X

An anonymous reader writes, "CNET writes about Sun and Apple getting together to create StarOffice for the Mac OS X." Apparently, the Java-based OpenOffice app will be released before year's end (a developer release went out on Thursday), with a commercial StarOffice release sometime next year.

Java is NOT the way to go

[swissmonkey]

Corel already tried and we all saw the result: slow and dismissed by the market.

Even though JVMs improved a lot in the meantime, there's no way a JVM is going to make an app such as OpenOffice as smooth to use as a native version.

They'd better work on a native version, instead of working on something which has not a single chance of attracting users.

Re:Java ?!

[stu_coates]

CNet may be partially right... the article talks about Apple engineers having access to StarOffice source and working on moving the UI to Quartz... maybe just the UI work will be done in Java (which has the Quartz UI on MacOS X) with the core functionality being in C/C++ as per the other Star/Open Office platforms. Using JNI this would certainly be possible... as for performance, well, we'll have to wait and see.

preparing for the time after MS Office for Mac?

[karm13]

to me, that sounds like apple is preparing for a time when MS decides -- for valid reasons, of course -- to discontinue their office product line for the mac.
btw, any new rumors about OS X for x86 out there?

Re:Java is NOT the way to go

[lurvdrum]

You also have to remember that general computing power has incresed beyond all recognition in the last few years; by the time this software comes to fruition the performance penalty of using a language like Java (or even C#/.net for that matter) will be less noticeable.

Re:OOo already themable.

[King of the World]

I'd take it the other way... after all the themes over the years that try to ripoff OSX, not a one has got close. The proportions are wrong. The font-rendering is screwy. The software, well... black and white minstrels.

Re:Appleworks dead?

[Blondie-Wan]

I doubt it. AppleWorks is not only too good a product to discontinue (from the POV of users, which granted isn't necessarily Apple's), but also one Apple's supported for too long, and one that apparently continues to provide Apple with decent returns on its years of investment and development.

I could easily see Apple maintaining AppleWorks while simultaneously contributing to (or publishing under its own brand?) a Mac version of StarOffice/OpenOffice. Perhaps Apple could continue to bundle AppleWorks on its consumer systems while bundling StarOffice on its pro systems. Or perhaps it could license StarOffice from Sun and work with them to create its own, highly Mac-ified version and offer it as a higher-end alternative to the more consumer-oriented AppleWorks. Either of these could happen in much the same way they position iMovie and iDVD versus Final Cut Pro and DVD Studio Pro for consumers and professionals, respectively.

Java is the way to go

[g4dget]

Even though JVMs improved a lot in the meantime, there's no way a JVM is going to make an app such as OpenOffice as smooth to use as a native version.

Sure there is. Java is quite fast these days and it has gotten a lot more stable and robust. OpenOffice could actually become smaller and simpler if it is written in Java because much of the big and complex stuff in OpenOffice is already taken care of by the Java runtime.

Also, Sun finally needs to put the resources behind Java for client/desktop apps--that means developing large and complex client/desktop apps and fixing whatever problems remain in Java and the Java runtime.

Corel already tried and we all saw the result: slow and dismissed by the market.

Corel didn't know what they were doing and they didn't have the option of hacking the Java runtime much. Besides, there are an awful lot of bad or failed C and C++ applications--should we stop using C and C++ because of that as well?

The Java Connection

[Genady]

Hasn't anyone here actually played with project builder? Apple lets people develop in project builder in either ObjC, *OR* Java. I'll bet this is what they're doing. There's probably nothing happening with Swing or any of the Java UI crap. What they're probably doing is writing the underlying code in java and allowing it to compile with either the new apple front end, or swing on other platforms. This sounds much more like a Sun strategy since they're so hip on Java in the first place, and cross platform apps secondly.

compatibility, speed, cost

[dankelley]

1. In my tests staroffice was much slower than office. Unless launch time is under 200 ms (human reaction time), users will select the faster product, all other things being equal.
2. Users in an office environment will need full compatibility with office (for document sharing). How can that be accomplished, when Microsoft can change file formats at a whim, knowing that users will update like lemmings to get the new "features" provide along with the thwarting format changes?
3. Folks won't choose because of cost because cost is not a big issue. In an office environment, it makes sense to pay a day's salary (on tools), to save 10 days of work. In a home environment, people use (cheap) bundled Microsoft products or they steal them.

PS: all of the above applied to Corel, too.

Re:Hmmm.

[rikkards]

People are not that stupid.
Do I have to pull the Java version of Wordperfect out of it's grave to remind you of what people are capable of doing? :)

OS X on Intel/AMD last hurdle to World Domination

[Curious__George]

Well, "world domination" may be a bit strong, but I am completely impressed with Mac OS X and Apple. (Even more with the upcoming Jaguar release). Jobs is not just spouting sound bytes when he says that Apple plans to innovate through this recession.

Apple has had two achilles heels in the past. Number 1: Dependence upon Microsoft Office If Jobs is throwing some of the same programming talent that went into OS X onto Star Office, the result should be sensational. Apple surely has learned that it must lower it's dependency upon a Bill Gates controlled project. I'm sure they have been working on Star Office for some time.

Number 2: Dependence upon Motorola. Any company risks their entire future when they have a single point of failure and for Apple, that is Motorola. They have been limited by Motorola's ability to produce faster chips and enough of them in the past. They also lose mindshare with the "megahertz myth". I'm sure Apple by now has realized that most people don't give a damn about processor internals and pipelines. It is just going to be harder for Apple (in the mindshare department) once Intel is shipping 2 GHz processors in quantity, while Apple is just cracking 1 GHz.

Everyone knows that Darwin runs on Intel. What you don't see is how much more advanced development is going on at Apple to bring the full look and power to the Intel/AMD platform. In a Yahoo financial interview recently, Jobs played coy with the question but did not deny it.

This doesn't mean that Apple is turning it's back on the hardware business. Apple could easily make sure that it's OS X innovations became available first on it's own hardware. But an operating system that competes on traditional Windows platforms that includes great apps like iMovie, iPhoto, iDVD, iTunes, and Broadcaster (plus the new ones like iCal and iSync) for a prospective $129 must have the Microsoft honchos tossing in their sleep. Making the iPod available for Windows, is just another indication that Apple is opening up to a whole new market.

No, Windows isn't going away but now it must fight a strong competitor on two fronts: IBM/Linux and Apple/OS X. Linux shipping on Walmart computers for the average user may be a pipe dream, but do you think Walmart wouldn't love shipping Wintel platforms with OS X and saving the Windows OS fee?

I love Linux, but I encourage Linux programmers to take a good hard look at OS X (if you haven't already). Your product could run on both platforms with very little extra work. I have seen the future, and it is OS X.

Curious George

Re:Java is NOT the way to go

[MaxVlast]

Because X is an awful, old standard?

It gets the job done okay, but gosh. If you need X, XFree86 works fine. I'm quite certain that the people who either don't know what it is, or can't figure out how to install it don't really need it, and it would add a whole 'nother layer of bloat to the OS that's just not necessary for 95% of users.

And from Apple's viewpoint, putting X into OS X would be a ghastly, stupid move. Apple's best interest is served by people producing beautiful, consistent Quartz applications. If you give people an escape hatch to write cross-platform ugly-as-ass X apps, Mac OS X loses a whole lot of its sex appeal in one fell swoop. Half of the little program writers would abandon Quartz for X in a heartbeat, and the integrity of both the UI and the OS experience would go right down the toilet, and that would sink everything Apple has going for it.

Themes are only skin-deep, Quartz goes to the core

[maggard]

Apple's windowing API -- and redesigning the user interface such that it conforms to the Apple Aqua guidlines. (That's a tall order, especially considering that much of the Aqua guidlines are incomplete and still being formed.) Currently, StarOffice uses its own interface toolkit, built from the ground up.

I don't think supporting an aqua Look'nFeel would be too hard. OOo already is themable to MacOs9 look (and Windows, OS/2 and XWindows). Look at Tools->Options->OpenOffice.org->View.

Probably all it would take would be a new "theme" for the Toolkit OOo uses. Maybe they would have to extend the theming

Making something look like Aqua doesn't make it work like Aqua, or work with Quartz.

One of the beauties of the Mac OS is that there's a unform, consistant, and universal interface and scratchpad model. IBM pioneered the idea of a standard interface and Apple brought it to the GUI and applications with a vengance.

Not only do the MacOS and applications follow the same behaviors they also allow universal cut-and-paste. Anything you see that's editable on a Mac can be cut-and-pasted anywhere else that is editable and supports the medium (eg no sound-for-text.) Styled text, QuickTime multimedia, everything. This is more thoroughly plumbed then on Windows and certainly more extensive then on X and traditionial Unix applications.

It has always frustrated me when someone puts together a Theme and presents it as being the same as another OS. No. There's more to an interface then window-dressing. Another misbegotten kinda-sorta-looks-like-Aqua (but doesn't use the System Services or Quartz engine etc.) is exactly the sort of half-assed implementation Apple is selling the alternative to. Without a doubt if Apple ships an Apple/Open Office it'll be as high-gloss and thoroughly native as any of the iApps. That they've chosen Java as the platform to work from rather then Cocoa is a "Good Thing" for everyone else.

Yes Java is a completely peer layer in MacOS but it is portable and so anything Apple & Sun produce is instantly applicable to all of the other Open Office platforms (if not as nicely as the Apple implementation - think of this as payback for Apple having really committed to making Java a native portion of their OS.) This will also allow all of those other wonderful Java libraries to be leveraged in a consistant manner and become directly usable by Open Office.

Is this worthwhile for Apple? Yes. They get the only robust MS Office alternative to run suh-weet on their OS, now the best-selling Unix out there. Sun gets a partner in melding Open Office and Java, pusing their jewels out into the marketplace. The Users gets a better GUI on Open Office, one that can build on lots of other work rather then being another home-grown roll-your-own deal. They also get an infusion of all of those new MacOS X (Unix) desktops all using and supporting and developing further Open Office.

Win-Win-Win.

Re:Java is the way to go

[g4dget]

Assuming you are willing to use 2 to 4 times more memory for the Java wordprocessor equivalent and take a 50% speed hit relative to C++, it certainly could be written in Java. (Java only matches C++ speed in benchmarks where objects are not created).

It really doesn't make too much sense to compare Java and C++ in that way. For example, yes, "object creation" in Java is slower than in C++, but the two don't do the same thing.

In general, Java requires a different programming style from C++ to get efficient code. There are many habits C++ programmers acquire to keep their C++ programs from crashing and to interact well with C++'s constrained memory management. Many of those habits are meaningless and costly in Java. Java is not a "simple and safe C++", it's a very different language.

Ever try to debug a Swing problem? You often get stack traces that are more than 25 levels deep - all in Sun's Swing code. Temporary objects being created like there is no tomorrow. Any way you slice it, Swing is a horribly designed graphics toolkit.

I have had no problems with Swing--it seems like one of the better toolkits around in terms of its APIs. Its implementation is rather inefficient, but on modern hardware, it doesn't seem to matter all that much.

Re:(Good news but...) Amusing and Ironic

[BlueGecko]

I honestly think that this entire post is well-written flamebait. Here's why:

WWDC did not have a single session on programming Quartz in Java.

True, but that's due to the combination of the fact that Quartz is C-based at low-level (we're talking device drivers here) and the fact that ObjC and Java share exactly the same API at the high level, so both languages are discussed in any particular session. Part of the whole deal with Java and ObjC on OS X is that they share practically identical APIs wherever possible, meaning that once you are familiar with Cocoa, you very rarely need to worry about the documentation to see what the Java version of a particular Cocoa function call is. So, for example, to access Quartz' bezier curves, you would just do

NSBezier myBezier = NSBezier.bezierPathWithOvalInRect(new NSRect(10.0, 10.0, 50.0, 50.0));

For comparison, the Objective-C version of this exact Quartz call is

NSBezier *myBezier = [NSBezier bezierPathWithOvalInRect: NSMakeRect(10.0, 10.0, 50.0, 50.0)];

The rest of the Cocoa API is similarly exposed. Further, in practically all of the documentation, they either alternate between ObjC and Java examples, or else, show both side by side. Quartz, Cocoa, AppleScript, QuickTime, etc. are all completely supported. Interface Builder can directly generate Java Controller classes to handle UI events and can tie the GUI to those methods, and Apple is working on a version that will be able to natively handle Swing as well. What, specifically, did you find lacking?

On the side, I got contradictory information about how to program in Cocoa using two different bridges across obj-c and java.

There are exactly two Cocoa-Java bridges: Apple's and GNUstep's. Both use JNI to call out to their respective APIs. I fail to see how you could be confused about which bridge to use on which platform...

The rest of OS X and Cocoa (GUI) stayed in obj-c. Doh.

Again, all of Cocoa is available from Java. Did you want them to actually rewrite Cocoa in Java? What's your complaint here?

I even spoke with their then new head of software tools and engineering. As a smalltalk guy (skeptical of java and obj-c), he claimed that obj-c won him over. No love for Java there. Just more "not Apple's target market". It's hard to swallow paying thousands to go to a developer conference and have some pinheaded honcho tell you that despite Apple's "best platform for Java" campaign, that Java programmers are not allowed to program in Cocoa (OS X native) since Java Cocoa is not Apple's target market. What arrogance!

That's right, but for the wrong reason. Programmers at Apple aren't supposed to write in 100% Pure Java for what I hope are obvious reasons (they wouldn't take full advantage of the OS X user experience). Most (but not all) applications at Apple destined for OS X, meanwhile, are not written in Java due to the fact that users find the speed unacceptable. That's why Apple's VM team is so arrogant: specifically in order to allow Apple and others to write OS X-specific apps in Java using the Cocoa bindings without a performance penalty, Apple's been trying to squeeze every last ounce of performance they can out of the VM. They aren't there yet, and, unlike some companies, they care enough about the end-user experience to keep Java off the front line until the 15% performance gap can be closed.

Most of your post sounds essentially like you didn't read up sufficiently before going to get the most out of the conference, quite frankly. I encourage you to take another look at Java in OS X.