I don’t know that I’m such a big fan of IDE’s. They seem to run counter to the Unix Philosophy, which is to have a large number of small tools that do one specific thing, and do it very well. These small tools are all bound together through dead simple, absolutely standard and rock-solid message-passing interfaces (stdin, stdout, stderr; all parameters are Strings). A big IDE that attempts to do everything and the kitchen sink often just feels like the wrong level at which to be working. Certainly, for my current project, being strongly bound to Eclipse for development has so far been counterproductive. This is because the GWT-Eclipse tooling is not yet matured… which is to say that the GWT module concept is really very different from the basic Java package concept, and this is a gap that the current tooling does not yet bridge. The result, for me at least, has been a great deal of confusion. Then again, I’m attempting to use GWT for things for which it was never intended to be used

In any case, it has felt very good to ditch the IDE for a while and return to my humble yet powerful development tools: GNU Screen, Vim, Bash and Ant. I won’t describe here what these tools are or how to use them; this is covered very well in other places. But I will post a nice screenshot of my current desktop, which I feel is very close to complete User Interface zen:

One component currently missing from my toolbox is a good, preferably console-based file managers. I don’t really have very strong preferences with regard to file managers, but I really should, because there are many times when I could really use some powerful features. I just haven’t quite figured out what those are yet. Vi keybindings are a major plus, though. That rules out the famous midnight commander, unfortunately, as its keybindings are not configurable. Really, it only leaves two options: vifm, and a Vim plugin called VimExplorer. vifm was quite nice, a nice solid little file manager with vi-like keybindings. Unfortunately, it had some trouble installing on Ubuntu Hardy, and it was just different enough to what I was used to with a proper Vim instance to be annoying. That left me VimExplorer. I was a bit wary of this, because it hadn’t been updated since 2007, and the last update was to fix a critical bug that could cause data loss. But I installed it, tried it out, and found it to be quite good. It gives you a small file manager instance that lives right inside of vim. All of your vim skills then can be applied to managing files, including: regular expression search, macros, manipulating vim windows and buffers, and using “!” to trigger shell scripts. There’s something really great about being about to just say “yy” and then “p” to copy and paste a file. Same for move and delete.

Unfortunately, I still feel like this tool is lacking. 90% of what I do when developing is in done in just a few files and directories. What I want is to be able to just type the name of a file on my filesystem (e.g. “Accessibility.gwt.xml”), and immediately have an editor up for that file. The system should behave intelligently when there are naming collisions. I believe that GNOME-Do might actually be able to do this, and I should look into that. For the most part though, I think most of this could be accomplished by just tagging certain files or directories as favorites, and maintaining a simple hash to map short variable names to long paths. In any case, I’m continuing to iterate on this component of my set of simple tools.

I worked really hard today, and I have lots to report. I started at 6:30am and worked straight through on GSoC until about 7:30pm. I also spent some time investigating alternate tooling, and I’ll talk a bit about this in another post.

So, to recap, we have this stack: Demos/GEF/Draw2d/SWT/JRE. The goal of this week is to get Draw2d to compile under GWT. After that, I’ll have to try to get it to run, but for now, I’m just concerned with getting it to compile. This, of course, means figuring out what Draw2d’s dependencies are in SWT and the JRE, and where they are not satisfied, writing out stub code and small TODO comments. Also, I will atempt, where possible, to reuse the existing, non-functional code from the previous project that used GWT to compile SWT to js.

To summarize my experiences of today: JRE == SUCCESS, SWT == FAIL.

First some background: GWT already provides some JRE emulation, but it is not sufficient to compile the SWT codebase. To get SWT to compile, one must at least implement certain stub interfaces that GWT does not provide. There are additional issues, such as reflection, that may be more serious, and I’ll talk about those in a later post. The extension to the GWT emulation classes live in the project org.eclipse.swt.e4.jcl. Left over from the previous project were three GWT modules which I was never able to compile. Additionally, it was unclear to me how these modules were supposed to compile, as they used the GWT module “source” tag, rather than the “super-source” tag, which, according to all of the documentation I have read, is what one is supposed to use when implementing JRE classes.

