Eclipse is actually one of the less buggy of applications. It doesn’t crash every three minutes like Bloodshed Dev-C++, it doesn’t crash every two minutes like Internet Explorer, and it doesn’t crash every minute like Windows. The Java development environment is beautiful, the task management system is well-designed if poorly-integrated, and the C++ development environment is second only to Emacs, Vim, Ed, and the ever-elusive butterfly technique (its not actually that great). Eclipse has a unique system of managing views and perspectives that allows a huge amount of flexibility to the user. But Eclipse’s plug-in development environment is less than satisfactory to the developer.

To begin with, Eclipse plug-ins are based on a less-than-easy-to-use API. Sure, its easy to do the things the designers anticipated you would be doing – like compiling their sample projects. But there’s no level of abstraction between “here’s a method to do exactly what you want” and rewriting half the API from scratch. Furthermore, the Eclipse developers insisted on creating their own system for everything, from user interface functionality to file system access. A good deal of the documentation is totally obscure, and the sample projects are no help.

Now suppose you’ve suffered through the experience of writing a plug-in, you’re almost done, and you’re ready to export. Or more likely, you’ve just begun, and you’re ready to export just to see what happens. There’s just one little problem – that tiny icon over in the “package explorer” with the red X or the yellow exclamation point – Eclipse doesn’t like something. Such was my situation as I was trying to export my plugin, so that I could export my feature, so that I could test my update site.

Now if you’re lucky – and odds are you’re not – that little icon will be over a “.java” file. That means you messed up your Java code, and that can be fixed with relative ease. If you’re unlucky, that icon will be over the build.properties or MANIFEST.MF file. You double click on that file, glance through the tabs, and discover that in none of the tabs does Eclipse have a complaint.

So I think to myself (or you think to yourself), “oh, I’ve been here before. I just have to look really carefully, and I’ll find it.” Now, I think that memory is actually a dream. The technique didn’t work. Ok, maybe Eclipse is caching something. Nope, restarting Eclipse doesn’t help.

The end result was that I went to the tab ”plugin.xml”, went through the source code, found the error, went to the related part of the wizard, and fixed it. But that’s not what happened next.

I decided that the warning probably didn’t matter, so I went right ahead and created my update side. Oops! It won’t let me add plug-ins, I can only add features. Ok, that’s fine, I’ll create a feature with one plug-in in it, and add it. I create the feature – no problems there. I add it to the update site – no problems there. I click ‘build all’, thinking, “wow, this is easy!”

Nothing happens.

I remove the feature and put it back in. Doesn’t help. I create a category and put the feature in it. Doesn’t help. Finally, I decide to go back and fix the plug-in. I finally land upon the correct tab, find the problem, find the associated part of the wizard, and fix it. I go back to the update site, remove the plug-in, add the plugin, and click ‘build all’. The progress bar scrolls nicely along, and then I refresh the project. Tada! Lots of new material. I look through it and like what I see. Now I’m ready to place this site online.

I create a new directory in my raw data folder (created as an easy way to avoid ending up with my serving script happily spitting out its own source code, passwords and all) called “eclipse-update” and copy the whole mess produced by Eclipse into there. The content.xml file is surprisingly large, but at this point I don’t have enough curiosity to find out what’s in it. Now, as a test, I go there in my web browser. Here, that is. And what I get is:

In case you can’t make it out, it says “undefined”. I look at the source code, and it is just one big mess of Javascript.

So again, I try to just accomplish the goal, and leave all the niceties to rot. For once, things decide to start working. I add the update site, and everything shows up properly. I select “Team 449 Eclipse Plugins” and click ‘install’. The progress bar moves, albeit somewhat sluggishly, my Internet connection falters but does not die, and the selected items install. Well, sort of. There was just the little glitch of, Eclipse appeared to think that every plugin I had installed on my machine was a dependency for the one I had created, so I made a mental note to fix that. Other than that, there was no problem installing.

Now its back to fixing the niceties. With my fingers crossed, I go to the index.html page again, and check firefox’s error console for errors it produced. If there were any, fixing them should be easy. Nope, none (save for some CSS errors). Great. Now I go to the source code. Here it is (without the HTML):

Ahh…. This makes some sense. First, I note that IE is treated differently. Does the IE version work? Yes! Now we can ignore all the non-IE parts. I pull up Safari 4 Beta and test it there. It doesn’t work there instead: I get the popup error message “document could not be loaded by browser”.

This is an important clue, since I know that this error message is only supposed to pop up when xmlFile.load, which is a function, does not exist. On the assumption that xmlFile is a document, I search and discover that even the examples on W3Schools don’t work on Safari. Great – the one browser that passes Acid3 doesn’t even support “standard DOM Level 2 techniques”.

