Monthly Archives: November 2004

Azureus – killer SWT app

I’m helping out a friend by helping him install Fedora Core 3. I’d rather get him to use OS X, but Fedora is free and lets him leverage some existing hardware. One step at a time, right?

Fedora (which in my mind is really RedHat Linux 10) has grown to take up 5 CDs: 4 regular and 1 recovery CD. It is about a 2.29GB download, which is quite a lot.

By the way, isn’t it kind of funny how your old posts never expire from Google or any other search engine? Result #15 on Google for “luis de la rosa” is RedHat 2.1 networking seems to drop…. I mean…. Pentium 60? NE/2000 card? RedHat 2.1? Is any of this stuff useful to anyone anymore? It seems like this post should be exiled to wander in the desert wasteland like the retiring judges in Judge Dredd.

So I try downloading from a mirror the ISOs. Well I wanted to get them before tomorrow afternoon and it looked like it was going to take all weekend. This is with a mirror that I usually get good results with when downloading Eclipse, meaning it is relatively close to me.

I thought, this isn’t working for me. Why not join the Torrent for Fedora Core?

So I did.

I downloaded Azureus. This is the #1 project on SourceForge. It is a BitTorrent peer-to-peer (P2P) client. Best of all, it is written in Java and utilizes SWT. It looks quite nice on OS X and performed superbly. I downloaded the torrent above and then dragged it from Finder into the Azureus. Its UI is good and I really like the Norton Utilities disk-defragmenter-style of showing you how your files are arriving piece by piece. I think the tab metaphor is overused, though. It needs a non-pixelated dock icon on OS X and could use more documentation. Also I wonder if it would benefit from hosting on top of the RCP. It would also be nice to drag a URL into Azureus, bypassing the torrent download step. But these are really minor compared to the results.

The results? Well I’ve got a killer SWT app on my Mac, which is nicely deployed as an OS X app (rather than just an executable JAR, which is OK, but doesn’t fit in that well.) It is only 5.4MB on disk. Oh and I downloaded all of Fedora Core 3, 2.29GB, all in an hour and 18 minutes, roughly 4.1Mbit/s or 513kB/s. Much faster than the regular download from my favorite mirror site.

To burn the CDs, I tried using FireStarter FX for OS X, which is in beta. This seemed to burn the ISOs well and had a decent drag and drop interface. I tested out the CDs on my Windows box and they turned out well.

Now I’m ready to install Fedora…

Proposal to reduce repetition with Swing and SWT listeners

DRY – Don’t Repeat Yourself

