Cliff Liang has translated “A Shape Diagram Editor” into Chinese. You can read it here (assuming you can read Chinese).

It’s only every once in a while that I really get to geek out and use some of that computer science stuff I learned in university. Frankly, I quite enjoy these little opportunities (disturbingly, most of these opportunities have something to do with combinatorics and recurrence equations).

Yesterday, I wrote a recursive backtracking algorithm for solving Sudoku puzzles. It’s a pretty simple thing (only about a dozen lines of code in addition to all the code that implements the actual puzzle board) but it works. And it works well. I use it to both solve an existing puzzle and to create new ones. Unfortunately, it’s not all that smart and, while it oftentimes takes less than a second to solve a puzzle, sometimes it takes several minutes. I have some thoughts on how to speed it up that I’ll explore over the next few days.

I built the solver because I need to generate puzzles for a Sudoku game that I’m building with Maria, my co-op summer student, using Eclipse Rich Client Platform. It’s taken about two days to get most of the game working and now, we’re working on finishing touches. Here’s what it looks like so far:

As you hover over a cell, it shows you the values that could possibly go in that cell; you simply type a digit to set the value in the cell under the cursor. At some point, we’re going make a preferences selection to turn on or off the hints. We’re also going to add a feature to optionally highlight invalid rows, columns, and boxes. There’s already a lot of cool features in the implementation that I’ll likely blog about later this week and next.

As of now, the Sudoku game is just a collection of plug-ins that I’m testing in the Eclipse workbench. I’ll turn it into a proper RCP application sometime later this week. That should end up being a pretty simple exercise since most of the heavy-lifting is already done.

The European Conference on Object-Oriented Programming (ECOOP) 2006 is being held in Nantes, France from July 3rd to 7th. Eclipse is going to be there in full force.

The Eclipse Technology Exchange (eTX) Workshop will be held on July 4th. The goal of the eTX workshop is to create opportunities for participants to become familiar with each other’s work and to create a challenging environment for open exchange among participants. The deadline for position papers has already passed, so unless you’ve already submitted, you’ll be joining me in the groupie area outside the workshop space.

That evening, the Eclipse Foundation is hosting the Eclipse Bistro. The Bistro may sound a little weird, but I’m confident that it’ll be a great evening for anybody interested in learning about Eclipse. We’ve assembled a collection of experts in various Eclipse-related fields. These experts will be available to discuss your Eclipse questions, concerns, and projects. Bring your laptop if you want/need to show us something. The experts may have some demonstration materials of their own and will be invited to say a few words to the audience to describe their areas of interest and invite folks to their table. We’re also going to have a few short talks, beverages, and munchies. It should be a fun night for all involved.

Of course there is lots of Eclipse content at the conference; there are at least four tutorials with explicit Eclipse content and no-doubt many more that make use of Eclipse.

It’s going to be a great conference. I hope to see you there. Early registration ends June 2.

I just posted a presentation by Chris Laffra that steps through the new and noteworthy with Eclipse 3.2. You can find the presentation here.

You can get Eclipse 3.2 here.

And, of course, the RC3 release of Callisto is available for download and testing.

Over the past few months, I’ve heard a lot of folks talk about how many ways the ten Callisto projects can be combined. In all cases, the concensus seems to be that there are 10! (ten factorial) combinations. Or at least about that many. That’s 3,628,800 combinations. Wow! Except that it’s actually nowhere near correct.

To start with, the platform (Eclipse) project is required in all combinations. That leaves at most 9! = 362,880 combinations. That’s better. Far more manageable. Of course, when you consider that TPTP needs to have BIRT and that WTP requires EMF, then the actual number of possible combinations is actually quite a lot smaller.

Of course, this isn’t even close to correct anyway…

It’s just not a “factorial” type of combination. Assuming that you need to have the platform in all combinations, you can then either (a) have or (b) not have each of the remaining projects in your combination. Essentially, it’s a binary condition for each of the remaining nine projects. Either WTP is included, or it’s not. Either GMF is included or it’s not. And so on. Basically, you double your possible combinations with the consideration of each additional project.

Again, since platform must be included, there are really only nine projects to consider. So, there are 2⁹ = 512 combinations. Of course, the actual number of combinations is smaller than this since some of the projects are dependent on other projects.

So there you have it. All that university math I took was worth something. At least to me…

