IDEs are not about code generation

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

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!

More updates about the Oracle vs Google lawsuit

The text of Oracle’s complaint is available online, here (courtesy of Rick Ross of JavaLobby and dzone). It appears as though the complaint centers around 7 patents and a claim of copyright infringement.

Patents

There are 7 patent claims, all of which seem to center around virtual machine related concepts:

6,125,447 – Protection domains to provide security in a computer system
6,192,476 – Controlling access to a resource
5,966,702 – Method and apparatus for pre-processing and packaging class files
7,426,720 – System and method for dynamic preloading of classes through memory space cloning of a master runtime system process
RE38,104 – Method and apparatus for resolving data references in generated code
6,910,205 – Interpreting functions utilizing a hybrid of virtual and native machine
6,061,520 – Method and system for performing static initialization

Copyright

The complaint also references the copyrights around code, documentation, and other artifacts surrounding the Java platform, and claims Google infringes on some of these as well. It isn’t immediately clear what they are referring to, however.

What this means

It is pretty clear that this complaint is centered around the Dalvik VM. Lots of people (including me) have already been speculating about whether or not GWT could also find itself a target of Oracle lawsuits. It is probably safe from the patents listed above, but there is still a potential of it having the same copyright violations as Android – or perhaps Oracle has more patents up its sleeve.

Further, people have been suggesting that Google change Android to use one of the alternate JVM languages (such as Scala or Clojure) instead of Java, but it is unlikely that would make a difference, since the complaint centers around the VM.

The reaction from the Java community has been swift and negative towards Oracle. Google is doing some cool and innovative stuff with Java, why is Oracle going after them like this? Google has been hugely involved with Java, will this lawsuit push them towards another language/platform?

Oracle sues Google over Android

I recall a few years back when rumors were swirling about potential buyers of Sun Microsystems. There seemed to be a consensus within the Java community that it would be better for the future of Java for Sun to be acquired by Oracle rather than IBM. Oracle had been a good participant in the JCP and didn’t have as much direct reliance on Java for their business, and thus would have less incentive to muck around with Java.

Today, however, I think much of that goodwill evaporated. According to MSNBC, Oracle is suing Google, claiming that Android violates numerous Java-related patents. I think this doesn’t bode well for the long-term outlook for Java.

Android

Android is one of the most exciting areas in Java development today – it is standing toe-to-toe with Apple’s iOS in the hottest technology space (mobile). JavaME has been reasonably successful – more so than people often give it credit for – but it can’t compete with iOS or any of the other smartphone platforms. Without Android, Java has limited representation in the mobile market.

Frankly, I’m confused as to why Oracle is going after Google here – a consumer phone OS seems pretty far out the realm of Oracle’s normal business.

GWT

I hadn’t even thought of this until one of my co-workers pointed it out – GWT has some of the same legal issues in this case as Android and could fall into Oracle’s crosshairs as well. Oracle has been incredibly excited about JavaFX and GWT is a direct competitor in that area. Will Oracle go after GWT next?

What else?

Java is an excellent language, but it has been showing its age for some time now. Many other languages offer more advanced features and are arguably better in some areas (C# comes to mind), but the main strengths that have kept Java relevant for so long have been the JVM and the community around the platform. If Oracle goes around suing everyone in the Java community with their new IP assets, what does that mean for the community?

Ultimately, we’ll have to see how this develops and what happens – perhaps they will settle quickly, with Google paying some licensing fees and Oracle leaving everyone else alone. Or, perhaps this is just the beginning of Oracle milking every dollar they can out of the Java platform.

With this development, plus all of the high-profile departures of ex-Sun employees, I’m a little worried about the long-term future of the Java platform under the stewardship of Oracle.

JDK 6 update 21 kind of breaks Eclipse on Windows

If you recently upgraded to JDK 6 update 21 on Windows and are noticing lots of Eclipse problems, I probably know why (and can show you how to fix it).

First, some background. The HotSpot VM (Sun’s implementation) has a concept known as the Permanent Generation, or PermGen for short. Its main purpose is to confound users and it is rumored to be going away in future releases of HotSpot. By default, the VM allocates 64 MB for the PermGen space, which is often enough. However, Eclipse installations with a lot of plugins tend to need a lot more.

Because Eclipse is meant to work on multiple JVMs, the stock eclipse.ini doesn’t directly set the PermGen size, it has a line that looks like this:

–launcher.XXMaxPermSize
256m



That will tell the Eclipse launcher to set the perm size, if it is running on the HotSpot VM. Unfortunately, it appears this quit working with update 21 – a quick check with VisualVM showed that this flag wasn’t working and no matter what you set it to, your VM would have only 64MB of PermGen space.

It appears that the cause of this is that with update 21, the vendor flag was changed to Oracle, which broke Eclipse’s VM detection code. Thus, the flag is never being passed through to the VM. It appears as though this only happens on Windows and only when running the Sun (sorry, I’ll never call it Oracle) JVM.

Fortunately, it is easy to fix. Simply add this flag to the -vmargs section of your eclipse.ini (it should be at or near the bottom):

-XX:MaxPermSize=256M

That will directly set the PermGen size and should fix any PermGen errors you were running into.

Who knows what else changing the vendor flag broke?