Rss

Archives for : October2010

shoes[1].drop();

I’m late to the party blogging about Apple deprecating its Java for Mac OS X, with particularly good posts up from Matt Drance and Lachlan O’Dea. And I’ve already posted a lot of counterpoints on the Java Posse’s Google group (see here, here, and here). So let me lead with the latest: there’s now a petition calling on Apple to contribute its Mac Java sources to OpenJDK. This won’t work, for at least four reasons I can think of:

  • Petitions never work.
  • Apple doesn’t listen.
  • Apple is a commercial licensee of Java. The terms in their contract with Sun/Oracle almost certainly prohibit open-sourcing their Sun-derived code.
  • Even if it could be open-sourced, Apple’s code was developed for years with the assumption it was proprietary code. The company would want nothing less than an absolutely forensic code analysis to ensure there are no loopholes, stray imports or links, or anything else that a creative FSF lawyer could use to claim that Mac OS X links against the GPL’ed OpenJDK and must therefore itself be GPL’ed. Apple has nothing to earn and everything to lose by open-sourcing its JDK, so don’t hold your breath.

It’s also frustratingly typical that many of the signatories of this petition have spent the last week blogging, tweeting, podcasting, and posting that they will never buy another Apple product (and they’re gonna go tell all their friends and relations that Apple sucks now, just for good measure). Here’s the thing: companies generally try to do right by their customers. When you assert that you will never be their customer again, you remove any reason the company would have to listen to your opinion. Really, this much should be common sense, right?

Buried in all the denunciations of “control freak Steve Jobs” and his nefarious skullduggery is a wake-up call that Oracle and the Java community need to hear: one of your biggest commercial licensees, the second biggest US corporation by market cap, doesn’t think licensing Java will help them sell computers anymore. Why does nobody take this screamingly obvious hint?

I imagine part of the reason that the activists want Apple to contribute its code instead of letting it go to waste is that they’ve realized what a tall order it would be for the community to attempt a port on its own. Java is huge, and its native dependencies are terribly intractable: even the vaunted Linux community couldn’t get Blackdown Java up to snuff, and Sun came to the rescue with an official version for Linux. How likely is it that we’ll find enough people who know Java and Mac programming well enough — and who care to contribute their time — to do all this work for free? It may well be a non-starter. Landon Fuller got the headless bits of JDK 6 ported to OS X ported in a few weeks in the form of the Soy Latte project, but had to settle for an X11-based UI, and his announcement asked for help with Core Audio sound support and OS X integration in general… and I don’t believe any help ever materialized.

Aside: when volunteers aren’t enough, the next step is to get out the checkbook and call in mercenaries. I looked at javax.sound yesterday and estimated it would take me 4-6 weeks, full-time, to do a production-quailty port using Core Audio. I’ll bid the project out at $20,000. Sign a contract and I’ll contribute the sources to any project you like (OpenJDK, Harmony, whatever). You know where to reach me. And I’m not holding my breath.

The real problem with porting Java is that Java’s desktop packages – AWT, Swing, javax.sound, etc. – are very much a white elephant, one which perfectly fits Wikipedia’s definition:

A white elephant is an idiom for a valuable possession of which its owner cannot dispose and whose cost (particularly cost of upkeep) is out of proportion to its usefulness or worth.

As I’ve established, Java’s desktop packages are egregiously expensive. In fact, with Apple’s exit, it’s not clear that there’s anybody other than Oracle delivering a non-X11 AWT/Swing implementation for any platform: it’s just too much cost and not enough value. End-user Desktop Java applications are rare and get rarer every day, displaced largely by browser-based webapps, but also by Flash and native apps.

We know the big use for AWT and Swing, and it’s a terrible irony: measured by app launches or time spent in an app, the top AWT/Swing apps are surely NetBeans and IntelliJ, IDEs used for creating… other Java applications! The same can be said of the SWT toolkit, which powers the Eclipse IDE and not much else. This is what makes this white elephant so difficult to dispose of: all the value of modern-day Java is writing for the server, but nearly all the Java developers are using the desktop stuff to do so, making them the target market (and really the only market) for Desktop Java. If there were other viable Java applications on the desktop, used by everyday end-users, Apple couldn’t afford to risk going without Java. There aren’t, and it can.

There’s lots of blame to go around, not the least of which should be directed at Sun for abandoning desktop Java right after Swing 1.0 came out. It’s embarrassing that my five-year-old Swing book is more up-to-date with its technology than my year-old-iPhone book is, but it illustrates the fact that Apple has continued to evolve iOS, while Sun punted on client-side Java for years, and then compounded the problem by pushing aside the few remaining Swing developers in favor of the hare-brained JavaFX fiasco. Small wonder that nearly all the prominent desktop Java people I know are now at Google, working on Android.

