What is Oracle’s mobile strategy for Java?

Posted by Spencer Uresk on November 16, 2010 0 comments

It has been a tumultuous time for Java – the transition to Oracle ownership has been rocky, there has been JCP drama, the language is falling behind feature-wise, and it’s future on a increasingly important platform (OS X) was briefly looking bleak.

Oracle’s stewardship over Java has been the center of a lot of controversy lately, and at least some of it has been largely due to Oracle’s communication with the Java community. I think there is a bit of a culture shock for both sides in this transition – Oracle is used to tightly controlled, infrequent communication with developers, whereas the Java community is used to constant communication and openness from Sun.

I suspect over time this culture difference will become less of an issue – Oracle is already showing a little bit that they can learn to open up and communicate better, and I think the Java community will grow to accept Oracle’s communication style.

For me, however, there is a much more depressing situation going on with the Java platform right now – Oracle not only lacks a (public) vision for the future of Java on mobile devices, they are actively preventing others from making Java relevant in the mobile space through litigation and licensing terms.

First, where is Oracle taking Java in the mobile space? In my view, down a dead-end. At JavaOne, there was a lot of hype (as there was under Sun) about the number of mobile devices Java ran on. Unfortunately, JavaME lacks most of the appeal of the current generation of smart phone platforms – it lacks the features of iOS or Android, is more difficult to develop with, doesn’t target powerful smart phones, and has a much more involved deployment process. In my view, JavaME represents the past, and concentrating on past success isn’t a very good long-term strategy.

There is, however, a company doing interesting stuff with Java in the mobile space – Google. Android competes very well with iOS, is relatively pleasant to develop for, and has a good deployment model. It has its drawbacks, but it is far more interesting and relevant than JavaME. What does Oracle do? They sue Google.

Adding to this is the licensing spat with Apache Harmony over field-of-use restrictions in the TCK designed to prevent Harmony from being used in the mobile space. To be fair, this was an issue that Sun failed to resolve and wasn’t something that Oracle added in after acquiring Sun. To be less fair, when Oracle was just a member of the JCP and not the owner of Java, they strongly supported removing the field-of-use restriction – now that they situation has changed, however, they aren’t doing the very thing they originally supported.

So, to sum up my complaints as a member of the Java community – not only does Oracle (and to be fair, Sun before them) lack a coherent, interesting long-term mobile strategy, they are actively preventing others in the community for moving forward on their own. Will this kill Java? Doubtful – Java can remain viable and interesting without any sort of mobile presence. It certainly is missing a huge opportunity and it will be unfortunate if the millions of talented, motivated Java developers can’t apply their Java skills to developing compelling, useful mobile applications.

Analysis of Apple’s Java bombshell

Posted by Spencer Uresk on October 25, 2010 1 comment

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.

Motives

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

Posted by Spencer Uresk on October 2, 2010 12 comments

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.

Prerequisites

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:

http://m2eclipse.sonatype.org/sites/m2e

If you need full instructions, you can go here:

http://m2eclipse.sonatype.org/installing-m2eclipse.html

2. Install the Scala IDE

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

http://download.scala-ide.org/nightly-update-helios-2.8.0.final

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:

http://github.com/sonatype/m2eclipse-scala

The short version of those instructions:

1. Download the latest jar found at this url:

http://github.com/sonatype/m2eclipse-scala/downloads

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 Scala-Tools.org 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 (suresk@gmail.com). You may also follow me on Twitter – @suresk.

IDEs are not about code generation

Posted by Spencer Uresk on September 11, 2010 4 comments

There’s been a lot of interesting topics on Twitter, the JavaPosse Google Group, and various blogs recently about the “complexity” of the Scala language and whether it will be the next Java. This isn’t meant to be a post ripping on Scala – I respect the hard work from the talented individuals it took to create Scala, and I think it is a delightful language.

However, there is more to a language than the language itself, and I think the tooling situation in Scala leaves much to be desired. This is fixable – Miles Sabin and others are doing some excellent work to improve the tooling situation in Scala. What is more worrisome is the attitude that a lot of people in the Scala community seem to have toward IDEs.

Every week or so, someone pops into the Scala or Lift mailing list and asks about the IDE situation with Scala. They are met with a smattering of helpful replies pointing them to the IntelliJ plugin, the Eclipse plugin, someone’s favorite TextMate bundle or whatever. There are also, inevitably, a handful of people questioning the need for an IDE in the first place – “Scala is such an elegant language, why do you need an IDE?” or “Scala requires no code generation like Java does, so why do you need an IDE?” or “You don’t need anything more than emacs” are some common refrains.