We know that this is good, since it reduces code maintenance, so why do we persist with writing listeners like this: (Note that this is example is written with SWT; Swing looks almost the same.)

        final Button button = new Button(shell, SWT.NONE);
        button.addSelectionListener(new SelectionAdapter() {
            public void widgetSelected(SelectionEvent e) {
                text.setText("Hello World");

If you’ve got lots of these lying around, well first off, you should try using an application framework like the Eclipse Rich Client Platform or the Spring Rich Client Project. But if you don’t (and even if you do, you still need to deal with wiring interface elements together), then you can make a code template in your IDE to generate this idiom. However, you’re stuck with maintaining all this code, plus the code is not as clear as it could be.

What if instead, your code looked like this?

        final MyButton button = new MyButton(shell, SWT.NONE);
        button.onPress( text, "setText", new Object[] { "Hello World" } );

Unfortunately, because Java places a higher value on security of its classes than expressiveness, you cannot add methods to an existing class (which you can do in some other languages). Also, you cannot subclass SWT widgets. So, instead, we use a utility class, which is slightly less readable.

        final Button button = new Button(shell, SWT.NONE);
        ButtonUtils.onPress( button, text, "setText", new Object[] { "Hello World" } );

This is better, since it takes what used to take 5 lines of code to express and put it into 1. It also focuses on what should happen when the button is pressed, instead of that being dominated by the supporting code.

Swing introduced something similar back in Java 1.4 called EventHandler. This generates a dynamic event listener. For example:

        JButton button = new JButton( "Hello World" );
        button.addActionListener( (ActionListener) EventHandler.create(
                                                        ActionListener.class, textField, "setText", "source.text" );

Note that this has the disadvantage of having to grab parameters to pass to the target object from the ActionEvent object. That’s why I stuffed “Hello World” as the text of the JButton for this simple example.

Here is the main piece for ButtonUtils. The code for findMethod is relatively simple, but I can post it if people want it.

     * Registers an object that has a method named methodName,
     * which is called when the button is pressed.
     * @param button
     * @param instance
     * @param methodName
     * @param parameters
    public static void onPress( Button button, final Object instance,
                                                    String methodName, final Object[] parameters ) {
        final Method method = findMethod( instance, methodName, parameters );
        button.addSelectionListener(new SelectionAdapter() {
            public void widgetSelected(SelectionEvent e) {
                try {
                    method.invoke( instance, parameters );
                } catch (IllegalArgumentException exception) {
                } catch (IllegalAccessException exception) {
                } catch (InvocationTargetException exception) {

So what do people think about this? Does anyone use something like this in their code? The advantages are: 1. DRY, 2. less code overall, 3. somewhat clearer (could be clearer with Java language changes). Disadvantages: 1. reflection isn’t refactored easily, 2. reflective code doesn’t take advantage of static type checking at compile time, 3. potential for reflection exceptions.

Back from a week of studying Cocoa

As a wise man (Brent Simmons of NetNewsWire fame) once said in a blog post explaining MySQL to Frontier users: “Old programmer’s philosophy: if you work primarily (or exclusively) in one environment, it’s a good idea to learn about others. It stretches your mind, helps you think more widely and imaginatively about how to solve problem”.

For the past week, I’ve been studying Cocoa and Objective-C by reading Cocoa Programming for Mac OS X (Second Edition), by Aaron Hillegass, which came recommended and is definitely the best book I’ve seen about Cocoa programming. The author always brings a smile to my face, not just from his clear and warm writing style, but also the fact that he wears this huge cowboy hat all the time. It’s been quite interesting and exciting and its definitely been a mind-stretching experience. There’s a lot in Objective-C that Java could learn from, plus things in Cocoa for other desktop frameworks. (And vice-versa, of course.)

Here’s one example: in Objective-C, you don’t have an actionListener type framework, with actionListeners that either do work or delegate to other classes. Instead, you’ve got actions and targets, where if you press a button, you can tell another class to directly do something, instead of going though an actionListener.

For example: if you had a button that generated a random number, in Java/Swing, you’d have something like:

  myJButton.addActionListener( new ActionListener() {
    public void actionPerformed( ActionEvent anEvent ) {
  } );

In SWT, you use selectionListeners. The code would look like:

  myButton.addSelectionListener( new SelectionAdapter() {
    public void widgetSelected( SelectionEvent anEvent ) {
  } );

In Objective-C/Cocoa, you’d visually wire a button in a program called Interface Builder to an instance of RandomNumberGenerator, by control-dragging from the button to the instance (called a target from the button’s point of view). Then you’d pick a method to call (which is called an action). The end result is less code to maintain (actually zero lines of code vs 5 lines of code each for Swing and SWT) and a more direct mapping of the programmer’s intent: in this case, to generate a random number when the button is pushed.

Any other Eclipse user groups out there?

I just got back from the kick-off meeting of the Eclipse SIG (Special Interest Group) of the NOVAJUG (Northern Virginia Java Users Group.)  (Thanks Dave for getting it started!)  Matt Abrams of Cougaar Software gave a great presentation on how you can quickly get started building Eclipse plug-ins.  He has good experience in doing this from his work on the Cougaar IDE, which helps developers use Cougaar, which I’ll talk a little more about below.  I’ll ask Matt for the presentation and post a link sometime soon.

Cougaar (short for Cognitive Agent Architecture) is "a Java-based architecture for the construction of highly scalable distributed agent-based applications", which also happens to be open source.  It is brought to you via US tax dollars through DARPA (Defense Advanced Research Projects Agency), which is a good thing, because it seems that governments usually get a good return when they invest in research and development.  For example, you are able to read this blog primarily because back in 1973, DARPA started the research project which became the Internet.  I’ve met several smart folks who work at and for DARPA and they do good work.

Recently, it seems that DARPA has been supportive of open source projects, especially via the UltraLog project, which has spawned not just Cougaar, but also the popular (and quite useful) PMD.  PMD, if you don’t know, is a nice static analyzer of Java source code which can find problems.  PMD also has an Eclipse plug-in (as well as plug-ins for most every Java IDE you can think of.)  So try out Cougaar IDE and the PMD plug-in, especially if you’re in the US, since you’ve already paid for them. :)

Note on PMD: I would recommend using the Eclipse Update Manager, using the URL as the remote site URL vs downloading the files from SourceForge.  It seems to be a newer version and it fixes a bug in PMD due to its inclusion of Xerces, which is used in the serialization of its preference files.

Back to my original question: are there any other Eclipse user groups out there?  If so, let me know and we can all link up.  If your local community doesn’t have one, consider starting one.

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.

Eclipse 3.1 M3 is here!

You have to love the Eclipse developers.  They are like clockwork, hitting their milestones on time or sometimes early.  Eclipse 3.1 M3 (in English: Eclipse 3.1, milestone 3) was released today at 3:33PM EST.  Note that this release is also the same as integration build I200411050810 (though I’m not sure how many folks actually download integration builds.  Do any of the readers out there do so?)

An interesting thing about Eclipse is that the mirrors don’t seem to propagate right away.  So, as of 11:14PM on 11/5/2004, you have to go to the main Eclipse download site to get Eclipse 3.1M3.  The mirrors should pick it up within the next few days.

The New and Noteworthy for Eclipse 3.1 M3 (which is where the Eclipse team highlights what’s in this milestone) is a must read.    I prefer the printer friendly version.

Here are some initial highlights:

  1. JFace virtual tables (SWT had virtual tables before, but it didn’t work with JFace)
  2. More support for J2SE 5.0
    1. enumerations (there’s even a wizard to create these)
    2. static imports
    3. varargs
    4. better generics support (generics support was introduced in 3.1 M2)
  3. You can tell the incremental compiler to exclude internal packages that shouldn’t be used.  For example, com.sun.* is internal to Sun and Sun reserves the right to change it with each release.  I wonder if this also prevents Quick Assist from giving classes in these excluded packages to you as an option for importing when it can’t resolve the class.
  4. Some nice refactorings and quick assists
    1. convert ? operator to if/else and vice-versa (there are times when one reads better than the other)
    2. introduce a local variable after instanceof check
    3. convert usages of collections to use generics (officially called "Augment Raw Container Clients" (This needs to be turned on in the Java > Work in Progress preference page and doesn’t support Map yet.)
  5. You can now see an externalized string when you hover its key and can navigate to it
  6. You can see the toString() inline while debugging (configure with Variable Details…)
  7. Ant editor is improved w/F3 and hyperlink navigation, Shift+F2 to open up the Ant manual for a relevant element, etc
  8. You can execute Javascript in the SWT Browser widget

I encourage everyone to download Eclipse 3.1 M3 and try it out.  Then give your feedback to the Eclipse team.  Open source works best when the community is involved.

Interesting development:  The Eclipse team is now tracking performance, which is a good sign.  I think this test is only on Windows XP for now.  Since this is the first time I’ve seen this, I’m not sure how significant this first test is.  Looks like window resize and control renaming is slower, but conditional breakpoints, opening up Java and text editors, and creating configurations are significantly faster.

Eclipse 3.1M3 due out today / Java GUI Builders

Per the Eclipse 3.1 Project Plan, Eclipse 3.1M3 should come out today.

It looks like there is great interest in Desktop Java as I saw the number of page views surged yesterday.  Thanks all for reading and stay tuned for more.

One more enabler for a Desktop Java Renaissance:  The appearance of some really good Java GUI Builders.

Sun wanted to have a tool that competes against VB for ease of development.  So they created Java Studio Creator.  It creates webapps in JSF (JavaServer Faces) without giving up the "highly-productive visual style" that you’re used to.  That’s marketing-speak for: "You can use a drag and drop GUI Builder.  That means you, VB Coder."  That’s great for webapps, but for Desktop Java, there are now several GUI Builders that are widely available.

Now I haven’t tried the Java GUI Builders in IntelliJ (still have the 3.x version) or NetBeans, but I have tried both the Eclipse Visual Editor and Instantiations SWT Designer.  I’ll post more detailed reviews in the future, but the important thing to note is that these two products are going to help a lot of people create Desktop Java apps.  I’m an experienced Desktop Java app developer and love to create UIs in code (either Swing or SWT), but I know there are a lot more people who would rather drag and drop and get it over with.

These two GUI Builders are exceptionally good.  SWT Designer is a professional product that is more polished, faster, and comes w/support.  Note that Instantiations also has a Swing Designer and also WindowBuilder Pro which lets you build a GUI in either Swing or SWT.

The Eclipse Visual Editor is only at 1.0.1 and interestingly started off life as a Swing UI builder, but now lets you build SWT and Swing UIs.  It is open source and it’s 1.1 release seems to be synchronized to come out around the time that Eclipse 3.1 comes out, according to the newly released Eclipse Visual Editor Project 1.1 Plan.

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, 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.

Native Browsers in Java on Windows (and Linux)

Last night I looked at embedded native browser components in Java, focusing on Mac OS X. Tonight we’ll look at what’s available on Windows. There are at least 4 contenders, perhaps more. In addition, there are 3 browser choices: Internet Explorer 5.x/6.x, Mozilla 1.4, and Mozilla 1.7.

First off, there is the Browser component that I talked about last night. Due to the elegance of the Eclipse plug-in loader (actually it is OSGi in 3.x), the name of the component is also called Browser. However, it is in the org.eclipse.swt.win32 plug-in instead of the org.eclipse.swt.carbon plug-in. This is the nicest of the bunch, with the caveat that it only embeds IE 5 or IE 6. Using the SWT Examples that you can download from the main Eclipse download page (look for Example Plug-ins), it worked pretty much like IE. You could even drag URLs to it and it would load them up and update the location bar. On my Windows XP laptop, I’ve got IE 6 installed and using the BrowserSpy information, I confirmed that it was indeed IE 6. Ryan Lowe pointed out that if you have IE 5.x on your Windows, then this component would embed IE 5.x. This came out with Eclipse 3.0.
Eclipse plug-in / RCP developers: I would use this implementation.

Second, we’ve got OLE/ActiveX integration on SWT Windows. I tried this via the SWT Examples again and was unimpressed, but probably because there was more work done in the SWT Browser widget. BrowserSpy couldn’t detect what it was, the location bar didn’t update, though it did otherwise work like IE. This has been around since at least Eclipse 2.x.

Third, there is the JDIC Browser component. This is an AWT component that can nest IE quite easily. There’s a demo available via JNLP. This can also embed Mozilla 1.4 (the whole thing, not Firefox), but you have to jump through some hoops to get there, including setting an environment variable and copying an .exe file. This performed well and the APIs are designed to work cross-platform. The SWT Browser API edges it out for completeness, though. BrowserSpy confirmed IE. This is licensed via LGPL. This project is looking for some help, especially with supporting Mozilla 1.5 and up. BTW, Mozilla 1.4 is around the timeframe of Firefox 0.7 – 0.8. This project started up around the JavaOne 2004 timeframe.
Swing developers: I would use this implementation.

Finally, there is the Webclient. This is another AWT-based implementation that predates the JDIC. This supports Mozilla 1.7 (the whole thing again, not Firefox) only. There is no IE support, but that only makes sense, since this is a collaboration between the Mozilla Foundation and Sun and is hosted at BrowserSpy confirms that it is Mozilla 1.7. The installation for this was the most heavyweight, due to the reliance of Mozilla 1.7. Nonetheless, this performed decently. This project was started back in 1999 and is licensed with the Mozilla Public License. I suspect that this will either merge with JDIC or be overtaken by JDIC.

One more… JRex supports Mozilla 1.4+ and integrates with AWT/Swing. Haven’t tried this yet, but again, I think JDIC is the project to beat in the AWT/Swing universe.

Linux readers: The only problem is that the list would be almost the same as the one for Windows, except that IE gets the boot, with Mozilla being the only choice for embedding. Also, no OLE/ActiveX. SWT GTK2 3.0 supports Mozilla 1.4 – 1.6 and the 3.1 stream adds support for 1.7.

Update [11/3/2004 10:33PM] – I clarified which browser will be embedded using the SWT Browser widget on Windows. It will be whatever version of IE that is currently installed on your system.