Other languages are easier to port and maintain because Ruby, Python, and the like don’t try to port their own entire desktop API with them from platform to platform. Again, the irony is that this stuff is so expensive in Java, and little related to the server-side work where Java provides nearly all of its value. I’m not the first to say it, but Oracle would do itself a huge favor by finding a way to decouple all this stuff from the parts of Java that actually get used, likely as a result of Project Jigsaw. Imagine something like this:

Splitting desktop stuff out of Java SE

In this hypothetical arrangement, the desktop packages are migrated out of Java SE, which now contains the baseline contents of Java that everybody uses: collections, I/O, language utilities, etc. These are the parts that EE actually uses, and that dependency stays in place. I’ve colored those boxes green to indicate that they don’t require native widgets to be coded. What does require that is the new Java “Desktop Edition” (“Java DE”), which is SE plus AWT, Swing, Java2D, javax.sound, etc. For the rare case where you need UI stuff on the server, like image manipulation as a web service, combine EE and DE to create “Java OE”, the “Omnibus edition”. Also hanging off SE are ME (which is SE minus some features, and with a new micro UI), as well as non-Sun/Oracle products that derive from SE today, such as Eclipse’s quasi-platform, and Android. Of course, it’s easy to play armchair architect: the devil is in the details, and Mark Reinhold mentioned on Java Posse 325 that there are some grievously difficult dependencies created by the unfortunate java.beans package. Still, when the cost of the desktop packages is so high, and their value so low, they almost certainly need to be moved off the critical path of Java’s evolution somehow. The most important thing Oracle needs to provide in Java 7 or 8 is an exit strategy from desktop Java.

Instead, we’ll continue to hear about what an utter rat-bastard Steve Jobs is, and how the deprecation of Apple’s Java is part of a scheme to “force developers to use Objective-C”, as if there were a flood of useful and popular Java applications being shoved off the Mac platform. Many of the ranters insist on dredging up Jobs’ vow to “make the Mac the best Java platform”, in determined ignorance of the fact that this statement was made over ten years ago, at JavaOne 2000. For context: when Jobs was on the JavaOne stage, the US President was Bill Clinton, and Sun was #150 on the Fortune 500, ahead of Oracle and Apple (and Google, which didn’t even enter the list until 2005). If TV’s Teen Titans taught us anything, it’s that Things Change.

And for a while, maybe the Mac was briefly the best Java platform: unlike Windows (legally enjoined from shipping Java by their attempts to subvert it) and Linux (where many distros turned up their noses at un-free Java for years), Apple shipped Java as a core part of the OS for years. Not an option: it was installed as part of the system and could not practically be removed. Apple’s Mac look-and-feel for Swing was also widely praised. Do you know who said the following?

I use the MAC because it’s a great platform. One of the nice things about developing in Java on the Mac is that you get to develop on a lovely machine, but you don’t cut yourself off from deploying on other platforms. It’s a fast and easy platform to develop on. Rock solid. I never reboot my machine… Really! Opening and closing the lid on a Powerbook actually works. The machine is up and running instantly when you open it up. No viruses. Great UI. All the Java tools work here: NetBeans and JEdit are the ones I use most. I tend to think of OSX and Linux with QA and Taste.

It was Java creator James Gosling, in a 2003 blog entry. As you might imagine, Apple dumping Java seven years later has him singing a different tune.

A lot of us who’ve developed Java on the Mac have expected this for years, and this week’s reactions are all a lot of sound and fury, signifying nothing. The Java crowd will keep doing what it does — making web sites — but they’ll have to make a choice: either use Windows or Linux for development, or get away from the IDEs and write their code with plain text editors and the command line on the Mac. If I were still doing Java, I probably would barely notice, as I wrote nearly all my Java code with emacs after about 2000 or so, and never got hooked on NetBeans or Eclipse. But with the most appealing desktops and the most popular mobile devices ditching Java, it’s time for the Java community to face up to the fact that Desktop Java is a ruinously expensive legacy that they need to do something about.

All the angry screeds against Steve Jobs won’t change the fact that this is the “ball and chain” that’s pulling Java below the waves.

Slides and stuff from Voices That Matter talk

I wish I hadn’t been so crunched in the week leading up to the Voices That Matter: iPhone Developer Conference last weekend in Philadelphia, and had gotten a few of the super-advanced AV Foundation features working for demos, but since I went over my time by 10 minutes, I guess the talk was already chock ful o’ content.

