Alex headshot

AlBlue’s Blog

Macs, Modularity and More

Eclipse as a training tool

Eclipse 2005

Bruce Eckel recently wrote on his blog a comment about IDEs as a training tool, stipulating that he wanted "an IDE that's idiot proof, because:

  • I don't want to struggle with it; I have other problems that I want to solve and the IDE should be a helper and not something I have to work against.
  • When I teach, I don't want seminar attendees to get lost in the IDE, either. That's not the problem we're trying to solve in a seminar."

The problem with any IDE when teaching is that you can spend too long explaining what the IDE is, and how to use it, rather than the language itself. On the other hand, if you go back-to-basics (a text editor and the command line compiler, for example) you can teach a lot about how the low-level of Java coding works, but without how to be productive in code.

I used to give training courses to a wide variety of students, and was often asked for my input as a recommended editor, to which I always used to reply Eclipse. I'm somewhat biased towards it; it has grown from Visual Age for Java, through the various WebSphere Studio incarnations, and is now Rational Developer -- all of which I have been involved with at some point through their initial deployment and use.

Of course, I don't just recommend Eclipse because of that; it's also free, which is a big deal in some circles. It's been a great marketing plan by IBM to get people used to Eclipse, because when they 'upgrade' to WebSphere Studio or Rational Developer, they already know how to use the product; and so there are millions of developers world-wide who can claim knowledge of the basic Eclipse interface. (One of the reasons why Visual Age for Java didn't grow so well is because the interface was too advanced for most people to use; and being a paid-for product, it only ever had a small marketshare.)

The main reason I recommend Eclipse (or indeed, any IDE over notepad) is that an IDE will give you much better productivity in generating (and debugging) code than a text editor ever could. The Java compiler gives all sorts of spurious warnings when missing a semi-colon, for example; whereas Eclipse (and others) show you where the error is in the built-in editor, often with a quick-fix mark that can get rid of it for you. You may not learn much about classpaths, but you do learn a lot about OO and Java, which is mostly what I would be teaching.

Although I would recommend IntelliJ/IDEA to anyone with enough money, Eclipse gives you most of that for free. It's also catching up fast; expect the combined development might of IBM, BEA, Sybase -- in fact, pretty much everyone other than Sun -- to overtake IntelliJ fairly soon, in the next major release. For what it's worth, Eclipse is also being used as a framework to launch other non-coding GUI applications; the Eclipse Rich Client Platform aims to provide an application framework that has been sorely missing from the Java language core.

A big reason why I teach with Eclipse, though, is the Java Browsing Perspective.

Image of Eclipse using Java Browsing perspective

This perspective shows you an object oriented view of your code, not a file-oriented view (as other IDEs and the Java perspective show you). Most people don't even know it exists, and even when they do, find themselves torn away from the file-oriented view that they've come to know and love. But let's face it, you're not editing files when writing Java code -- you're editing objects, and the Java Browsing view shows very nicely how they are associated with each other. (I personally customise the Java Browsing perspective to have a Hierarchy view on the left as well; that way, I can navigate around my object-oriented structure incredibly quickly, and the fact that they are stored in files is co-incidence as far as I am concerned.)

It doesn't sound like much difference, but when you're editing any decent-sized project (and have you noticed, that whenever you go on a training course, you rarely get more than about 20 objects?), the Java Browsing view really allows you to navigate through a wide variety of objects incredibly quickly. Plus, it supports all the usual drag-n-drop operations, so if you want a class (or set of classes) moved to a different package, it's just a drag and drop away.

What some people like in the Java perspective is the ability to 'remember' where they are in two separate places at once. Whilst you can't do that in the Java Browsing perspective (essentially, there's only one selected object at once), you can open up a new window (Window -> New Window) and then Alt+Tab (or Command+Tab) to the other breakpoint. I rarely find that I need to do that though, as the multi-editor window allows me to navigate between files in different places.

Of course, I'm biased -- the Java Browsing view is directly reminiscent of Visual Age for Java. You can even hide other members in the same class by clicking on the 'hide members' icon; in the screenshot above, it's the one just below the 'p' in the 'Help' menu. This allows the editor to 'zoom in' on a particular element, and hides unrelated members. This is really useful to force someone to think in terms of objects, not file structure, and tends to get around all of the issues to do with whether getters/setters are put next to each other in the file. It doesn't matter people -- they're objects.

In any case, that's why I used Eclipse for doing training courses; and though I've moved on to bigger and better things, I'd still recommend Eclipse to anyone who wants to be on board with the undisputed leader of the pack for the future. And if you're learning Java and want to get used to objects, I suggest that you switch out of the Java perspective and stick with the Java Browsing perspective from now on. Like touch-typing, it takes a bit of getting used to at first, but you'll quickly get better and be more productive than the Java perspective.