Generic JavaScript Array for GWT objects

GWT supports several wrappers for JavaScript arrays, e.g. JsArray, JsArrayNumber and JsArrayInteger. However, they all require JavaScript primitives or JavaScriptObjects. I needed to pass a JavaScript array containing regular GWT objects to a third party JavaScript library, together with a callback function that resolves specific properties for elements in the array. The skeleton of the array is similar to the JsArray classes provided by GWT (full source code):

import com.google.gwt.core.client.JavaScriptObject;

public class JsGenericArray<T> extends JavaScriptObject {

  // typical JsArray methods

}

I initially tried to use this array with the following factory method:

  public static native <T> JsGenericArray<T> createGenericArray() /*-{
    return [];
  }-*/;

However, I ran into the problem that instanceof Array tests on this array in the 3rd party libraries returned false (as debugging showed). This is because GWT runs in an iframe and instanceof does not work across frames. One recommended solution is duck typing, but this was not an option because I did not want to change the 3rd party JavaScript library. To address this issue, I changed the factory method to return an array object from the main frame in which the JavaScript libraries run:

    public static native <T> JsGenericArray<T> createGenericArray() /*-{
        return new $wnd.Array();
    }-*/;

This approach worked with Firefox 3.6 and Chrome 9, but not with Safari (see Webkit Bug 17250). However, I am not a JavaScript expert and would appreciate any feedback on potential shortcomings of this solution, especially concerning cross-browser compatibility.

Slides of InfoVis 2010 presentation "How Information Visualization Novices Construct Visualizations"

I presented the paper "How Information Visualization Novices Construct Visualizations" at IEEE InfoVis 2010 in Salt Lake City. Here are my slides:

Choosel at VisWeek 2010 and at CASCON 2010

Interested in data visualization on the web? There are several Choosel-related events at VisWeek 2010, CSER and CASCON 2010. Choosel is an open-source framework for browser-based data visualization.

Watch video in full screen and HD for better quality

Oct 24-28, I will present the InfoVis poster "Choosel – Web-based Visualization Construction and Coordination for Information Visualization Novices" at VisWeek 2010. Here is a preview:

Oct 31st, there will be a presentation on Choosel and the Work Item Explorer at CSER. The Work Item Explorer (developed by Patrick Gorman, Del Myers and Christoph Treude) is a research prototype built on Choosel that facilitates the flexible, iterative exploration of Jazz data, focusing primarily on work items.

Nov 1-4, there will be CASCON exhibits on Choosel and the Work Item Explorer. The Choosel exhibit (Bradley Blashko, Lars Grammel) will be at booth X2 near the Central Tower, and the Work Item Explorer exhibit (Patrick Gorman, Christoph Treude) will be at booth U5. The exhibits are open 5pm to 7pm on Monday (Nov 1), from 8.30am to 7pm on Tuesday and Wednesday (Nov 2 and 3), and from 8.30am to 1pm on Thursday (Nov 4).

Attracting the Community’s Many Eyes: an Exploration of User Involvement in Issue Tracking

User input drives the development of software systems by contributing ideas, reporting bugs and clarifiying requirements. To encourage such feedback, open source projects often provide issue tracking systems (e.g. Bugzilla) that are open to the public. In commercial software development, however, this is often not the case. I was interested if opening issue tracking systems of commercial projects to the public would yield similar community input as is the case for open source projects. Together with Holger Schackmann, Adrian Schröter, Christoph Treude and Margaret-Anne Storey, I studied community involvement in issue tracking in the Eclipse and IBM Jazz projects. IBM Jazz is a commercial IDE for collaborative development. The Jazz project has opened its issue tracking system to the Jazz community. Eclipse is a well-known open source IDE with a public issue tracking system.

Our 8 page research paper "Attracting the Community’s Many Eyes: an Exploration of User Involvement in Issue Tracking" was accepted at HAoSE 2010, the Second Workshop on Human Aspects of Software Engineering, co-located with SPLASH 2010. Here is the abstract of our paper:

A community of users who report bugs and request features provides valuable feedback that can be used in product development. Many open source projects provide publicly accessible issue trackers to facilitate such feedback. We compare the community involvement in issue tracker usage between the open source project Eclipse and the closed source project IBM Jazz to evaluate if publicly accessible issue trackers work as well in closed source projects. We find that IBM Jazz successfully receives user feedback through this channel. We then explore the differences in work item processing in IBM Jazz between team members, project members and externals. We conclude that making public issue trackers available in closed source projects is a useful approach for eliciting feedback from the community, but that work items created by team members are processed differently from work items created by project members and externals.

Download Paper

GWT ArrayList, HashSet and JsArray Benchmark

The performance of GWT applications varies quite a bit between the developer (hosted) mode and the compiled JavaScript code, as well as between different browsers. This blog post describes a benchmark [ Run Benchmark, Source Code ] of two different collection classes (ArrayList, HashSet) in three different environments (Chrome 6, Firefox 3.5, Dev Mode). It tests the add, contains and iterator methods, and also compares the collection classes to a lightweight JavaScript array wrapper.

The three benchmarks do basically the following:

• The add benchmark adds 100 items to an empty collection.
• The iterator benchmark iterates over an collection of 100 items.
• The contains benchmark checks if 20 items are contained in a collection of 100 items. 10 of those items are contained in the collection, and another 10 are not.

Each benchmark is run 2500 times (see GWTBenchmark class).

The results I report here are rough averages from repeated measurements (~20 times) on a Core 2 Duo 2.4 GHz machine with 4GB ram, running Windows 7 64bit and GWT 2.0.3. They should be accurate with about +/- 10% error.

	Chrome 6.0.472.63 beta	Firefox 3.5.13	Dev Mode (FF 3.5.13)
add - ArrayList	19 ms	550 ms	14 ms
add - HashSet	200 ms	680 ms	30 ms
add - JsArray	14 ms	540 ms	142000 ms
iterator - ArrayList	44 ms	395 ms	12 ms
iterator - HashSet	138 ms	1220 ms	8 ms
contains - ArrayList	4700 ms	8500 ms	37 ms
contains - HashSet	23 ms	110 ms	6 ms
contains - JsArray	8 ms	36 ms	26500 ms

Several things can be observed based on these results:

Measuring and optimizing performance in the developer mode is useless and can be dangerous. The developer mode is very different from running compiled GWT code in the browser. Code that is executed only within the Java VM tends to be a lot faster. Manipulation of the DOM and calling JavaScript using JSNI, however, is much slower (see also GWT developer guide). I was surprised by the extent of this effect, for example that Java collections are up to 125 times faster than GWT compiled code on Chrome 6 (ArrayList.contains), or that JsArray.contains is 736 times faster when compiled and run on Firefox 3.5 vs. in the developer mode on Firefox 3.5.

Chrome 6 is much faster than Firefox 3.5. This result is pretty obvious given recent browser benchmarks. However, the differences vary depending on the collection type and operation. ArrayList.contains is surprisingly slow on Chrome 6.

The different collection classes have different advantages. This is also pretty obvious given their different requirements and algorithms. The HashSet is slow for add and iterate, but fast for checking the containment of items. It also assures that each element is only contained once. The ArrayList is much faster than the HashSet when calling add and iterate, but also 200 times (Chrome 6) / 77 times (Firefox 3.6) slower when it comes to containment checks, which was surprising.

Potential speed gains when using handcrafted collection classes. The results for the JsArray class indicate that there is a potential for speed improvements by using lightweight collection classes. This finding is different from a benchmark that used bubble sort. The difference might be related to the overhead added by the GWT cross-compilation of ArrayList and HashSet.

In conclusion, when having performance issues in GWT applications that use a large number of collection instances, it might be worth looking at using optimized collection classes that reduce the overhead introduced by ArrayList and HashSet.