Anyways, I promised materials would be on my blog after a code clean-up, and here they are:

Title: Mastering Media with AV Foundation

  • Presentation slides (PDF)
  • VTM_Player.zip – Illustrates basic playback functionality, with local and remote files and streams (included URLs include .m4a, .mov, Shoutcast, and HTTP LIve Streaming)
  • VTM_AVRecPlay.zip – Performs A/V capture from camera/mic and playback of captured movie
  • VTM_AVEditor.zip – Simple cuts-only editor for in/out editing, addition of audio track at export time.

Of user-local programming

A Detroit-area “Mobile Monday” group cross-posted an event to the Ann Arbor CocoaHeads group (which I attend regularly), and it’s interesting enough to make it worth my time to drive across the state twice this week. Which, in addition to traveling to Philadelpia for Voices That Matter: iPhone Developer Conference on Friday, is probably too damn much travel for one week.

[Aside: we really need a West Michigan CocoaHeads group…]

The event is going to feature a presentation from Ford on SYNC and the API they’re exposing to developers of third-party applications. At 360iDev, fellow AA CocoaHead Tom Hoag was on me to check out SYNC, and since we’ll probably have it on our next car, I would naturally be attracted to it anyways. Looking at the developer welcome page, they talk about planning to distribute apps through existing app stores, so whereas I originally thought a SYNC SDK might involve writing apps to run on the car’s CPU, maybe what it actually means is more of a protocol to be called via the iOS External Accessory framework. That would actually suit my needs much better: I’ve long wanted to voice-enable Road Tip, and being able to just connect to SYNC and let it do the voice recognition and speech synthesis is conceptually straightforward and would be very compelling. In fact, it would be more practical for the user to use SYNC’s driver-optimized microphone and the sound system’s speakers than to use in-built iOS speech frameworks (which aren’t yet available to third-party apps anyways).

But that’s actually beside the point I wanted to make, which is this: to sign up for the event, I had to join the Mobile Monday meetup group, the process for which posited this question: “Why are you interested in mobile.”

I answered: “I’m not.”

Specifically, I’m not interested in mobile, per se. Over the summer, I was talking with a high school friend of mine, Raman, who’s had a long and successful career at Microsoft. One of the things we found we both liked is the idea of having our code running where the user is. This isn’t mobility, exactly, because we both like desktop programming too. What we like is having our code executing on a device that’s where the user is, in direct interaction with the user, rather than on a server somewhere.

For the sake of coining a term, I’m calling this “user-local computing”.

I think this is an important turf to stake out becasue there’s been an almost smothering focus on the web and server-side programming for the last decade, that a lot of us feel like we’ve been left behind or overlooked. Sure, I can do server-side stuff — I’ve written servlets and SNMP traps and web services — but what I enjoy is the kind of application that’s interacting directly with a user, not looking up some database record that something else is going to present, or sending some HTML that’ll get rendered a second or two later and just sit there. Other people like that. Most people like that. In some camps, the server side is the default point of view, to the point of myopia (looking at you, Java community).

But not everything can be a webservice. Not everything should be.

There is a tangible difference to code that is executing in the user’s immediate presence, stuff that responds immediately to input, that manages resources locally. The web is getting closer — Google Instant Search is a remarkable user experience — but it still isn’t, and probably can never be, as responsive as work being done on the user’s own CPU.

There are also creative tasks that seem ill-suited to remote performance. It may well be possible to make a browser-based IDE, with source files stored on and executables built on a remote machine… but would it really be a good idea? Now let’s up the bandwidth: could you build a video editor in a browser, sending all your source media back and forth across a network connection? I’m sure someday it’ll be possible, probably soon, but I think it’ll be a long time before it’s actually a good idea.

In a way, this is a sort of retro outlook for those of us in our 40’s: the old paradigm of computing was based around creative tasks executed locally: Visicalc, WordPerfect, MacPaint, PageMaker. With the dictate that everything has to be network based, we’ve gotten more in a mindset of applications that collect and consume data from various network sources. And that’s great. But the idea of empowering your user to actually do stuff still matters, and while it may seem old-fashioned, a lot of what really matters involves clearing out the noise and distraction of the network and concentrating on doing something yourself. Notice how the new trend in text editors is to dispense with formatting, menus, toolbars, and all other distractions: it’s just you and your text. This is an ideal application of user-local computing: cut the crap, just let me focus on the here and now. “Here” being wherever I am, and whatever CPU happens to be handy.

