Forgot your password?
typodupeerror
Apple Businesses

Sun and Apple Team Up for StarOffice for Mac OS X 363

Posted by pudge
from the victory-is-within-our-grasp dept.
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.
This discussion has been archived. No new comments can be posted.

Sun and Apple Team Up for StarOffice for Mac OS X

Comments Filter:
  • by swissmonkey (535779) on Saturday July 27, 2002 @06:04AM (#3963742) Homepage
    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.
    • by znu (31198) <znu.public@gmail.com> on Saturday July 27, 2002 @06:26AM (#3963781)
      It might not be as bad as it sounds. Cocoa can be programmed from Java. They talk about Quartz, which I don't think is accessible from pure-Java apps, so that's probably what they're doing. A Java/Cocoa app is totally indistinguishable from a "fully native" app (Objective-C/Cocoa). Except that it's a bit slower and uses more RAM, of course.
      • by EccentricAnomaly (451326) on Saturday July 27, 2002 @01:19PM (#3964797) Homepage
        If they use the JAVA-Cocoa bridge, Apple can speed things up by adding functionality to Cocoa. Apple already has the basic functionality of a word processor built into the application kit (multiple fonts, spell checking, WYSYWIG printing).

        I wouldn't be suprised if OS 10.3 has a few new cocoa classes like NSWordProcessorView, NSSpreadSheetView, NSRelationalDatabase. These would be subclasses of existing Cocoa classes like NSTextView, NSTableView, and NSData.

        I think this fits Apples strategy of making development for the Mac quick and easy. This benefits them in several ways: 1) They attract more badly needed developers to their platform 2) They can churn out iApps much more quickly than M$ 4) Once developers have tasted Cocoa, they don't want to go back 5) With so much work done in the Cocoa frameworks, Apple can make the frameworks run faster and make all the apps on a system runs faster. 6) If apple changes processors, they can make it real easy to port cocoa apps to the new architecture since all of the machine dependent stuff is done in their APIs.
      • A Java/Cocoa app is totally indistinguishable from a "fully native" app (Objective-C/Cocoa).

        Exactly, so it's not cross platform. One of the things that people harp on against .NET is that the GUI lib's are native Windows code and not cross-platform. With Java/Cocoa, it's the same issue. I, for one, believe this is the way to go. Resource intensive API's should be kept native while the rest of an app runs on a virtual machine.
    • 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.
      • Actually, that's false. As computers get more powerful, the user's expectations of what the computer can do, and its speed, increases. Pure "speed" isn't too important to the majority of users; they want new functionality when they buy a new machine.
    • On my Linux installation, there are several jars in /usr/local/OpenOffice.org1.0/classes. Enabling Java to interoperate with the Universal Network Object (UNO) model that sits at the core of OpenOffice was always a key part of their architecture.

      So, the use of Java isn't really news, and any messaging around Java should just be seen as Marketing exploiting the fact that yes, indeed, parts are written in Java.
    • by g4dget (579145) on Saturday July 27, 2002 @07:15AM (#3963846)
      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?

    • 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

      But I'm betting it WILL be a native version. It will be a Cocoa app, just using Java as the programming language rather than Objective C. All the windowing, and UI widgets etc. will be Cocoa/Quartz/Aqua being invoked by a few lines of Java.

      But why use Java instead of Objective C? It may just be Sun wanting to "eat their own dog food" or simply having more programmers familiar with Java than with Objective C.

      But perhaps there is a more intriguing possiblity. Cocoa is just the upgraded OpenStep which could run as a layer on top of windows, and Solaris. It was a cross platform solution that handled all the platform specific UI (as well as a bunch of other stuff) so a simple recompile was all that was needed to get your app running on windows, NeXT, and Solaris (& maybe others?). Apple was originally going to keep things that way and add support for Java so you could build (semi)native windows/mac/solaris apps using Java & Cocoa without even a recompile. Only the Java bit is running under the JVM, the UI & all the other Cocoa stuff is native.

      This plan was 'steved' when Steve Jobs took over. That was probably the smart thing to do, they needed to focus on getting their own house in order first. But now they have everything basically ship shape on the Mac side, maybe they are revisiting the idea of Cocoa as a cross platform API. Apple and Sun working together on StarOffice seems like a perfect oppurtunity to revive the old OpenStep on windows & Solaris. Maybe I'm just being clueless, after all Sun has their own approach for Java's cross platform UI. But it doesn't seem to be that great and isn't very popular. Maybe they are considering OpenStep/Cocoa as a better solution to getting Java used on the desktop, especially if Apple has already done (almost) all the work to develop it.
    • OpenOffice _uses_ java for some things, but is not Java-based. CNet probably installed it, found that the installer looked for an instance of Java, and concluded that since it's cross-platform, it must be Java-based. It's mostly C++-based.
    • as smooth to use as a native version

      I just know I'm going to get modded flamebate, but have you used the native version? Because I have, and I'm sorry to break everyone's heart but I wouldn't describe the UI as "smooth". Certain things like right-clicking cells in Calc 6.0 is slow compared to Excel, at least on my machine it is. If anything the Star Office team should be trying everything they can to make the *native* UI "smooth".
  • I cannot imagine Java being of much use for StarOffice on OSX, given that the visual side of Java, AWT and Swing are very slow under OSX compared to Linux and XP.

    I think this is either a mistake or else they'll be using Java for some system glue or something I imagine.
    • by squiggleslash (241428) on Saturday July 27, 2002 @08:48AM (#3964013) Homepage Journal
      StarOffice wouldn't be using AWT or Swing. Apple's Java includes a version of the Cocoa API (Cocoa is the API derived from NextStep), which presumably hooks in at a fairly high level so the most intensive aspects are all in native PowerPC code within the OS itself.

      This is, IMO, a good idea. It'd be an even greater thing if GNUstep [gnustep.org] could have Java hooks too, then this fairly respected GUI API could have much wider use.

      • GNUstep has Java bindings. It's called JIGS [gnustep.it] and has been around for quite awhile. The API is extremely similar to Cocoa's Java binding; the biggest difference is the package name. Try it out and please help contribute to GNUstep if you would like to see it get wider adoption.
    • Apples page for using Cocoa with java [apple.com]
    • I cannot imagine Java being of much use for StarOffice on OSX, given that the visual side of Java, AWT and Swing are very slow under OSX compared to Linux and XP.

      Actually, MacOS X is probably the best platform for Java development [apple.com] and use [apple.com]. MacOS X has great, fast java support. I use jEdit [jedit.org] as my main gui text editor on my Mac.

      In any case, I think the article got it wrong. I doubt that the StarOffice gui would be done in Java.
  • Summary (Score:5, Informative)

    by Dr. JJJ (325391) on Saturday July 27, 2002 @06:19AM (#3963769)
    The main points of the article are:

    1) The relationship between Apple and Microsoft has been strained by the lackluster sales of Office v.X. Apple supports the porting of StarOffice because it doesn't want MacOS X to be cutoff from the ability to interact with the ever-important Microsoft dominated office file formats should Microsoft decide to abandon the platform.

    2) Development hurdles that Sun must overcome are removing and redesigning X11 protocol specific code to work with Quartz 2D -- 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.

    3) The ever-pressing issue of how to make money by selling an essentially open-source product. Sun plans to do this not by merely offering support, but also adding special enticements to a commercial distribution that wouldn't be available in an open-source distribution. (An example is the bundling of commercial quality fonts with the software).
  • by karm13 (538402) on Saturday July 27, 2002 @06:22AM (#3963774) Homepage
    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?
    • There's no money in it on either side.

      For M$, too low ROI. Two orders of magniture to low. First order is sheer sales market. There's one tenths as many machines. Second order is market resistance. Apple owners have a deep and abiding hatred for M$ that makes Linux people look tame. And they vote with their wallets. Look for universal acceptance of StarOffice as fast as Sun & Apple can ship the CD-ROMs.

      For Apple, they make hardware, they use Aqua to sell it. Giving away the crown jewels would be slitting their hardware revenue throats while M$ could drop-kick their OS sales revenues just like they did to NetScape (And fuck the DOJ.)
    • I think Apple's considering it, but they'll have to go through some steps first [slashdot.org].

      Before they introduce a version of Mac OS X to work on x86, they'll want to make sure there's a near-perfect substitute for Microsoft Office. This looks like Apple's considering contingencies. Call OpenOffice Step 3.5.
  • Java ? (Score:5, Interesting)

    by AdamInParadise (257888) on Saturday July 27, 2002 @07:00AM (#3963831) Homepage
    First I'd like to say that I like Java very much, but I think that this must be a mistake. Let's see. OS X is unix-based, and does support X11. StarOffice (and OpenOffice) runs just fine on X11. Basically their problem is to port the GUI from X11 to Quartz
    Porting StarOffice (once the biggest open source project) to Java would be an absolutly huge task. This rules out a full port. It leaves the option of using Java as the GUI. World+dog (including me) agree that Java's GUI is so-so, even if it is better on OS X than anywhere else. Anyway, what would be the point of using Java to interface between C/C++/Objective-C apps? None.

    CNET just got it wrong one more time.
    • An alternative theory might be that the port is going to rely on Java for some of the platform specific stuff. Java is well integrated into Mac OS X and OOo needs stuff like printing, file dialogs, fonts, etc. OOo already has a Java API so using Java to implement some of the platform specific stuff seems not a bad idea. This way sun can also avoid the duplicate effort of implementing platform specific stuff again since this already has been done for the Java port.

      However, I'm theorizing here. Maybe someone from Open Office could post something about this.
    • Re:Java ? (Score:5, Interesting)

      by overunderunderdone (521462) on Saturday July 27, 2002 @10:17AM (#3964230)
      World+dog (including me) agree that Java's GUI is so-so,

      Yes, but from what I understand Apple has provided hooks for Java to use all of the Cocoa API's in fact they bill Java as being coequal to Objective C for building Cocoa apps. In that case the GUI is not really java, java is just being used to invoke the native cocoa/quartz/aqua GUI. They could use Objective C instead but I would imagine that Sun would like to show off a Java app that surpasses peoples expectations (including the dog's) Also I'd imagine you can find more programmers at Sun that are proficient with Java than are proficient with Objective C.
    • While OS X is unix-based and does support X11, it doesn't do it out of the box. Half the OS X users I know are geeks who have Terminal in their dock and use fink and XDarwin. The other half are the long time mac users who are being dragged kicking and screaming into OS X and would not be able to get X11 running rootless without a lot of help. Apple never wants to leave the less technical out.

      And Java works pretty well on OS X, even if it usually breaks the human interface guidelines.
    • You seem to forget that there is already a Java version of Star Office. ...if it's not available to the masses (haven't checked in a while), it certainly does exist, as before Sun bought StarOffice, the company had a Java version, Windows, Linux, and Solaris version of Star Office 5.0.

      So if there's any *huge amount* of work required at all, it would simply be to get the Java version up to the 6.0 level, if it hasn't already been done (probably has).
    • You're implying that Mac OS X is the only platform that would benefit from a Java port.
  • by Genady (27988)
    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.
  • by oever (233119) on Saturday July 27, 2002 @07:56AM (#3963917) Homepage
    Sun has been looking for hardware allies in its long-running quest to popularize StarOffice, which competes against Microsoft Office. To date, no major PC makers have pledged to heavily promote StarOffice.

    To me, it's incredible that no hardware vendor such as IBM or HP is offering StarOffice or OpenOffice preinstalled on personal computers. I see no reason for them to not install it.
    • by squiggleslash (241428) on Saturday July 27, 2002 @08:41AM (#3963995) Homepage Journal
      The Findings of Fact in the Microsoft trial gives an answer to that. Back in 1995, IBM did ship PCs with Windows/Lotus Suite bundles, as well as OS/2 equivalents. Microsoft told IBM if they didn't stop bundling OS/2 or Lotus with their PCs they would not be licenced to offer Windows 95 IBM didn't back down until the last moment, which lead to a situation where IBM didn't even get a copy of the final version to test with their hardware until the hour before Windows 95 was released.

      Result: IBM, knowing a PC manufacturer who didn't support Win95 at that particular point in time, would sell virtually no PCs, stopped bundling both the Lotus software and OS/2 from that point on, affectively killing the commercial chances of both.

      I doubt any PC manufacturer is going to consider shipping a rival office suite for many years to come unless either they're so small they cannot expect decent treatment from MS anyway, or else the penalties levelled against Microsoft actually have some effect.

      • That was the accusation but what the actual trial transcript showed was that IBM didn't get an early license to OEM Windows 95 because an audit of their sales showed several million dollars worth of Windows licenses that they hadn't paid for or reported to Microsoft. MS insisted that IBM put a better tracking system in place so that a similar "mistake" wouldn't happen again with the Windows 95 sales.
        • Your source for this being...?

          I recall the allegations I described being reported in the papers well before they made it into Jackson's FoF, and to the best of my knowledge, Microsoft has yet to challenge any of the Findings of Fact. Their line, well after the FoF was issued, was that they agreed with Jackson's facts but not of his conclusions.

          If it's true that IBM simply failed an audit, why hasn't Microsoft challenged this critical document in the trial? And why, then, did IBM drop the practice of bundling Lotus and OS/2 at the exact time Win95 came out? One might be able to claim that OS/2 wasn't selling as well as hoped, but Lotus? What aspect of Windows 95 made Lotus's office suite unsellable and unbundle-able?

    • The Azza motherboards we get from ACS come with StarOffice CDs (only Windows is pre-installed on the PC). Not that we use the CDs, but some of the beige-box assembly houses are shipping StarOffice.
    • To me, it's incredible that no hardware vendor such as IBM or HP is offering StarOffice or OpenOffice preinstalled on personal computers. I see no reason for them to not install it.

      Actually, eMachines [e4me.com] shipped several of their eTowers with StarOffice 5.2 a couple of years ago. One of the ones we bought for the office came with it preinstalled. On the brief look I just took on their website, I see no mention of StarOffice or OpenOffice; my guess is that 5.2 didn't fly with the consumers, so they went back to the traditional MS Works...

      Just my $.02...

    • I was standing in line at Future Shop a year or two back, and the people ahead of me were buying an eMachines computer. I was surprised to see that Star Office 5.2 was bundled with the machine. I really don't keep up with what the bargain basement OEMs are bundling, but I wouldn't be surprised to find out this is still the case.
  • Errr... No.

    OpenOffice includes support for Java but it is most certainly _not_ Java based.

    Anyone who has not used OpenOffice really should take a look. IMHO is is a viable replacement to Microsoft Office at home while Star Office (based on OpenOffice) is a viable replacement for Microsoft Office at work.

    Wish good luck to the OpenOffice guys and take a bit of time to wish Sun good luck with Star Office too.

    Thanks.
  • by dankelley (573611) on Saturday July 27, 2002 @08:16AM (#3963951)
    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.
    • In my tests staroffice was much slower than office. If you're referring to 5.x, yes. With 6.0, it's a different world. On Windows, MS Office 'preloads' a lot of itself to provide the illusion of speedy launch. StarOffice on Windows does the same thing (although it gives you the option to disable the QuickStarter if you so desire, which MS Office doesn't), and is pretty much equally speedy. I honestly wish a similar daemon existed on the Solaris & Linux versions, so my users would stop whining that their workstations are 'slower' than Windows. Unless launch time is under 200 ms (human reaction time), users will select the faster product, all other things being equal. Ah, but everything isn't equal. $75 != ~$400. If you're a home user, and you get it bundled free with your Mac/PC, you'll be happy to wait an extra second or two to keep cash in your pocket (Yes, Dell bundles MS Office, no it isn't 'free', it's a $199 upgrade from the Small Business version to the Professional version, and even more if you add it to a system that didn't have it at all). Also, this article is about MacOS-X.... if MS Office X goes away, what equality is there? 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? As Microsoft changes formats, so will StarOffice update its filters for compatibility. It's a chicken-and-egg situation: Enough deployment of SO6 can shift the critical mass away from Microsoft. 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. You make $400/day? Cool. Now how about a month's salary to cover the cost of administration and deployment. Management-wise, SO6 is a dream! Don't like the default settings & behaviours? Want to customise it for mass deployment? All of SO6's preferences are in text files that can easily be edited to make your deployment exactly the way your company needs it to be, without expen$ive deployments tools (MMC, etc). See my comment above about the 'cheap (bundled)' Microsoft products. Steal them? Well... I'm sure some people at the BSA would like to talk to you! Furthermore, I'd like to see you pirate OfficeXP. You'll be amused at the dialogue box that says "Sorry, but this copy has already been activated on another computer". So, you'll have to stick with pirating Office2000 (oops, that conflicts with your compatibility-forced-upgrade scenario, above) or Office X for Macs (until Microsoft either adds anti-piracy features equivalent to Windows' activation, or discontinues it altogether.) Even then, you don't really 'own' your data if it's in their proprietary file format, which you can only get at with software that you 'licence', not 'own'. If you're not going to move to SO6, at least do yourself a favour and save copies of all of your files in PDF. At least it's an open-standard format..... For what it's worth, I've moved an entire firm of ~60 people and tens of thousands of documents to StarOffice 6 & PDF, and management is VERY happy with the productivity increase, stability, data accessibility and cost savings.
  • We all know of the "spat," as Steve Jobs called it, with the sales of Office X for Mac OS X, and the Mac Business Unit's comment alluding to "reevaluating" the future development.

    I don't feel that Microsoft would drop Office for Mac OS X because antitrust red flags (and lawsuits) would be dropping into the Federal courts, placing MS in another legal pickle.

    Apple's public support of StarOffice is actually another bow to the power of open source software (of which OpenOffice is, I know, but not StarOffice--uh..kinda?). The problem that Apple might see is that the "radical" OSS community that shuns ALL things MS would not buy or cannot afford Office X. So, for these users (as part of an incentive to pull them to OS X from other *nixes), StarOffice would be available and in a condition that works natively and well in OS X. (I'm not trying to avoid discussing AppleWorks, but it is not as robust as either Office or StarOffice.)

    And, should MS discontinue development of Office, Apple also has a strong backup productivity suite that may be less expensive.
  • by Curious__George (167596) on Saturday July 27, 2002 @09:19AM (#3964080)
    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

  • It'll be great to see Apple working on OpenOffice with Sun, if for no other reason than the fact that Apple understands clean, accessible interface design.

    Microsoft has held Office over Apple's head as a sword of Damocles for many years now, always threatening to take it away and crush the Mac market. And to make sure Apple doesn't forget that, they make Office for Mac hideously expensive, knowing that Mac users have to pay.

    Having Apple contribute to the OpenOffice project may finally give MS some real competition.
  • Can someone explain this to me? It seems that M$ /must/ make Mac software of some sort, or did the following become invalid with time?

    October 24th, 1985: John Sculley signs the worst contract Apple ever has made. He agrees that Microsoft may use some Mac GUI (Graphical User Interface) technologies if it continues producing software for the Mac (Word, Excel). If Sculley wouldn't have signed this deal Windows would have never been introduced since the similarities to the MacOS were so obvious that Apple would have easily won any lawsuits against Microsoft!

    January 1988: Microsoft releases Windows 2.0.3

    March 17th, 1988: Apple sues Microsoft and Hewlett Packard accusing them of violating copyrights of Apple on the MacOS. Windows 2.0.3 features Mac-like icons.

    (http://www.theapplemuseum.com)
  • by occam (20826) on Saturday July 27, 2002 @10:44AM (#3964304)
    When I went to WWDC this year for the first time ever, I went as a Java programmer interesting in learning how to program OS X (and Quartz GUI stuff) in Java. I was told by the "java evangelist" in no uncertain terms that I was "not Apple's target market". Java was its own platform, not to be crossplatformed to OS X and Quartz.

    WWDC did not have a single session on programming Quartz in Java. In the only mildly interesting session on Java, it was like pulling teeth to get concrete information out of the presenters in Q&A, and yet the presenters (Apple JVM guys) were incredibly arrogant about their work and how advanced it was (which in some ways it is) and how even Sun was considering incorporating their JVM innovations.

    What was boggling was Apple's Java guys didn't _get_ that they should want Java to become a first class citizen on OS X (rather than a poor stepchild to OS X's (and NeXTstep's vaunted in their eyes) objective-c. Sure, I could see the obj-c guys being protective of their baby (even though it's basically stillborn by the time its reached OS X), but why would the Java guys be so lousy sharing information on Cocoa (OS X) programming in Java.

    On the side, I got contradictory information about how to program in Cocoa using two different bridges across obj-c and java. In sum, neither really works so Apple doesn't support either really. (In particular, obj-c's reference counting doesn't mix well with Java's garbage collection.) Unfortunately, despite Apple's migration of WebObjects to Java (from obj-c), The rest of OS X and Cocoa (GUI) stayed in obj-c. Doh.

    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!

    Unfortunately, one of Apple's catchy banners did not mean what I wanted it to mean: "Come for the Java, Stay for the Cocoa". Instead of providing the means to program Cocoa in Java, the banner really means come to learn about Java on OS X (and be profoundly disappointed), and we'll (try to) lure you to objective-c every step, session, and discussion along the way.

    Cough-cough.

    Unfortunately (or fortunately), I'm an ex NeXT enthusiast, so I've already tasted obj-c (not to my liking), reasonably informed about its strengths and weaknesses, and happy with Java.

    -=-

    So, why is Apple, its head of engineering so obstinate. I assume it's because he's in love with smalltalk and obj-c caters (a la obj-c tenuous lease on life) to smalltalk, his desired language. Fair enough (but too bad for Apple and its Java shortcomings).

    But why oh why would lowly Apple Java grunts be so against first-class java support on OS X for Cocoa? That really confused the heck out of me, until I discovered that the very arrogant presenter(s) of JVM breakthroughs (yada yada yada about Apple innovations) was really the obj-c kernel team doing side work on the JVM. Doh!

    Java not obj-c. Obj-c >> Java. You know?

    There are not Java evangelists at Apple. The keepers of the Java VM are obj-c hacks. Their baby (albeit on life support) is obj-c. OUCH.

    When I figured that out, beat around the bush at the top to discover the smalltalk allegiance, and just generally got stonewalled by too many (certainly not all) of the small team of java(obj-c) insiders, I just gave up.

    Besides, the Quartz Extreme team had awesome presentations, was extremely humble despite their awesome GUI architectural innovations, and was just generally the real mccoy from an engineering point of view. My WWDC became a GUI tour rather than a deep tour of Java (as intended and paid for, as far as I was concerned).

    One final note: my impression is that Java on OS X is good --- but only for Java only apps (i.e., use Swing, not Apple's Cocoa). Their target market (as I gathered anyway) is pure Java (as opposed to Java Cocoa apps). So, if you want to port and run pure Java on OS X, they (should) love you. FYI.

    -=-

    So, it's amusing and ironic to see Apple spending any resources on Java for Cocoa now as I assume (fingers crossed) they'll do for OpenOffice after telling me that's not their target market!

    What happened to all the arrogance? Disdain? Curt political marketroid answers to basic engineering questions? Yada yada yada.

    Too painfully amusing and ironic.

    So I guess I am crossing my fingers that Apple separates the JVM team from their obj-c team, fires (or at least reassigns to obj-c only) their so-called "java evangelist", and gives java its own first-class political and technical citizenship at Apple.

    Maybe next year's WWDC can have a banner which says (and means) "Come for the Java, and Stay for the Mocha". That would be a dream worth having.

    = Joe =
    • You're impression of things could very well be entirely accurate, but what of all of Apple's online documentation [apple.com]? It certainly implies that Cocoa for Java is not only possible, but supported and encouraged. I know of a few Cocoa/Java apps that work very well - Fern [kapsi.de] (a gnutella app) for instance. What's missing to make Java a first class citizen?
    • by BlueGecko (109058) <benjamin@pollack.gmail@com> on Saturday July 27, 2002 @03:02PM (#3965089) Homepage
      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.
      • Wow, an uninformed speculative reply gets higher ranking than a first-hand report from the front line. Who's the troll? Interesting!


        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).


        Good point. Java for Cocoa is a second class citizen to pure Java, and pure Java doesn't access Cocoa. That's clear.


        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.


        Decent point for now, and an issue raised in the defense of obj-c by the Apple folk.

        Considering Java's current (long VM, libraries loading, and app) startup time and lack of shared VM images (as I understand it), Java is not totally ready for prime time for general one-use consumer apps (yet). The Apple folk did specifically mention that the startup time was a problem, so that is one of their concerns.

        However, I believe one of their innovations for OS X 10.2 Java was getting the images to share, and they have apparently shared that technique with Sun. So, I do think they have some good reasons for hedging their bets somewhat, but their overall pure Java only approach was disappointing considering their 'best platform for Java' promise. So, if you're speaking about startup time, you have a good point, but startup time is not always a showstopper (or Java wouldn't be so compelling in so many server, handheld, and high uptime applications).

        With the memory mapping features of Apple's 10.2 Java (due August 24, I believe), graphics is quite fast for general apps (and beyond) in Java and memory footprint for multiple apps should be down dramatically through VM footprint sharing (good stuff!) (but arguably still somewhat memory heavy). The rest of Java speed is a matter of taste since hotspot compiles dynamically depending on the nature of the app(s).

        So, to finish your thought. Apple does not write in Java (for their reasons), e.g., their iApps are still being written in obj-c which pretty much aligns with their treating Java as a bastard child despite Steve's promise. Steve's promise should be "best platform for pure Java" to disambiguate the situation.


        That's why Apple's VM team is so arrogant:


        Let's clarify this issue.

        Apple's VM (and Java, since they're the same) team or, more particularly, prominent members of their Obj-C/Java VM team and so-called "java evangelist" have no reason to be arrogant toward their developers. Arrogance is unprofessional, reckless, and offensive. Feel free to troll as hard as you want on this point, but they did themselves no favors with their arrogant and offensive attitudes.


        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.


        No, they've been squeezing performance for general performance.

        Contrary to your speculation, they told me that they only care about pure Java apps. That's why (according to them) they do not support Cocoa from Java. The drive for speed is to win the (pure) Java platform speed title.


        They aren't there [high performance Java Cocoa apps] yet,


        Point is: they're not even trying (according to them) to support Cocoa Java. Their answer to that question is: program in obj-c, you'll like it. (Swing and miss.)

        IOW, they're saying: pure java or bust on OS X. Java is no alternative to obj-c (c, obj-c++, etc.).


        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.


        First of all, Apple does not choose whether Java is on front line for industry. Java already is front line. Also, they don't choose the user experience by determining languages. The developers of apps choose user experience by doing well designed, quality work using the tools of their choice, including Java.

        Second, Steve chose to make the Java issue front line for OS X with his "best platform for Java" jingoism. So your comment is misleading.

        Finally, what 15% gap? The startup time gap is >> 15%, so you're not talking about that. The memory footprint gap with multiple apps is variable according to the apps running and number of copies running (and Apple fares well on that with their promised shared memory for Java), so memory footprint should not be your issue. The execution speed is variable according to the app as well --- could be faster, same or slower. There's no well recognized 15% gap known --- it's totally app dependent when using hotspot optimization versus compile-time optimization. Bottom line: who cares about performance for general apps anyway as long as its speedy enough?

        The driving value in programming languages (and environments) today is value to the customer for efficiency and effectiveness of programming (not necessarily speed of execution). Apple does not dictate whether Java is on front line. Apple determines whether Apple gives Java priority and native support.

        For native apps, Apple supports obj-c, not Java. If they choose to support Java Cocoa in the future, that would be promising. According to them publically and behind the scenes at WWDC, they do not support Java for Cocoa (contrary to your opening assertions). IOW, despite your speculation otherwise, Java and obj-c (and therefore Cocoa on OS X) are not seamlessly integrated --- according to Apple.

        Apple has two different bridges, neither of which work. They advised against using either one when pressed, and different engineers would give conflicting opinions about which one was better (i.e., neither one was feature-complete, sufficient, or robust). Take home message: run away. I.e., only pure Java gets their nod, or for Cocoa programming, use obj-c.

        -=-

        Obj-c is the VM team's baby. Java is new to OS X and doesn't even run the latest Java incarnation yet (10.2 in August should catch up most of the way).

        If Apple does work with Sun to port OpenOffice using some aspect of Java to talk OS X Cocoa, then perhaps the waters will part and, lo and behold, Java will reach the promised land (Cocoa first class citizenship). However, as long as it's obj-c uber alles (with pure java second class citizenship), OS X Cocoa is basically an obj-c or bust platform which is not particularly appetizing when more modern, compelling, and popular languages are available.

        IOW, I'll take a little Jython with my Java over obj-c anyday, and I'd like that with my OS X but it's not currently available (despite your speculative gestures).
  • Yes, you've alreadys heard the arguements that Java is bad and C++ is good. That's not what I'm concerned with.

    What I ABHOR, is dependence on external libs. Just think of the Unix world... More and more I see apps depending on external libs. That's why KDE and GNOME users are so bent on destroying the other. If I was to use all the (console) apps out there, without choosing lesser implimentations due to dependencies, I'd have perl, python, ruby, lua, netpipes and any of dozens of other interperaters, all running at once. Since I'm a little more stubborn on the subject, I'm using a computer that is several years old, and still only utilizing a tiny fraction of it's resources. But resources are secondary as well.

    Even C and C++ programs are increasingly being designed with increasing dependencies. The problem is, if any one of those libraries has even a minor change made, the program won't compile. Then, you need to find the older libary, and attempt to introduce it, without destroying all the programs compiled with the old lib.

    Just look at OpenOffice.org itself. You've got to download several large libs (which really aren't used for any other program) and compile those, as well as already having several libs, which may or may not be installed due to other programs.

    Well, I'll stop myself before this gets too long.

    Increasing dependance on external libs (such as Java) wastes memory (you're usually using a handful of fuctions of a huge lib), increase complexity, increases problems (the new version of Java was installed by another program, now StarOffice doesn't work), and is just plain and simple bad practice, and bad coding.
  • "I want Apple to bundle it. I'll give them the code. I'd love it if I could get the team at Apple to do joint development and they distribute it at no cost--that it's their product.
    So, Microsoft's product is the lone player in the market. The under-dog's product is going to be using bundling of less-popular software to compete with Microsoft.

    Well, you know one thing. Microsoft can't dare say that it's not fair for Apple to bundle software.

"Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats." -- Howard Aiken

Working...