Monthly Archives: October 2010

Analysis of Apple’s Java bombshell

I heard about Apple’s deprecation of Java just as I was headed to BlizzCon this week and have spent some time over the past few days chewing on Apple’s move, their motives, and the ramifications.

The sky isn’t falling… yet.

Java 6 is currently quite well-support on OS X. Java 7 isn’t slated to be released until mid-2011, and there is usually a lag between when a new version of Java is released and when people are able to start using it. Apple’s Java releases have historically lagged behind Sun’s releases – sometimes by over a year. This obviously isn’t a terribly good situation, but it does mean there is a significant amount of time to at least achieve “business as usual” for Java on OS X.

There is also one bit of good news in the release – it looks like Apple is trying to accomodate third-party JVMs.


There has been a ton of speculation about why Apple is making this move – from pure business reasons, to Apple wanting to kill Java, to Apple wanting even more control over their entire platform. If I had to guess, I’d say it is a combination of #1 and #3. Apple is clearly moving Mac OS closer to iOS, and Java doesn’t really have a place in that transition. Apple would rather use resources dedicated to maintaining Java for Mac OS to do something that is closer to their long-term goals. Unfortunately, I think Sun is partly to blame for this – poor marketing and poor focus on desktop Java has made it largely irrelevant except for developers, which makes it easy for Apple to ignore it.

Don’t take it personally

Apple isn’t very sentimental about technology and they have nowhere near the emphasis on backwards compatibility that other companies (like Sun or Microsoft) have. They are pretty ruthless about abandoning technology when they feel it no longer helps them meet their goals.

Apple can kind of get away with this a little more because the majority of the products they sell are consumer-related with an expected lifespan that is very short. It is also part of their culture, however, and I think it helps them be successful. Backwards compatibility is a double-edged sword, and while it hurts when you are on the wrong side of it, I think Apple does a decent job of balancing it.

Is Mac OS going to become iOS with a keyboard and better hardware?

Looking at Apple’s history and what they are doing with iOS, there is good reason to wonder this. I think Apple definitely wants to move Mac OS closer to the model for iOS – it gives them a ton of control (which they like because, among other things, it allows them to create a better experience for most users) and because it gets them more money (by controlling application distribution, they can get a cut of each sale).

That said, I have doubts as to how far they will be able to take this. For one, there are legal issues – I think Apple is already playing with anti-trust fire right now with iOS, and total control of the desktop situation would sure be attract unwanted attention from the DOJ. More importantly, there are pragmatic issues. Developers, creative professionals, and other power-users would have a hard time working with a a crippled, locked-down Mac OS that some people are envisioning.

Does Apple need Java?

Obviously, Java isn’t critical to Apple’s success, but it is (and will continue to be) important to them for a few reasons. First off, Apple themselves use Java quite a bit for their server-side stuff – the Apple Online Store, the iTunes backend, and other systems. They’ll need to have some level of Java support in OS X in order to continue to support these systems, but I’m not sure how they intend to handle that.

A Java-less Mac OS also hurts sales of Mac hardware – not enough to seriously hurt Apple, but enough to make me wonder how much financial sense it makes for them to discontinue their support for Java. Apple typically utilizes small, effective teams, and I don’t think the team that supports Java at Apple is more than a handful of people, which means it can’t cost them more than a few million dollars to maintain Java. Judging by the number of MacBook Pros at JavaOne alone, this seems like a pretty effective investment – unless Apple thinks someone else will maintain Java enough to keep Java developers interested.

Does Java need Apple?

Probably, to some degree. Apple is doing a great job marketing the Mac OS platform and I think it is reasonable to assume it will continue to grow. If Oracle is concerned about getting traction in the consumer market with Java, then making sure there is a good JVM for Mac OS is going to be really important. On the developer side of things, I think it is also important for there to be good Java support on the Mac. There is already quite a bit of uncertainty and negativity around Java right now – JCP shenanigans going on right now, Oracle’s lawsuit against Google, and concerns about the pace of new features and releases. Losing support for a major platform like Mac OS would be another blow to a community that is already a bit unsettled right now.

Oracle hasn’t really shown much interest in the Mac platform and it will be interesting to see if they are willing to devote resources to keeping Java alive on it.

Where do we go from here?