Development environments are very personal, often irrational

I’ve been working on developer tools for the last several years, and one of my most memorable experiences was talking to developers about IDE usage a year or two back. I’m a die-hard Eclipse user, and I was talking to a group of equally die-hard IntelliJ users about what they liked about it. I remember walking away shocked, thinking “What the hell are these guys on? Over half the things they liked about IntelliJ are reasons I quit using it!” I’m sure had I shared my reasons for being an Eclipse enthusiast, they’d be thinking the same thing about me.

One of the biggest lessons I’ve learned over the past few years is that developers are often very passionate about their development setup and are loathe to change it. The best development environment is the one you are most productive in – whether that is Eclipse, Netbeans, IntelliJ, TextMate, vi, emacs, dictating your code to an intern, or writing it on a piece of paper and scanning it in. I’m not arguing that people who are happy writing Scala (or any other language) in emacs are idiots and should use a modern IDE, but I am arguing that there are millions of developers who derive significant productivity benefits from using one and we aren’t interested in stopping just because a new language has nicer syntax.

Not just code generation

A common argument against modern IDEs is that people use them largely for code generation, and thus, languages such as Scala that are generally more elegant and terse don’t really benefit from an IDE. This is way off the mark. Code generation is only a tiny part of IDE usage for most people, and Scala benefits from an IDE almost as much as Java does. Let’s look at some uses for a modern IDE such as IntelliJ or Eclipse:

1. Syntax Highlighting

Yes, most text editors do this perfectly well.

2. Debugging

Being able to debug your code from within the same program you are writing it has a lot of benefits.

3. Real-time compilation information

Being able to immediately see when you’ve done something that the compiler doesn’t approve of is a time-saver, and can be especially helpful when you are learning a new language.

4. Auto Complete

Is this a form of code generation? Maybe, but I’d argue it goes well beyond simply saving you a few keystrokes. For one, autocomplete functionality can be pretty useful when you can’t quite recall what the method name is, what parameters it requires, or what it returns – a nice language can’t help you avoid this, this is a problem of being able to instantly recall details about potentially thousands of classes in hundreds of libraries. Second, autocomplete in Eclipse (and other IDEs, I assume) can show you JavaDoc information inline, saving you a context switch out to your browser to view them.

5. Getting useful information about the code you are working with

What calls this method? Where is this variable referenced? What classes implement this interface? What does this class’ inheritance tree look like? All of these are pretty useful things to know, and IDEs make them trivial to discover.

6. Code navigation

Ctl+o in Eclipse opens up a list of methods in the current class, ctl+o again changes the scope to all of its parents – this makes it trivial to navigate to a specific method. Ctl+clicking on a class or method takes me directly to it.

7. Easy access to sources

Being able to jump directly to the source of a library is often useful as well, and this works quite well in current IDEs. M2eclipse will automatically download sources for Maven-based projects, which makes this even easier.

8. Refactoring

One of the benefits of statically typed languages such as Scala is that you can refactor your code with a high level of confidence that you haven’t horribly broken something. IDEs make this task even easier.

9. Version Control integration

It is also nice to be able to interact with a version control system directly from your IDE, without having to switch to another program to checkin your changes, perform merges, get new code, etc.

Final Thoughts

You’ll notice that of the uses for an IDE I’ve pointed out above (which are not a comprehensive list by any means), at least half of them are especially useful for someone learning a new language or framework. Yes, I know Scala has a REPL that is quite useful for when you are initially learning and playing around with the language, but I think an IDE is incredibly helpful for that phase when you’ve been playing with the language for a month or so and are now trying to do something productive with it – the instant feedback and wealth of information that an IDE can provide is incredibly valuable during that time.

This wasn’t intended to be a mean-spirited post and I hope it didn’t come across that way. I’m just trying to point out that IDEs are not crutches for hack programmers who want a tool to write code for them – IDEs are incredibly useful, even for Scala.

Free copies of my iPhone Fantasy Football Cheat Sheet App

Posted by Spencer Uresk on August 24, 2010 0 comments

I have an app in the App Store, Simple Fantasy Football Cheat Sheet. It is a simple cheat sheet for fantasy football drafts.

Since draft season is upon us, I’m giving away a handful of copies of the app for free (it is usually $0.99). Check it out, and shoot me an email (ff@uresk.net) if you want a free copy. I’ll send you a promo code ASAP, no string attached (although leaving an honest review and/or telling your friends about it is appreciated!).

I only have 15 or so promo codes left, so act quickly if you want one!