I’ve talked about LimeWire in the latest installment of Swing Links of the Week, and now it’s time to meet its lead developer, Sam Berlin.

Tell us a little bit about yourself

My name is Sam Berlin. I’ve been working with computers since I was a little kid. The first “program” I wrote was a collection of .bat scripts in DOS for my parents, to let them choose what program to open. I went to college for theater, but after one semester decided I didn’t want to be an actor and switched to computer science and music, then switched again to computer science and philosophy.

I’ve been involved with LimeWire since around 2001, originally contributing patches as an open-source developer. Nowadays I’m the lead developer for the LimeWire client and focus on all aspects of Java delopment (NIO, Swing, concurrency, etc…). LimeWire’s open-source community has fallen off a bit, due to mailing lists not being maintained & the code becoming more complex and difficult to maneuver. I’m making an effort to simplify the code and make it easier for newcomers to comprehend — fortunately that process helps LimeWire’s internal daily development too.

What is LimeWire?

LimeWire is a file-sharing program. It’s open-source (see limewire.org) and written in Java. The company is Lime Wire, LLC and also contains the LimeWire Music Store and a variety of other projects. LimeWire has been around for about a decade. Originally it was compatible with Java 1.1.8 and even ran on Mac OS 8. Today, the project has over a half million lines of code and requires Java 1.6. The most difficult aspect of managing it is that it’s a client application and runs on all sorts of desktops — we can’t target a specific VM or architecture and ignore bugs on other ones.

Why did you decide to go with Swing? If you were to start from the scratch, would you still go with Swing today?

I wasn’t around for the decision to go with Swing in LimeWire 1 (that held through till LimeWire 4), so I can’t comment on that. With LimeWire 5, we effectively did start from scratch. We threw away the entire old branch of GUI code and started fresh. The conception of LimeWire 5’s UI began by evaluating a range of toolkits (QT, SWT, Swing, AIR, and probably a few others I can’t remember). Each one presented its own problems. In the end, we ended up going with Swing after finding the mozswing browser. A browser that worked on all platforms was the last remaining hurdle to using Swing. Of course, as things turned out, it wasn’t all perfect. We decided to require Java 1.6 (for many other reasons), and Apple only decided to release Java for OS X in 64 bit architecture. Because MozSwing uses XULRunner internally, it needs native code bindings — but the native code for XULRunner doesn’t work in 64bit mode because it links to 32bit code in OS X. So we can’t use the browser on OS X.

Still, I’m happy with the choice of Swing.

What are Swing’s weak points in your opinion?

The worst thing about Swing is that it’s too easy to use wrong. This is why, in my opinion, Swing has such a bad reputation. It’s so easy to use, and so easy to use wrong, that millions of amateur hackers have written awful Swing programs and given it a bad smell. (Of course, the fact that the default look and feel felt like you were using a computer in 1990 didn’t help.) Swing is great because it’s so flexible, but the flexibility is really it’s downfall. It’s the classic tradeoff in API development — if you create something confined and limited, the internal code has the flexibility to change and grow without causing errors. On the other hand, if you create with extensions in mind, you allow for hooks and have to be concerned that additions will break the hooks. Swing chose the latter route and it handcuffed internal Swing development.

What functionality is missing from core Swing, and would you want to see third-party libraries folded into the core distribution?

The #1 thing I would like to see, and fortunately it is happening, is JWebPane — a lightweight browser. The fact that it’s not included today is almost absurd. It’s like releasing a new programming language that can’t connect to the internet. As far as third party libraries are concerned, I don’t really care either way if they’re included in core swing or as a standalone enhancement. So long as third-party development continues, it’s effectively in core Swing. The only argument I can make for wanting to have them included is that Sun would be forced to keep them up-to-date and working, but I’d rather that the components remain flexible and changeable as time goes on. Third-party libraries can break API compatibility with major releases (and doing so is often a good thing if the old API had intractable problems), but Sun can’t do that with new Java releases.

Tell us about your experiences with embedding a browser into a Swing application.

It’s been pretty easy. Finding mozswing was the hard part — it’s not advertised anywhere. We learned about it through a blog post about NetBeans. The only catch is the browser is heavyweight, so we have to do some fancy footwork to let things show on top of it. (Apparently in Update 12 Sun has enabled limited heavyweight / lightweight mixing, though I haven’t tried it.) In LimeWire 4.x we embedded the SWT browser on Windows. That worked well enough, but the SWT browser is very limited in how you can configure it. You can’t change the User-Agent, can’t run Javascript, can’t listen for downloads… you pretty much can’t do anything. What’s great about mozswing is it exposes the entirety of XULRunner. We intercept DOM events and open links in native browser when the target is _blank, listen for the progress of the page and show loading animations, etc… The ability to do anything XUL can do is limitless. We even listen for new downloads and show them within LimeWire’s UI, complete with the progress of the download.

What do you think about Sun’s new direction of client Java towards RIA space with JavaFX (called Swing 2.0 by Richard Bair)?

To be honest, I haven’t really looked too deeply into it. It came about just a little too late for LimeWire 5. I think it’s an interesting direction, but I’ll reserve my judgement until people start using it and creating more than simple applets with it. The real important change, I think, is the new Java Plugin — it’s actually good. You can run a Java applet without stalling the browser, and can drag the applet off the browser… that’s pretty cool (and useful).

Have you considered moving to JavaFX at some point in the future?

Not really, but I won’t rule it out.

Is there anything else you would like to add?

Swing isn’t dead, it just isn’t targeted to today’s designers. A designer today doesn’t want to mess with complex application logic, he (or she) just wants to paint something pretty. Swing was unfortunately written before today’s designer existed. Sun’s trying to make up for this with JavaFX (which may very well work), but that doesn’t mean Swing is left in the dust. You can still write an amazing application, but you need to be well disciplined. The approach we took with LimeWire 5 worked very well. We focused on implementing ugly wireframes that performed the functionality, and afterwards went back and painted the UI. It requires some patience to not be turned off by the ugly, and some patience to wait to ship until the pretty is finished… but it pays off. In the end, you’ll end up with a program that is very focused in what it does and how it does it, and has a consistent look & feel.