This just leaves Firefox. Suspecting that the problem lies in transform(), I add alert() statements for each variable. My discovery is that everything exists but doc.documentElement.innerHTML. After experimenting around a while, I decide that it is probably the fault of Firefox. Just to be sure, I navigate to some other update sites. I get a variety of results, including raw xml, but none of them actually work.

The Answer

Be sure there are no warnings in any build.properties files by going to the tab that contains the xml code, finding the error, and correcting it by finding the related part of the other pages. Then remove from and place back in the update site the affected plug-ins. Build your update site, and then refresh the project so that you can see what’s going on.

You can just use an ftp client to upload the files now, and your update site will be working. Be sure to copy all of the files to your host server. Your update site html page will not work in many browsers, so you should write your own.

we would have the Java code:

This makes it easy to convert C++ to Java code, and vice versa. In fact, if your code is longer than 100 or so lines, it’s probably best to just write a script to do the hard work for you. The packages to include are javax.media.opengl.* and javax.media.opengl.glu.*. As far as I know, there is no support for GLUT, at least with this particular Java OpenGL binding. The boilerplate code for Java is below.

Now for people who are new to OpenGL. To set up a decent-looking three-dimensional scene (if you don’t want all three dimensions, don’t use opengl), you need three things – the lighting settings, the material settings, and the content (the position of the camera is taken care of in the boilerplate code above – if you want to more the camera, you can cheat and move the scene itself instead). The material itself is easiest. The four main functions are gl.glBegin(), gl.glEnd(), gl.glVertex3d(), and glu.gluSphere. Use the first three together, to draw lines, and polygons; however, our example only uses spheres. Draw a sphere with glu.gluSphere(glu.gluNewQuadric(), radius,50,50).

And now, for your coding pleasure, I present you with a complete code listing for a simple application to show the moon orbiting the earth. I’ve set it up so that the viewer rotates about both.

To show the FFFrame, just call new FFFrame().display().

The programmers in question wanted to design a system in which, so long as the number of button presses was less than the number of lines in a certain file, pressing the button would retrieve the next line, process it, and print out the result. They did this as follows (I’ve made some modifications for readability):

From the programmer’s standpoint, I suppose this actually is the intuitive way to do it. If the user wasn’t involved, we would just loop until there were no more lines, but since the user is involved, we have to wait for the user to press the button, hence the while loop. Nevertheless, this is a Very Bad way to do it. While in the loop on line 5, we are using 100% CPU, even though all we are doing is waiting. If we want to do another operation at the same time, we are doomed.

When programming an event-driven system, you have to think from the user’s standpoint. And as far as the user is concerned, the mouse click on the button should be the cause of processing of the line. Hence the term “event-driven” programming. The correct code would be.

These two code snippets are almost functionally the same. The difference is subtle, but there.

Suppose the function processLine() takes a significant amount of time, like maybe three seconds. In the first code sample, if the user presses the button again before the first call to the function processLine() has completed, nothing will happen until the call has completed. In the second version, processLine() will be called immediately, resulting in two instances of processLine() running at the same time. If they share resources (including the output buffer), then things might not work properly. The solution is to synchronize them – something you may have seen if you have done multi-threaded programming.

The first and third versions of the code are functionally the same, but the third one does not use 100% CPU. Waiting for stuff to happen should never be CPU-intensive – if it is, you’re doing something wrong.

Java lends itself particularly well to plugin systems, since classes are loaded dynamically anyway. The idea of a plugin system is to modify how Java loads things. Normally, Java will load your program from the class files in its directory or jar file. When creating a plugin architecture, you want it to also load classes from different jar files (generally the jar files in a certain directory). The solution is to create your own version of the ClassLoader.

Most of the code below is just to navigate the jar files. In the execution of the application, a PluginReader is created for each jar file in the plugin directory. The read() method is then called (line 39), which first fetches a manifest file named “MANIFEST.GMF” which contains the name the actual plugin class (the class that has information like author’s name, as well as functions for starting the plugin running). This class is then loaded, and the class itself is registered with PluginUtils, so that it shows up as an option on the application screen. Then, all the other classes are loaded via the same method (but they are not registered), so that they can be used by the plugin. Finally, copyFiles is called, which copies the entire contents of the jar file to a temporary directory, so that the plugin can fetch graphics and stuff if it wants (using a path conversion method that takes a jar file path and turns it into a temporary directory path).

The real meat is at the very end: line 206 and on. Here, we define a ClassLoader that takes as an argument to its constructor a JarFile, and can be used to load classes from that JarFile. But the real beauty of the ClassLoader is not simply that we can load classes from a jar file, its that when those classes then want to load more classes or find more resources, it is still done within the context of the jar file. Which means that we don’t have to be 100% thorough, we just have to get the plugin going – Java will be happy to handle the rest for us.

Creating a class is simple. We just have to read in a .class file and call the ClassLoader’s defineClass method – in this instance, using our own createClass method as a proxy (just for convenience).

The key lines of code are displayed below, followed by the whole file.