Eclipse – not just for developing Java

Most folks who use Eclipse use the wonderful Java Development Tooling (JDT) and thus associate it as a Java IDE. While it is true that it is a great Java IDE, it is much more than that. While many have used the Ant Editor, it strikes most folks as being complementary to Java development. By the way, I had a chance to try out the new Ant Editor improvements of 3.1 M3. I liked the way you could navigate to referenced targets via F3, as well as the code folding. Control-click works as a way to hyperlink to a target, except on Mac OS X, where that keymapping interferes with contextual menus. So the Ant Editor is getting better and should be much improved over 3.0 by the time 3.1 comes out.

I tried out the RubyEclipse plug-in recently, because while I love vi, I wanted to see if Eclipse could support Ruby development better. It did help, providing me a Ruby project, though no Ruby files. I had to create “simple files” with Ruby code in them. I named them with the common Ruby extension “.rb”. I went into the Ruby Perspective, which has 3 panes: Ruby Resources (similar to Java Perspective’s Package Explorer), an Outline View and an editor area. I double-clicked on the “hello.rb” file, which opened up the Ruby Editor. This showed me syntax highlighting (which I had to change via the preferences to set to nice colors). Running it as a “Ruby Application” prompted me to set up the Ruby interpreter in the Preferences. Since OS X ships with Ruby 1.6 in the /usr/bin directory, I pointed it there. If you’re on another platform or if you want to get the latest version of Ruby, go to the Ruby Home Page. Once that was set, running showed the Ruby output in the Console View.

While the RubyEclipse plug-in still has a ways to go to match the JDT, using it demonstrated to me that Eclipse indeed is not just for developing Java. This is one of the great design decisions behind Eclipse: that it should support any kind of IDE tool (which later was expanded to supporting any Desktop Java Application with the RCP.) In fact, the JDT was forbidden to use any kind of internal APIs, forcing the Eclipse Platform team to surface up the proper APIs needed for any tool. The C/C++ Development Tools (CDT) was the first to benefit and the first to show that Eclipse is a multi-language tool platform. Tidbit: The CDT team’s motto is: “Better than JDT or go home.” :)

No Fluff Just Stuff

I spent the last few days at what’s called either a) the Northern Virginia Software Symposium (the boring name) or b) No Fluff Just Stuff (the cool name.) Why “No Fluff, Just Stuff”? Well, its all technical sessions by developers for developers, with none of the infomercial-like sessions that you might attend at other conferences. Its a conference that I recommend attending, since it a) teaches you a lot, especially about technologies that you wanted to know about but didn’t have the time to research, b) it comes to you, so you don’t have to pay for airfare, hotel, and car rental, and c) its quite affordable. The only downside is that you give up your weekend, but really… isn’t your career worth one weekend?

I learned a lot at No Fluff Just Stuff, like about Spring from Bruce Tate himself and Ant from Erik Hatcher. This is one of the conference’s great strengths: you get to meet the gurus behind the technologies that you are using. I’m definitely more excited about using Ant 1.6.x now that Erik’s explained what motivated the new features. I’m going to experiment with Spring. I also looked at the Spring Rich Client Project this weekend and it looks like it has really good potential. I’m hoping that all the open source work around Swing rallies around this project, since it is fragmented compared to the efforts of the Eclipse RCP. I’m hoping both thrive so as to give Desktop Java developers two great choices.

But I think the most intriguing sessions were by Dave Thomas, who co-authored The Pragmatic Programmer (which should be on everyone’s bookshelf), who encouraged me to think outside of the Java box and reminded me that programming indeed existed before Java and will continue to exist after Java is deprecated (though still around) in favor of another (perhaps more dynamic? perhaps aspect-oriented?) language. That Java is just another tool (even though it is a tool that accomplishes most of what we do from big to small) in a programmer’s toolbox.