Today, I successfully compiled the previous project’s JCL classes. In order to accomplish this, I applied Technique 1 from my previous post, which is to say, I added a prefix (“e4″) to the JCL packages, where before there was no prefix, and I used <super-source path=”e4″/> in my GWT modules. I had to futz a bit to discover in which order I should import the modules, but after that, they compiled without complaint, w00t

//TODO: insert complete project structure here

Note that, since yesterday, I have been developing this prototype outside of the Eclipse environment. My toolset has consisted of GNU Screen, Vim, a Vim plugin called VimExplorer, and Ant. This has allowed me to ignore all of the IDE-specific confusion that I have so far encountered. My next post will be about my experiences using some of these tools.

I was feeling very optimistic after succeded in getting JCL to compile, so I set it as my goal to get the necessary SWT libraries to compile as well. Unfortunately, I failed in this task, because, I believe, I took the wrong approach. The approach I took was to attempt to reuse directly the SWT emulation classes left over from the previous project, just as I reused the previous project’s JCL classes. Unfortunately, these SWT emulation classes had many missing dependencies. My strategy was to just keep hacking on it (adding in missing classes, stub methods, etc.), until the thing worked. I spent most of the afternoon working on this, probably about 4 hours. Ultimately, I ended up pulling in most of the code in “org.eclipse.swt/Eclipse SWT/common”. I didn’t get to the end of the dependency chain, but I think I got far enough along to recognize a trend that I wasn’t happy with, namely, pulling in dependencies that in turn rely on other dependencies, etc. It should be a major priority to limit dependencies, because the more deps I cut out, the less complex my project will be. Given that this project is still at the prototyping stage, reducing complexity is of critical importance.

Note that I also tried compiling “org.eclipse.swt/Eclipse SWT/common”, but this pulled in some native code which GWT was unhappy with. So, I really do need to be selective.

The alternative to today’s approach is to start at the top of the stack (work top-down) and discover what the dependencies are for the Draw2d demos; then, find out what the dependencies are for Draw2d; then, very carefully, attempt to pull in those deps from org.eclipse.swt, or stub them out. I intend to use Doxygen to figure out the complete dependency chain. This will be tomorrow’s work.

In short, there is a kind of impedance mismatch between the functionality that GWT provides the functionality that GWT’s Eclipse tooling provides, at least with respect to super-source. Here’s my understanding of how all of this breaks down:

1. You can use a package structure in which the native packages you would like to emulate (e.g. java.*) are prefixed by some other package (e.g. hack.java.io). So you might have a project structure that looks like this:

The Pros: This works great in both GWT hosted mode and compiled mode.The Cons: The Eclipse IDE will think that something is wrong with your package declaration (it thinks it should be hack.java.io), and will give you errors.

2. You can use a package structure which does not use prefixed packages. So, you have something like:

testsuper/

super/

test/

TestSuper.gwt.xml

test.java.io/

OutputStream.java

Your GWT module super-source tag would then use path=””.The package declaration in your emulated Java classes would then say “java.io”, as per normal.

The Pros: GWT Hosted mode works (although you must set the runtime classpath to point to whatever dependencies TestSuper has; you set this as an Eclipse run configuration), and the Eclipse IDE doesn’t throw errors.The Cons: GWT Compiled mode fails for the Eclipse GWT tooling, if you have projects that import this project, because the super/ folder is not on the Eclipse build path. If you were using Ant, this would not be a problem, because you can simply set the build-time classpath, but it does not seem to be possible to do this yet with the Eclipse tooling. Also, because super/ is not on the build path, you don’t get all of the advantages of the Java tooling that you would normally get from Eclipse.Workaround: Use ant within Eclipse to Compile, and use regular GWT for Hosted mode.

It’s important to point out that all of these issues are related to the GWT Eclipse tooling, not GWT itself. Nevertheless, for my project, I am strongly dependent on Eclipse, so it is necessary for me to find the best way to resolve these issues. I’m not 100% certain about this, but at the moment, I feel like my best option is to go with option 2.b., so to stay in Eclipse, but move all of the build logic to Ant.