So I’m interested in desktops, tablets, and iPhones not because of some high-falutin’ idealization of the power of mobile computing… I like them because they put my code where the user is, whether that’s at a desk, a couch, walking around, or driving in a car.

Beauty and the Box

Yesterday, I took my 5-year-old daughter, Quinn, to the Beauty and the Beast sing-a-long event. Quick summary: would have worked better with more people (we only had about 20, and most were shy), but helped to be in front of some theatre girls who knew the songs by heart and were into it. Still, one of my favorite movies, one I’ve surely seen 20 or 30 times. But let’s get back to digital media…

The event was meant to promote Tuesday’s re-release of Beauty and the Beast on home video, this time in its first HD edition. I’ve already owned B&tB on VHS and DVD (the 2003 edition cleverly contained the “work in progress” film circuit version, the original version, and the IMAX re-release that added an unneeded song). So I found myself wondering if I would be buying this release. Probably not, since I don’t own a Blu-Ray player and now that we’re many years into the Blu-Ray era, I don’t see that changing anytime soon. We don’t do a lot of movie watching anymore, as most of what we watch is DVR’ed off the DirecTV, and I didn’t fall for the “PlayStation 3 as Blu-Ray trojan horse” due to the PS3’s absurd unaffordability. And I don’t feel like we’ve missed it.

Then I thought: “wait, Blu-Ray isn’t the only form of HD.” There’s also on-demand from DirecTV, and what about iTunes? A little search there shows that yes indeed, the B&tB platinum edition will also be available on iTunes: $14.99 for SD, $19.99 for HD.

Of course, these Disney classics are usually only available for a short time before they “go back in the vault”, to enhance demand for the next re-release. So if I felt I did need to grab an HD version before it went away, which would I get?

Thinking about it, I think I’m more likely to buy an AppleTV — or at least rig a Mac Mini to a TV — before I get a Blu-Ray player. As it is, I could play the HD .m4p on a bunch of the devices I currently own (computers, iPhone, iPad), and the only thing that’s missing is connectivity to the TV. In fact, various video out cables allow for iOS devices to serve as a sort of “poor man’s” first-gen AppleTV, depending on your available connections, how many videos you’ve loaded on your iPod, and your tolerance for SD. A Blu-Ray disc would be locked to the TV the player is connected to, and wouldn’t be rippable for the iDevices (though this particular bundle may come with a digital copy… haven’t checked).

Still, I’m surprised to find that I’ve blundered into exactly what Steve Jobs purportedly told a customer in one of those alleged off-the-cuff e-mails: Blu-Ray is coming up short, and will eventually be replaced by digital downloads, just as CD successors were beaten by downloads (anybody spun up an SACD lately?).

BTW, Apple’s resolute anti-Blu stance is made all the more interesting by the fact that Apple is a board member of the Blu-Ray Disc Association.

Another note about the AppleTV: teardowns and other spelunking reevel that the new device runs iOS and has 8GB of storage, which would be suitable for apps, should Apple ever choose to deliver a third-party SDK. Clearly the UI would be different — perhaps it exists not as an “AppKit” or “UIKit” but rather a “TVKit” atop Foundation and the rest of the usual Apple stack — but there would be all sorts of interesting opportunities.

One of the most obvious would be for all the existing iOS streaming media apps to connect to the TV. This includes the sports apps — everyone knows about the MLB app, but look further and you’ll find apps for major events like the PGA Championship and Ryder Cup also have their own apps with live video available via in-app purchase, DirecTV’s “NFL Sunday Ticket” streams to phones, etc. There are also specialized video apps for all manner of niches. For example, as an anime fan, I use Crunchyroll’s streaming app, and might someday sign up for Anime Network Mobile. I imagine every other little video fetish has its own streaming app, or soon will.

(By the way, none of these apps can use the standard def video out cables like Apple’s iPod or Videos apps can. When you connect the composite video cable and do [UIScreen screens], you only see one screen, so these streaming apps can’t access the video out and put their player UI over there. rdar://8063058 )

By Apple fiat, essentially all of these apps need to use HTTP Live Streaming, and an AppleTV that permitted third-party apps would presumably drive even more content providers to this standard. I had previously wondered aloud about doing an HTTP Live Streaming book, but if we get an AppleTV SDK, it would make perfect sense for the HLS material to become one or two chapters of a book on AppleTV programming, along the lines of “if you’re programming for this platform, you’re almost certainly going to be streaming video to it, so here’s how the client side works, and here’s how to set up your server.”