Tag Archives: leopard

Leopard, Java, and Open Source

I haven’t gotten around to upgrading to Leopard yet for several reasons, probably the most prominent of which is that Lightroom doesn’t work correctly, and I’m starting to use it a lot (more on that in a later post, perhaps). But it’s not for lack of Java 6. I’ve been following the Java on Leopard thing with bemusement, but John Gruber’s most recent post sparked a few thoughts.

Since I haven’t posted in a while, let me remind you of the context. For a while I was a Java developer, but that was another life ago, and since then, I’ve been a Python developer, and am now a manager of Java (and Javascript) developers. I’d agree with John that Java is not directly important to the Mac. No important piece of Mac software that I am aware of is written in Java, and the only important (unless you count Azureus, which Mac folks would not) client side Java apps are Java IDE’s or custom corporate applications. So it is hard to make a compelling argument that a late Java is directly bad for Macintosh sales, which Apple is surely focused on.

Nonetheless, I do think that Java, and all those Java developers (who many in the Mac community look down their nose at) are important. Their pushing for Titanium Powerbooks and MacBook Pros helped (in a lot of situations that I am directly familiar with) to improve Apple’s credibility in development shops, which helped Apple get to where it is today. I might still be using Windows if I hadn’t gone to ApacheCon 4-5 years ago and started to see the Mac’s, which were being used by my Java developing friends.

Gruber says that Java is not made to “just build” on any Unix-like OS:

Several irritated Java developers suggested that I’d feel differently if it were a developer runtime that I personally cared about — that I’d be irate if, say, Perl or Ruby or Python were dropped or degraded in Leopard. But that’s not a good comparison; Perl, Python, and Ruby pretty much compile out of the box on Mac OS X. Apple doesn’t have to do much at all — at least relative to Java — to include them on Mac OS X. Why? Because that’s how these tools are designed and engineered — they’re made to “just build” on any Unix-like OS. It’s not Apple’s responsibility that Java isn’t like that — it’s Sun’s.

Actually, I don’t think that he is correct here. When I worked at Apple, one of the projects that I worked on was a port of Java 2 to run atop the Newton operating system. I personally wrote the driver code for networking and the file system, and I can tell you from first hand experience, that Java definitely builds fine on Unix like operating systems. That’s not the problem. The problem is where OS X is not a Unix like operating system.
The places where there seem to be problems are the places where Java needs to talk to Carbon to do all that client side GUI Java stuff. I don’t think that you can claim that Carbon is part of “any Unix-like OS”.

I do think that there is something important buried in the quote from Gruber’s post. Look at the difference between the runtimes that got “kept” in Leopard. Perl, Python, and Ruby (Let’s leave aside for a moment the sad truth that hardcore Python and Ruby developers end up installing their own local runtimes). Not only were these runtimes bundled, but 2 of the 3 were actually improved – things like bridges to Cocoa, DTrace probes, and so on. What’s a critical difference between these runtimes and Java? How did all these improvements happen? Many of them were done by people outside of Apple, on a schedule that was not Apple’s, but which coincided with Apple’s. The Ruby DTrace probes were done by Joyent, the Python Objective-C bridge was done by people outside Apple. Apple pretty much just had to pick up the changes that were made. How did this happen? Those runtimes are open source, as were all the improvements that I just mentioned.

A few years ago at JavaOne, Sun took a poll of Java developers to see if open sourcing Java was important to them. If I remember right, about half those developers said no. From where I sit, it looks like an open source Java would have contributed substantially to having Java 6 ready to go for Leopard. Today, Sun has opened up the source code for Java, but a version of Java based on that opened codebase has yet to arrive. Maybe open source Java really is important after all. I guess we’ll have to wait for OS 10.6 and Java 7 to find out.

Leopard hasn’t even shipped yet, and I am already mad…

I found Leap via TUAW today. I’ve been watching Yep because I collect PDF’s like candy, and it’s just getting a little out of hand. So the idea of a “tagging Finder” sounded pretty good to me. I installed the demo and briefly played with it. It relies heavily on Spotlight for finding the files and for doing things like excluding directories — I had to exclude a bunch of files in ~/Library/Application Support, for example. My big question was whether or not Leap tapped into Spotlight facilities for storing additional metadata. Before firing off a message to the authors, I dropped into the Google Group for Leap, and a little poking around produce this message thread. Unfortunately, the upshot is that even in Leopard there is not system level support for user defined metadata on files, despite the proliferation of third party tagging solutions. I’ve avoided looking at those solutions because I was expecting to see major improvements in Spotlight in Leopard, but it looks like that is not to be.

Sometimes reading is useful…