Inspired by that, I took his Ruby for Java Programmers session and while writing my first Ruby programs, I was reminded of my days with Smalltalk, where I really learned about objects from my mentors. This Smalltalk to Java experience confirms that there is more to life than the language you currently program in, as many Smalltalkers at the time disdained Java as a toy language that was nowhere near as good as Smalltalk. I even remember a co-worker who had a picture of one of the main Java implementors taped to the side of his monitor with a little nastygram next to it. In the end, I think all of the old Smalltalkers that I worked with now program mostly in Java.

The reminiscing about Smalltalk leads me to one of Dave Thomas’s other observations: that we started programming because we love to. Or as a former Computer Science professor of mine once said: People program because they like to create things. Not sure if this was a Frank Capra-esque moment, but it definitely made me pause and reflect.

By the way, while I was in the Ruby session, I also tried out RubyCocoa (as you might have seen me thinking about in my deprecated Upcoming Posts list) and I have to say that the end result is exactly like another other OS X Cocoa app. I’ll have to include this when I get around to my Java/SWT vs Java/Swing vs ObjC/Cocoa vs Ruby/Cocoa shoot-out.

A Desktop Java Renaissance

I finally got used to the new look of JavaLobby and am glad that the gliding nav toolbar stopped gliding. That’s one of those features that seems glitzy but just ends up distracting the user. Anyways, I responded to two posts and found myself thinking… there is going to be a Desktop Java Renaissance.

Why so? Hasn’t Microsoft frozen the JDK out of Windows? Sun has a workaround for that, with Java WebStart, the consumer-oriented Java.com, and the Java Auto Update system tray icon. Also, Java is installed by default on Mac OS X, SUSE Linux and Java Desktop System.

Doesn’t Swing emulate everything and make your apps seem slightly out of place? Sun has improved the L&Fs of Swing in 1.4.2 and 1.5, but if those aren’t native enough, you can use the Eclipse Foundation’s SWT / JFace.

Are there any Desktop Application Frameworks, so I don’t have to roll my own every time? Eclipse refactored the Rich Client Platform (RCP) out of itself, due to popular demand. Trivia: The RCP Birds of a Feather (BOF) session at EclipseCon 2004 was the most popular, leading people like myself to write my name sideways in the margin to jam myself in there. Thanks again to Ed Burnette for spearheading the RCP effort.
If you’d rather use Swing (since RCP requires you use SWT / JFace), then you have Spring Rich or NetBeans to choose from as a framework. I’m interested in trying out Spring Rich and will share my experiences with you.

Are there any components available, ala Visual Basic or Delphi, to speed my development? In VB or Delphi, there’s a large assortment of components that you can buy instead of build, which shortens your dev cycle. This has been lacking in the past. However, now there is a multitude of Eclipse plug-ins, most of which can be used in the RCP, with more being developed every day it seems. If that’s not enough, you can even embed native components (like ActiveX on Windows or WebKit on Mac OS X) through either SWT or JDIC (which integrates well with AWT / Swing.)

What about Enterprise Java? Don’t worry, that’s still alive and well and thriving. Not only will J2EE focus on ease of development, but there are alternative frameworks like Spring.

The reason all of this is occuring is due to plain and simple market competition. Eclipse raised the bar when it came to look and feel and plug-in infrastructure, RCP on the framework side, and Spring on the enterprise side. Eclipse plug-ins started to multiply as the platform became more viable. While this can cause some divisions for those deeply invested in one specific technology, I think this is good for the Java community as a whole, because the choices this competition creates lets us developers decide our own fates. (And if our choice is open source, we can even contribute to the production and not just be a consumer.) All the pieces seem to be falling in place for a renaissance for Java on the desktop. Things should get even better, once Eclipse 3.1, with its extensive support for developing RCP apps, is released, its alternative Spring Rich matures, and as the plug-in market continues to grow.

Interesting developments to watch: There seems to be an effort to make RCP easier to install via either: 1. RCP support for Java WebStart or 2. natively compiling Eclipse / RCP apps.