I don’t think Apple is doing anything particularly nefarious here, even though the result appears to be somewhat unfortunate in the short-term. I think there opportunities for Oracle and other big members of the Java community to step up and fill the void that Apple is leaving. Perhaps in the long-run, this ends up being good news for Java on Mac OS? Apple generally did a decent job of providing Java on Mac OS, except that it was always well behind other platforms and Apple is notoriously bad about communicating their plans for Java – perhaps someone else would do a better job?

Developing with Lift in Eclipse

A few weeks back, I wrote a blog entry lamenting the attitude toward IDEs in the Scala community. A few people told me that the tooling situation was better than I’d implied, so I thought I’d spend a bit of time looking at using Scala (and Lift specifically) in Eclipse. I think the situation is still a ways away from the tooling situation for Java, but it is actually quite good, and I wanted to post a quick tutorial for those interested in developing Lift in Eclipse.


This post assumes that you already have Scala 2.8 final and Eclipse 3.6 on your system. For Eclipse, I recommend upping the Xmx setting if you haven’t already – I had issues when I had multiple Lift projects imported with Xmx set to 386.

Also, this tutorial is going to use Maven, not SBT. SBT may be a better build tool for Scala projects, but I’m not sure how well it works with m2eclipse – I’m going to play with that more later.

I also assume you know how to install plugins into Eclipse – I will create a more in-depth screencast for doing all of this if there is enough interest.

1. Install m2eclipse

Install m2eclipse using the following URL:

If you need full instructions, you can go here:

2. Install the Scala IDE

Get the Scala IDE for Scala 2.8.0 and Eclipse Helios here:

3. Install the m2eclipse-scala plugin

There is a configurer for m2eclipse that will setup Scala projects for you. You can install it using the directions here:

The short version of those instructions:

1. Download the latest jar found at this url:

2. Copy it to the dropins/ directory in your Eclipse installation

3. Restart Eclipse

4. Create a Lift project from an Archetype

Now you can create a new Lift project from the Archetype – this is effectively the same as running the mvn archetype:generate command that the Lift ‘Getting Started’ guide tells you to.

To do this, go to File > New > Other… > Maven > Maven Project

Follow the wizard until you get to the Select an Archetype screen. In the Catalog drop-down, select the Catalog. A list of archetypes will appear below – you can filter down to just the Lift projects by typing ‘lift’ in the Filter box. Select one of the Scala 2.8/Lift 2.1 archetypes – I selected lift-archetype-basic_2.8.0. Click next and fill in the information (group id, artifact id, and version), and then click ‘Finish’.

m2eclipse will spend a few minutes setting up your project, downloading sources, and configuring it in Eclipse.

5. Import an existing Lift project (optional)

If you already have a Maven-based Lift project, you can import it. Just select File > Import.. > Maven > Existing Maven Projects and then follow the wizard to import your project. It will configure everything for you.

6. What you can do

So, now that you have a Maven-based Lift project in Eclipse, what can you do?

– Code complete, syntax highlighting, and real-time compiler errors are available

– Code navigation works quite well – you can CMD/Control + click a class or method to go right to it. Cmd + O will let you navigate the methods and fields in the current class.

– m2eclipse will download sources for you automatically – this is one of my favorite features. If you navigate to a class in the Scala API or Lift itself, you’ll see a rough decompiled view of the class for a second while m2eclips grabs the sources, then it will refresh with the actual source code. This is a really handy feature! It will also download scaladocs for you.

– You can setup an m2eclipse command to run Jetty within the IDE. Right-click on the web project and select ‘Run as…’ > Maven build… You’ll be presented with a screen for creating a new maven runtime configuration. In the Goals box, add jetty:run, then click ‘Run’. This configuration will be saved, so you can run your project in Jetty anytime you want by using the Run button in the menu bar. You can also do this for the mvn scala:cc command if you want.

7. Final thoughts / Feedback

I think the tooling situation for Scala and Lift is pretty good – much better than when I was doing a lot of Lift work last year. A lot of credit goes to Miles Sabin, David Bernard, and others who have done a lot of work to make this possible.

If this post was helpful, please let me know. I’m also interested to know if people are interested in more in this area, specifically:

1) A screencast showing how to do all of this, and what other features are available when working with Scala/Lift projects in Eclipse.

2) A single Eclipse feature that can tie all of the above features together into one easy-to-install package, along with setting up the m2eclipse Run As.. commands automatically for you.

If either of these interest you, or you have any other ideas, please let me know. You can either leave a comment on this post or email me directly ( You may also follow me on Twitter – @suresk.