Ruminations on Apple

I've been an Apple user since the switch to OSX back in 2001. I previously had a NeXT box back in university called koyaanisquatsi.cam.chu.ac.uk – and yes, it had the accidental u in there – referred to as “a very expensive and very black way of checking e-mail”. Even then, the megapixel display was higher than the SVGA and XVGA common on Linux boxen at the time, and it had voice memo support which you could embed in a mail and send (aka Lip Service – see Jobs giving a demo at 3:14 at the release of NeXTSTEP 3.0:

OK, it looks dated now; but remember this was back in 1992 (check the copyrights at the end of the video if you don't believe it). At the time, Windows 3.1 had just been released and and Linux 1.0 was two years in the making from its initial 1991 release. To say it was ahead for its time seriously undermines its power at the time; the Objective-C language and NSObject hierarchy (which ultimately became Cocoa on OSX) gave it its drag-and-drop behaviour between applications. My first introduction to OO languages was in Objective-C; both Java (and Windows 95) didn't come onto the scene until 1995. And let's not forget that a NeXT box was used to create the world wide web in 1990.

Skip forward through Jobs' return and OSX, and I've been an avid Mac user since. It's not just about the build quality (though arguably the hardware is second to none) but the operating system and foundation is really a key part of the OSX experience. And as a developer platform it is great; it comes bundled with Python, Ruby, AppleScript, and has integration with document parsers, quick indexing and hardware support for a number of USB and other external devices out of the box.

In fact, when Jobs rolled out onto WWDC 2001, he said that he wanted to make OSX the best platform for Java development. And until a few years ago, that was arguably the case. There was concern during the transition of PPC to Intel with Java 6 being only available on 64-bit Intel systems but the feeling was that it was a transitional issue and a way of encouraging developers to move forwards. Unfortunately, it meant that Java developers couldn't develop against Java 6 APIs and then sell them to customers on OSX 10.5 platforms; but in reality, the Java marketplace for end-user applications has always been pretty small.

For developers, though, OSX has historically been far more popular than its market share would suggest. Go to any tech conference and the number of Macs in use are likely to be above average. Whatever language you use, Mac had it all. Many Mac developers use laptops or desktops for doing development work, even if that's on a platform-neutral runtime like Python, Ruby or Java. And although the Java language might be jaded, the JVM is used by many more languages, like Scala, Groovy and JRuby/JPython.

So Apple's departure from providing a Java runtime was a significant concern for me. OSX's server marketshare isn't likely to be significantly affected – Jobs' focus on consumers means that OSX server is never likely to get a foothold – but what it's really going to hit is developer platforms. Whatever your favourite IDE (Eclipse, NetBeans, IntelliJ), they all require a Java runtime to operate. Without an Apple-provided runtime in the future, it means that upgrading to future OSX platforms may not be worth the investment. My aging G5 needs replacement in the near future; I had been eyeing up the new Mac Pro; but the G5 will continue to work as a Java development platform whereas the next version of OSX on a Mac Pro may not.

Apple's push for continued Objective-C on the iPhone makes sense; and OSX-based GUI applications in Objective-C is also total sense as well. There's a lot of strength in the frameworks and the language, which isn't immediately obvious to those who have lived in the Java world for many years.

But the key problem is that many developers on the Mac *don't* use those languages, because their customers have no interest in OSX-only solutions. For better or worse, OSX is the only system that hosts Objective-C applications; and whilst GNUStep and and The Cocotron exist to assist in porting applications to other platforms, ironically it is Apple's own iTunes and QuickTime products that are the widely used Cocoa ported applications.

Apple has always been at the forefront of ditching technology that is past its sell-by date. It ditched floppy discs with the introduction of the iMac range; it ditched the PS/2 (and ADB) connectors for USB before it was widely used; it's started to evict hard drives and optical drives from its lightest laptops. Has Java fallen foul of this as well? Will there never again by a well-ported JVM on OSX?

It's too early to say whether Oracle can save Java; and whilst Jobs wants others to ship JVMs, it's not clear whether anyone else wants to do it, either. Apple has a great track record for integrating technology – for example, DTrace, and before it ditched it, ZFS – but when Apple abandons something, it does it in style. All of the hooks for the OSX specific behaviours (including the recently released support for fast shutdown) were things that Apple made possible. Even Swing didn't look too bad on a Mac thanks to the effort put in by Apple's Java team.

Although SoyLatte has been cited as a possible successor for OSX, the Harmony project shows that few people are interested in maintaining a Java platform. Even if Oracle does take over producing a Java version (and it's not clear why it should; it supports development tools but doesn't run Oracle on any OSX platforms), the integration with the UI is likely to be worse than it currently stands. As Scott Kovatch, former Apple engineer on the JVM platform said, All the talk about how well OpenJDK and X11 work together on the Mac is extremely depressing.

There's a small possibility that Oracle will manage an OSX port going forwards. But even if it does in the short run, I can't see it being supported in the long run. And ultimately that means that Mac OSX is transitioning from a development platform to a user-driven content platform. Perhaps it's time to dust off my Linux skills and see if it has made any significant progress in the UI space in the last couple of decades.

Apple deprecates Java

As I wrote over on InfoQ, Apple has decided to Deprecate Java on OSX, and potentially remove it (or not ship it) from future releases of OSX. The writing has long been on the wall for Java on OSX; I've already proclaimed Java dead on OSX at least once before, most notably due to the security issues present when Java is enabled in WebKit/Safari (howto disable Java in WebKit).

What does this mean for Eclipse and other Java-based IDEs? Well, one of the key problems is that the OSX implementation of Java provides a number of Cocoa-specific bindings and hooks. Whilst Eclipse is based on top of SWT, and SWT uses the native widget set directly (rather than AWT and Swing which render their own), there are a number of hooks into the Cocoa layer to provide application-level services. Some of these have been extended in the redesigned eAWT package to permit Java applications to opt into user events (including the “sudden termination” which enables faster OS shutdown).

NetBeans and IntelliJ, which rely on the AWT and Swing directly, may not be so lucky. Ports of the OpenJDK (such as SoyLatte) may use X11 instead of the native OSX windowing components; it's not clear whether Apple will donate back the OSX-specific UI code. (Earlier, when Sun was in charge, Apple were happy to donate back certain items such as the ability to load the rt.jar into shared memory for multiple JVMs to take advantage of.) Going forward, JVMs will be installed into /Library/Java/JavaVirtualMachines; though hopefully the JVM selector will still map the commands like /usr/bin/java into the selected default platform.

Either way, this is the end of an era; and, if as promised Apple don't ship a JVM with OSX 10.7, may be the beginning of the end of Eclipse on the Mac platform. If so, this would be a tragic end to an excellent journey, which led me to the Eclipse community back when it was being ported to OSX for the first time, through to helping test out the Cocoa port when it was ported again, and to now, where I am finally in an Eclipse paying job.

IBM joins OpenJDK

Charles Humble and I wrote about the press releases that IBM would be working with Oracle and the OpenJDK.

Although Harmony is an open-source project hosted at Apache, there was never much chance that they would get a testing kit to certify themselves as an open Java implementation. IBM has historically contributed a lot of work towards the project, and though it has gained other contributors it is still largely driven with IBM's hand on the wheel.

Can Harmony survive without IBM's involvement? Will Harmony keep going? As the magic 8-ball might say “Outlook not so good”. Of course, it says that about e-mail as well.

Maven 3.0 on OSX

Just a quick note for those that have installed Maven 3.0 on OSX – the JavaToolsLeopard installed Maven 2.0.9 into /usr/share/java/maven-2.0.9, and the Java for 10.6 update 2 installed MAven 2.2.0 into /usr/share/java/maven-2.2.0, with symlinks for /usr/bin/mvn into the appropriate directories. This means if you install Maven 3.0 elsewhere, running mvn will get you the stock install that comes with OSX's Java tools.

If you follow the instructions on the Apache install page, you'll get success; it says to set up the PATH such that it's ${M2}:${PATH}. However, if you set it the wrong way around (${PATH}:${M2}) but still have M2_HOME pointing to the Maven 3.0 location, then you may end up with a java.lang.NoClassDefFoundError: org/codehaus/classworlds/Launcher message.

The solution is to make sure you have the right path ordering, or remove/update the /usr/bin/mvn symlink to point to the Maven 3.0 location. It's almost certain that Apple will not update to Maven 3.0 in the 10.6 timeframe, though it may do for the 10.7 timeframe.

Happy 42 day!

Today is 42 day, and it's 10/10/10 at 10:10:10 Z (or should that be ZZ9+Zα?) Either way, whilst it's not a palindromic date, it is something that's not going to come around for ages (well, we'll have 11th November next year, I suppose).
42 is of course the meaning of life, and since 101010 is 42 then today must be the meaning of life. Well, that's the theory. As far as I can tell, it just means I have to clear up my cluttered office before lunch. Oh wait ... perhaps that is the meaning of life ...