Good news for Eclipse plug-in/RCP developers who need to embed Swing/AWT components in SWT views on the Mac! Thanks to the efforts of Apple’s JVM developers, the SWT_AWT bridge now works on the Mac. Bug#: 67384 is now marked as resolved (and is peppered with comments declaring victory).

Now… I just need to convince Mike to let me buy a Mac so I can see it for myself…

In comments to a recent blog entry of mine, beche-de-mer (which I believe translates to “sea-slug”), asked if I could post an example of using extension points in an Eclipse RCP application that uses Swing. I decided to oblige with this hastily cobbled together example.

I added an extension point to my Eclipse RCP Swing example (the “root” plug-in displayed below). This extension point invites other plug-ins to contribute buttons to the window that “root” creates. Other plug-ins, like plug-in “A” and “B” displayed below, contribute extensions that include a label to display on the button and the name of a class to execute when the button is clicked. To keep things simple, I decided that the class must extend java.lang.Runnable.

The implementation is pretty straightforward… The “root” plug-in adds the following extension point declaration to its plugin.xml:

<plugin>   <extension-point id=”button” name=”button” schema=”schema/button.exsd”/>   …</plugin>

Then, I declared the following extension in the plugin.xml for plug-in “A”:

<plugin>   <extension point=”org.eclipse.examples.swing.rcp.button”>      <button            action=”org.eclipse.examples.swing.rcp.addon.Ouch”            label=”Hit me”/>   </extension></plugin>

As I mentioned, this extension point defines the name of the Runnable to execute when the button is clicked (”action”) and the text display on the button itself (”label”).

Finally, I changed the application code to the following:

public class Application implements IPlatformRunnable { public Object run(Object args) throws Exception {  JFrame frame = buildWindow();  while (frame.isVisible()) Thread.sleep(1000);  return IPlatformRunnable.EXIT_OK; }

 private JFrame buildWindow() {  JFrame frame = new JFrame(”Eclipse RCP”);  frame.setLayout(new GridLayout(2,1));  frame.setLocation(50, 50);  frame.add(new JLabel(”Eclipse RCP application with Swing!”));  JPanel panel = new JPanel();  panel.setLayout(new FlowLayout());  addButtons(panel);  frame.add(panel);  frame.pack();  frame.setVisible(true);  return frame; }

 private void addButtons(JPanel panel) {  IExtensionPoint point = Platform.getExtensionRegistry().getExtensionPoint(”org.eclipse.examples.swing.rcp.button”);  for (IExtension extension : point.getExtensions()) {   for (IConfigurationElement element : extension.getConfigurationElements()) {    if (”button”.equals(element.getName())) {     panel.add(makeButton(element));         }   }     } }

 private JButton makeButton(final IConfigurationElement element) {  String label = element.getAttribute(”label”);  JButton button = new JButton(label);  button.addActionListener(new ActionListener() {   public void actionPerformed(ActionEvent e) {    Object object = null;    try {     object = element.createExecutableExtension(”action”);    } catch (CoreException e1) {     e1.printStackTrace();    }    if (object instanceof Runnable) {     Runnable runnable = (Runnable)object;     runnable.run();    }   }  });  return button; }}

The addButtons() method does most of the work. It obtains the extension point and then the extensions. It iterates through the extensions and then delegates to the makeButton() method to actually create a button (with an appropriate label and action listener).

The final product looks something like this:

Both of the push buttons come from extensions (there is a second extension defined). This “application” is now very easy to enhance by simply adding more extensions in one or more plug-ins (a single plug-in can define multiples extensions for the same extension point). Only the buttons contributed by the plug-ins I actually include at runtime will end up on the window.

This example isn’t exactly industrial strength. I almost immediately discovered that using Runnable as the “action” class is insufficient. It’d probably be better to create a custom interface that provides some kind of application state in a parameter so that the action can actually do something interesting. Also, I don’t handle the CoreException very well (it should be logged at least). But I think the example gets the point across.

I’ve put the code into CVS. You can get it from server/repository: dev.eclipse.org/cvsroot/org.eclipse, directory: /www/evangelism/samples/swing/code. There’re two plug-in projects there. Enjoy.

Note that I’ve updated the CVS information.

Another first for me! How very exciting. Somebody took the time to adapt some of their advertising materials to the Eclipse Corner Articles format and posted their contents as an article submission. I’ve decided to be in awe of the cleverness of the attempt.

