Top-Down 1

Warning: Extremely Boring, Project-Specific Post

Moving forward. In the post before my last post, I mentioned the swtlibs.gwt.xml file which was confusing me. Here it is again:

<module> 
 <source path=""/>
 <source path="events"/>
 <source path="graphics"/>
 <source path="layout"/>
 <source path="widgets"/>
 <source path="dnd"/>
 <source path="printing"/>
 <source path="animation"/>
 <source path="accessibility"/>
 <source path="custom"/>
 <source path="graphics2"/>
 <source path="internal"/>
 <source path="net"/>
 <script src="swt/loading.js"/>
</module>

The thing that was confusing me was the path entries. One would assume that they are relative paths... and I've now decided that, in fact, they are. First of all, the GWT documentation makes it pretty clear that this is the case:

<source path="path" /> : Each occurrence of the  tag adds a package to the source path by combining the package in which the module XML is found with the specified path to a subpackage. Any Java source file appearing in this subpackage or any of its subpackages is assumed to be translatable. The <source> element supports pattern-based filtering to allow fine-grained control over which resources get copied into the output directory during a GWT compile.

But this was nonobvious in this case, because all of the paths referenced except for graphics and widget, are not accessible as relative paths. One could interpret them as being poorly-documented indicators of "future work", but only if the it was certain that the GWT compiler wasn't doing something clever like pulling in other, actual SWT folders on the classpath, that have the same name; for this to be true, the GWT compiler needed to be silently ignoring the missing referenced paths. To test this, I set up a sample GWT project with a source package that does exist. I also added a reference to a source package that did not exist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC "-//Google Inc.//DTD Google Web Toolkit 1.6.4//EN" "http://google-web-toolkit.googlecode.com/svn/tags/1.6.4/distro-source/core/src/gwt-module.dtd">
<module rename-to='test'>
  <!-- Inherit the core Web Toolkit stuff.                        -->
  <inherits name='com.google.gwt.user.User'/>

  <!-- Inherit the default GWT style sheet.  You can change       -->
  <!-- the theme of your GWT application by uncommenting          -->
  <!-- any one of the following lines.                            -->
  <inherits name='com.google.gwt.user.theme.standard.Standard'/>
  <!-- <inherits name='com.google.gwt.user.theme.chrome.Chrome'/> -->
  <!-- <inherits name='com.google.gwt.user.theme.dark.Dark'/>     -->

  <!-- Other module inherits                                      -->

  <!-- Specify the app entry point class.                 -->
  <source path="exists"/>
  <source path="doesnotexist"/>
  <source path="client"/>
  <entry-point class='foo.bar.test.client.Test'/>
</module>

End result: the Java classes in subpackage exists were found usable in both hosted mode and compiled mode. The compiler just ignored the reference to a package that did not exist.

So what does all of this finally mean for my project? It shows me the scope of the SWT emulation that they had at one point presumably been working. At the very least, it sets an upper bound on the work that was done in this regard: emulation of graphics and widgets package. That's all. But they were aiming to emulate the entire SWT library.

With that in mind, I dug a bit deeper into the widgets package. As expected, there were a bunch of methods using JSNI. Not the nicest JavaScript code... But I won't criticize it to much, as I understand that it never got past the prototype phase.