Maven 3 released

InfoQ has published my piece on Maven 3's release at
http://www.InfoQ.com/news/2010/10/maven-30-released

LLVM 2.8 and OSGi Community Event

I wrote about the release of LLVM 2.8 over at InfoQ. I think that LLVM is coming along a long way; it's not able to replace gcc for everything yet (lesser supported testing on non-Intel platforms) and the fact that it's a pain to get binaries for various systems acts as a brake for its adoption. I do think that Eclipse CDT would be good for partnering with LLVM, but sadly LLVM is weakest on the embedded and non-Intel processor side; whereas the vendors who sponsor CDT are mostly focussed on the embedded processing side.

One of the great things about LLVM is that it's embeddable, and ships with a BSD license. So this means it would be possible to bundle it in a plugin and ship it with CDT out of the box, which would give compilation directly. That doesn't happen with CDT at the moment because of the GCC dependency (though Wascana solves that issue; if I don't mention it, Doug will). It also would be a great way of providing Objective-C support to CDT. The question is, how easily would the Eclipse parsers and the LLVM AST work together? I don't know the answer to that.

I also wrote a round-up of some of the topics on the OSGi Community Event last week; though I still have more to write in the coming week or two. For those that have been involved with Eclipse over the last few years, it covers Jim's keynote on the history behind OSGi and its adoption by Eclipse, as well as other topics. I was also glad to see Tim Ellison's talk on Harmony, which is an already fully modularised JVM, up on stage. One of the boxes on it was Pack200, which (a long time ago) I helped write some of the unpacking parts. But it's great to see a modular VM which is able to create a 10Mb runtime for Java applications that don't need cruft like AWT or Swing.

So, cue Tim or Doug commenting “we're always looking for contributions from the community” for the above suggestions. Hey, if you're interested in the intersection of LLVM, Eclipse and CDT then why not step up. I'm sure I can't be the only one ... can I?

Compiling Java Generics with 1.4 compatibility

If you're using Eclipse to compile Java code with generics, but need to maintain Java 1.4 compatibility, then there's a hidden option you can enable to compile Java 1.5 source code and produce 1.4 (version 48) bytecode.

Normally, you switch between compliance levels using the -source and -target command line switches for the Java compiler, or in Eclipse's case, by right-clicking on a project and going to the Java Compiler and changing the 'source' and '.class file compatibility' elements. However, you can't select the 1.4 generated class file compatibility (or the -target flag) with the 1.5 source (or -source flag) option, as you get an error saying that it's not a supported combination.

There is a less well known flag you can specify to the command line compiler called -target jsr14, which is equivalent to the 1.4 option – except that it permits a source code format of 1.5, thus permitting generics to be used. This was introduced in the transition to generics, mainly for testing purposes, in the run up to Java 1.5's release. However, it's still accepted today by Java 6 compilers.

Unfortunately, you can't select JSR14 from the drop-down list in Eclipse – but you can enable it anyway. Eclipse writes its compiler preferences into a file called .settings/org.eclipse.jdt.core.prefs. (This file gets generated when you've made a change to the Compiler Settings preferences pane in Eclipse; if it's not there, you can just change the compiler settings to 1.5 to get it to be generated.) Once it's there you can change the targetPlatform setting to jsr14. Alternatively you can just paste the following line in to the file:

org.eclipse.jdt.core.compiler.codegen.targetPlatform=jsr14

Note that whilst generics are supported with this method, other Java 1.5 features, like Enums, are not supported. That's because Enums are compile-time translated to subtypes of java.lang.Enum, which of course doesn't exist in the Java 1.4 runtime. Incidentally, the jsr14 flag refers to JSR 14, which was the JSR to add generics to the Java language.

This feature is used as part of the new OSGi 4.3 features to generify the existing libraries whilst maintaining binary compatibility with older VMs, which I wrote more about for InfoQ recently. This largely forgotten feature is still supported by Sun/Oracle VMs as well as others like GCJ and IBM.

Note that the same technique can be used to generate code with automated build scripts such as Maven or Ant:

<!-- Maven -->
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>2.3.2</version>
    <configuration>
        <source>1.5</source>
        <target>jsr14</target>
    </configuration>
</plugin>

<!-- Ant -->
<javac source="1.5" target="jsr14"/>

OSGi Wiki proposal

At the OSGi Community Event in London recently, a complaint about the available documentation was raised. The problem is that whilst the RFCs are very well written, they really describe the contract of the service provider, rather than an end-user. As a result, you have specifications that (like JSRs) dive deep into nuances of behaviour, but either gloss over or completely ignore how end users might adopt it.

This causes problems in two places. Firstly, the requirements of “How can I use...” aren't answered, and secondly (probably more importantly) “Why should I use...” are never answered. It's implicit in the formation of the RFC that the Why question is already known and accepted – otherwise there wouldn't be an RFC in the first place. Sun achieved this with the Java Language Tutorial book, a much better learning point than (say) the Java Language Specification. Yet all we have are the OSGi specifications from the official osgi.org website.

The reason we don't have such resources, of course, is that the OSGi Alliance doesn't have the funds to do this. There's plenty of information on the web, but almost all of it falls into either runtime-specific examples (Equinox, Felix, Knopflerfish etc.) or simplistic “An OSGi bundle is really just a JAR with extra Manifest entries ...”. And there's not really a single place to go to.

Community-sourced information is fairly easy to come by, given a community with enough interest. There seems to be the interest for the Eclipse community; after all, wiki.eclipse.org has an ever greater number of contributions, and there are a number of Eclipse help documents which are sourced from the wiki.

The problem is that all the existing wikis are (necessarily) vendor-specific. The Eclipse wiki is a great place to go to find out about arcane configuration information for Equinox or ECF, but it's not likely to say how to configure Felix. Similarly, the Felix site has a number of useful tutorials on how to use standard OSGi services, but not much on Remote Services Admin – largely because Felix doesn't have an implementation yet. By putting it all in one, well-known place, we could overlay information that crossed boundaries and made them available to all.

I therefore propose the creation of an OSGi.org hosted wiki that the community could participate in to fill the missing gaps in the user-end documentation. When you look at wikis generally, they're a great way of assimilating information; and one of the advantages is that ownership of the material doesn't preclude updates by new maintainers (or even drive-by typo fixing), as well as fleshing out information or adding extra gotchas.

For this to work, there needs to be a few things to make it happen:

• Copyright – does it follow a Wikipedia or Eclipse wiki model, where copyright retains with the authors that contributed it? Or does it require copyright contributions to be assigned to the OSGi Alliance? Requiring copyright assignment may well detract people from wishing to contribute.
• License – what license is the information to be used under? Wikipedia predominantly uses GNU Free Documentation License, but many companies shudder whenever GNU is mentioned. Alternatively, one of the Creative Commons licenses may be more applicable, like CC-BY-SA or CC-BY may be appropriate.
• Terms of use – is it necessary for contributions to be collected uner a non-anonymous account, such that an account has to be created (with a terms of use restriction) before amendments can be made? The Eclipse wiki has this terms of use, including information being available under the EPL (or documented appropriately). If so, what should the terms of use be?
• Accounts – will it be possible to hook into an existing authentication provider using OpenID, like StackOverflow authenticates against Google accounts? If people already have an ID, then they may be much more likely to contribute towards it.

Actually creating a wiki, and getting the hosting, is the easy part. But the right decisions need to be made ahead of time in order to ensure maximum participation – and thus benefit – for the entire community. A license which doesn't permit commercial re-use, or requiring copyright to be transferred to the OSGi Alliance, are likely to cause problems for some angles. But those needs must be balanced against an alliance with legal duties to its members to ensure that it doesn't expose itself, either in terms of opinions expressed by others or by bad advice – a suitable distinction between “official information” and “community provided information – use at your own risk” needs to be present.

The balls are in motion, and discussions have been started on the subject. In the meantime, please feel free to comment on this article and suggest what contributions or licensing issues you feel are appropriate, such that there is a set of information available to those who need to make the decisions.

For the purposes of making it explicit, I have no formal connection with the OSGi Alliance and I am speaking out about my personal thoughts, not of my employer. I have a vested interest in making OSGi succeed, and to that extent, having a wiki and being a part of its construction makes sense to me.