I get this question every once in a while: why is Eclipse so big? Typically, the person asking the question is thinking about the SDK. Why is the Eclipse SDK (version 3.2RC4) 121MB?

It’s a good question. The name “Eclipse SDK” provides a hint: it is the Software Development Kit (SDK) for building Eclipse applications. That is, the basic download for Eclipse contains what folks building plug-ins for Eclipse need: the platform, the Java Development Tools (JDT), the Plug-in Development Environement (PDE), and the source code for it all so that you can browse and debug into all the fore-mentioned parts. The source code accounts for a huge chunk of the download size.

Now, if you’re just using Eclipse to build, test, and debug your Java applications, you can get along with a more basic installation (you don’t need the PDE or the source code). Scroll down the downloads page until you find the “Platform Runtime Binaries” section and click on the one most appropriate for your platform. For Eclipse 3.2RC4, this is 34 MB. This provides you with the base platform for using Eclipse. Unzip this into your favourite directory.

Next, you need to add Java development tools. You can either do this by downloading the “JDT Runtime Binary” from the same page, or you can use the Callisto Discovery site. If you choose the former, decompress the downloaded files into your Eclipse directory and you’re off to the races. If you choose the latter, use the update manager to pull the “Eclipse Java Development Tools” off the update site.

All tolled, it weighs in at 54 MB. Still a lot bigger than Turbo Pascal on my old Apple ][e or Smalltalk/V 286 on a 1.4 MB floppy, but it comes with a lot more features built right in (like refactoring, and code completion, and quick fix and quick assist, and CVS integration, and a real component model, and syntax highlighting, and spell checking, and Ant integration, and local history, and integrated debugging, and, and, and, and, …). Then there’s licenses and graphics and configuration files. And… don’t forget the love. Love takes space.

A few years ago, things were different. But today, I don’t even blink at the prospect of a 121MB download. And with download speeds being what they are these days, I only manage to blink about half a dozen times while it downloads…

I’ve finally made it to JavaOne. It’s my first time here and I have to admit that I’m a little overwhelmed. It’s a huge conference.

Today, the title of my blog is not an insane attempt to attract more traffic… I was working the Eclipse Foundation booth earlier today and was asked by a visitor about the possibility of building an Eclipse RCP application with a Swing-based user interface.

Why the heck would you want to do such a thing I can hear you ask? (actually, I think that might be somebody from the Oracle booth) There are several reasons. My favourite reason is Equinox. You can use the Equinox component framework under your Swing application. And if you do that, you can make use of things like extension points in your application. This, of course, makes your application very extendable. Of course, by using Equinox, you can also leverage the Eclipse update mechanism. Then, there’s help: you can probably use a little help with your Swing application. For me the biggest reason for using Equinox is simple: actual managed components.

By making your Swing-based user interface an Eclipse RCP application, you can make use of Eclipse plug-ins. Of course, if those plug-ins require SWT or the workbench to run (and you don’t want those things to be part of your application), you’re out of luck. But components packaged up as OSGi bundles can be used. So you could use the Hibernate bundles or package up other libraries that you might need as bundles to make them more easily updated later.

Running a Swing-based GUI from Eclipse RCP is pretty easy. When you generate an RCP applciation, it creates code like this:

public Object run(Object args) throws Exception {   Display display = PlatformUI.createDisplay();   try {       int returnCode = PlatformUI.createAndRunWorkbench(display, new ApplicationWorkbenchAdvisor());       if (returnCode == PlatformUI.RETURN_RESTART) {           return IPlatformRunnable.EXIT_RESTART;       }       return IPlatformRunnable.EXIT_OK;   } finally {       display.dispose();   }}

The createAndRunWorkbench(…) part is where (oddly enough) the workbench gets created and run (I do love descriptive names).

You can change it to instead do Swing stuff:

public Object run(Object args) throws Exception {   JFrame frame = new JFrame(”Eclipse RCP”);   frame.setLocation(50, 50);   frame.add(new JTextField(”Eclipse RCP application with Swing!”));   frame.pack();   frame.setVisible(true);   while (frame.isVisible())       Thread.currentThread().sleep(1000);   return IPlatformRunnable.EXIT_OK;}

So… if you have an existing Swing application and you want to take advantage of the great features provided by the Eclipse RCP, you might consider this as a first step in your migration.