Turns out that there is a little more technical information for us poor folks that aren’t at WWDC. So on the topics that I wanted more info on:

  • Multicore – fixes to the scheduler, including processor affinity, multithreaded networking stack, more threading in Mail.app and Spotlight, NSOperation and NSOperationQueue, and OpenMPI
  • 64 bit – 64 bit Java, MySQL and Apache.
  • DTrace / XRay – Dtrace-ified Ruby 1.8.6, Python 2.5, Java, and Perl. XRay alone would justify the $129 upgrade.

There’s also a bit of news on ZFS [via Simon Phipps].

I guess I feel better now. Now if only someone would tell me that Spotlight is no longer crawling…

WWDC keynote impressions

I have to say that I was pretty underwhelmed by the WWDC Stevenote today. Between the combination of last year’s keynote and the promise of super cool, top secret features, I was expecting a bit more than what actually took place. Let’s look at the ten features that were shown:

  1. New desktop – this is pretty, and I will appreciate a unified window look, but I’m doing just fine today. Unlike the rest of the world, apparently, I am using the plain old blue apple background, so a desktop that is friendly to my digital photographs just isn’t making me that excited, although in theory it should. Stacks the only thing that look like a new feature, and while they look cool, I’m not sure that I will use them that much.
  2. New finder – I’d like a new finder – so much so that I already use PathFinder on Tiger. The sidebar searches are nice — assuming that Spotlight actually has something like decent performance now. CoverFlow looks very pretty, but the only time that I can see using it is on collections of images or PDF’s. Looking at my Applications directory using CoverFlow isn’t really very exciting. The file sharing stuff would be good if I actually shared any file with people, but mostly we’ve been doing just fine using the existing, albeit clumsy networking.
  3. Quicklook – This is nice, and it’s nice that enabling quicklook support enables other things, like iChat Theater support. But I’d rather have working (i.e. performant) Spotlight.
  4. 64-bit – A genuine advance. Too bad it missed the window so that we could have 64 bit Photoshop
  5. Core Animation – I’m just not an eye candy guy. There wasn’t really any indication of how much effort is required to build something like the video wall that was demonstrated. Without a look at the code, it’s hard to know how impressed to be by this. It does look like Core Animation is an enabler for lots of what was shown.
  6. Boot Camp – I understand the rationale for Boot Camp, but continue to find the idea of rebooting into Windows a non starter. Give me VMWare or Parallels any day.
  7. Spaces – Virtual desktop management is so 1990’s.
  8. Dashboard – more specifically, a movie widget, and webclip. I can’t remember if we saw webclip last year, but it looked impressive. I am sure that people using Dashboard will find this a boon. Personally, I turned off all the Dashboard triggers because Dashboard is such a resource hog.
  9. iChat – It’s great that there is all the iChat eye candy. I might actually use the iChat theater features, but the big impediment to iChat is that I don’t run it. I run Adium because I need to talk to people not on AIM. Also, my experience has been that firewall tunneling for iChat doesn’t work very well, so it’s anybody’s guess as to whether video or audio chat will work on a given day. I’m basically using Skype for those features now. If Apple improved the firewall tunneling, then this might be interesting. I do give points for leveraging Quicklook to get things into iChat Theater
  10. Time Machine – well, okay, but we saw this last year.

Note that 64 bit support, Core Animation, Boot Camp, Dashboard, iChat, and Time Machine all appeared last year. That leaves the new desktop, finder and Quicklook as the Top Secret features that we’ve waited an additional year for. The things that I really want from Leopard are probably still buried in those NDA’ed sessions. I want my OS to stop leaking VM. I want XRay and ZFS. I want to know if the processor thread affinity problems have been fixed. I want garbage collected Objective-C – actually I want that one for the ISV’s. Perhaps most of all, I want Spotlight to actually be usable for me.

I”m not that excited about Safari for Windows. Since I do “Web 2.0 AJAX apps” for a living now, the last thing that I need is to add another browser/platform combination to the test matrix. It’s great that Safari is so fast on Windows, but that doesn’t really help me much. It kind of bothered me that when Steve talked about increasing Safari’s share, he overlaid the share that currently belongs to Firefox and “other” browsers. That did not make me warm and fuzzy. Nice that tabbed browsing is improving in Safari, but why couldn’t they do something slightly cooler like using stacks to organize the tabs?

As for the sweet SDKless iPhone development story? Well, it’s nice to know the whole Safari engine is in there. Basically what they said is: Hey you can write a dashboard widget that is deployed from the web. Ok. You can build some decent apps that way. I still think that a regular SDK is going to need to happen some day. In the meantime the problems that I have with iPhone remain, which means that I’m likely to end up with something like this. But that’s for another post, sometime in the future.