Terminally Incoherent

I’m actually to lazy to write a full argument here, so I will just post my bullshit filler crap from a recent research paper:

5.3 Designing a Graphical User Interface

The discussion of GUI design should start by choosing appropriate widget toolkit. Java offers developers several attractive graphical environments. We will first take a closer look on each of them. Visualization details will then be explained in terms of that chosen toolkit.

5.3.1 Choosing a Widget Toolkit

There are three competing major widget toolkits that can be used for building graphical user interfaces in Java: AWT, Swing and SWT. Both AWT and Swing are currently included in Java Standard Edition, while SWT is an external set of libraries that needs to be downloaded and deployed separately.

The AWT toolkit was the first widget system implemented for Java. It is composed from fairly simple wrapper classes which in turn make calls to the native windowing environment to display GUI elements. Since each platform has a different set of native widgets, Sun only included the most basic ones in AWT [37].

Swing toolkit was developed in 1998 as a replacement of AWT. It abandoned the idea of using the systems native windowing environment, and designed a complete, feature rich widget toolkit entirely in Java. Swing is still in active development, and offers an impressing number of different graphical tools and GUI elements to the developers. For example, the package included in Java 1.4 includes 85 public interfaces, and 451 public classes [40].

The pure Java implementation however has proved to be both a blessing and a curse for this toolkit. Since Swing elements are really Java objects, they can only communicate with the underlying operating system through the JVM. In some cases this can create significant overhead, and thus Java based interfaces will often appear
to be less responsive, or slower than their native counterparts [37].

The Standard Widget Toolkit (SWT) [41] developed by IBM is a hybrid between Swing and AWT. It combines both approaches by including both calls to native widget elements, as well as implementing pure Java based ones. This helps to significantly improve the performance without sacrificing any of the advanced features one may
look for in an enterprise grade product [37].

The difference in performance, and responsiveness between Swing and SWT however is widely disputed and highly controversial. For example some benchmarks claim that Swing can outperform it’s competitor with respect to speed of rendering and re drawing windows on non-windows platforms [42]. Thus is is not very clear if SWT is really faster than Swing, or if overhead of the native calls and communication between Java and non-Java elements diminishes any performance gains stemming from using a native widget implementation.

Benchmarking the two toolkits is out of scope for this paper, and thus we chose Swing as our GUI toolkit because it is a Java standard, and it reduces the complexity of our code by eliminating dependency on a third party library.

Bibliography

[37] S. Holzner, Eclipse: Programming Java Applications. O’Reilly, 2004.
[40] R. Eckstein, J. Elliott, B. Cole, D. Wood, and M. Loy, Java Swing. O’Reilly, 2002.
[41] “The standard widget toolkit,” IBM. [Online]. Available: http://eclipse.org/swt
[42] I. Kriznar, “Swt vs. swing performance comparison,” Cosylab D.O.O, 2005. [Online]. Available Here

© 2007 Lukasz Grzegorz Maciak

I pulled the above from a draft version because it’s late, and I don’t feel like locating the finalized reviewed document. So there might be typos and grammar errors in there - which is of course nothing new around ere.

I ended up using Swing, and perhaps it was not the best choice. Not for an image processing application perhaps. So you tell me. Which one is better in your experience. Is SWK really that much faster than Swing? Is the added speed worth the hassle of bundling it with correct SWK packages for correct systems?

I would love to hear from bit SWK supporters - what are the best selling points of this widget kit over Swing, other than the speed? Anyone knows any good benchmark tests that were done to compare these?

I will have to make this same decision for another project soon, and as usual I’m not entirely convinced which one to choose. I’m leaning towards Swing because I worked with it before, and I know at least some of it’s quirks and pitfalls to be avoided. SWK would be a completely new ballgame.

What do you think?

I was messing around with the Apache Xerces based XML DOMParser class (from the com.sun.org.apache.xerces.internal.impl.xs.dom package)for the JTwitt project and I noticed some quirky behavior. I used the following snippet of code:

DomParser parser = new DOMParser();
parser.parse(new InputSource(xmlStream));
Document d = parser.getDocument();

Pretty straightforward stuff - in fact, you probably find the same few lines in just about every single DOMParser tutorial out there. The xmlStream is an InputStream instance object with the XML data. Where do I get it from? I pull it off the Twitter as I described here. I tested this code before, and got the XML to print out in the console so my InputStream is not the issue here. Every time I called the parse method I got few dozen errors like this:

s4s-elt-character: Non-whitespace characters are not allowed in schema elements other than ‘xs:appinfo’ and ‘xs:documentation’

It was basically one error per each node which had text data as a child. I was googling this message for hours and it seems that no one has a clue what causes it. I’m definitely not the first person who got it, but I have yet to see a working solution.

In the end I decided to abandon DomParser. There is about a bazillion different ways to parse XML files in Java so I simply switched to the JAXP parser (javax.xml.parsers). Now my code looks like this:

DocumentBuilder builder = DocumentBuilderFactory.newInstance().newDocumentBuilder();
Document d = builder.parse(xmlStream);

Both snippets are essentially equivalent and achieve the same thing. So as far as I’m concerned DocumentBuilder > DOMParser. Still, if anyone has a clue what is that s4s-elt-character error all about, please leave a note in the comments so that future generations do not have to suffer because of it.

As you may or may not know, I’m working on a Java based Twitter client recently. Sending and getting data from Twitter is really, really simple. Here is how to do it in Java.

Let’s assume that we are trying to post an update to twitter with the following data:

String username = "someone@example.com";
String password = "password";
String status = "Look! I'm twittering using Java";

Twitter uses basic HTTP authentication which requires you to send a username:password pair encoded in base64:

String cridentials = new sun.misc.BASE64Encoder().encode((username + ":" + password).getBytes());

Now let’s create a HTTP connection:

URL url = new URL("http://twitter.com/statuses/update.xml");
URLConnection conn = url.openConnection();
conn.setDoOutput(true);

Authentication is activated like so:

conn.setRequestProperty ("Authorization", "Basic " + cridentials);

Now we can send the update by simply writing to conn’s output stream:

OutputStreamWriter wr = new OutputStreamWriter(conn.getOutputStream());
wr.write(data);
wr.flush();
wr.close();

Finally, if you wand you can grab and print out the XML response sent back to you by Twitter server:

BufferedReader rd = new BufferedReader(new InputStreamReader(conn.getInputStream()));
String line, output = "";
while ((line = rd.readLine()) != null)
{
System.out.println(output);
}

That’s it - that’s all you need to do.

Now that my thesis is done, I feel that my procrastination skills might get bit rusty. Or even worse, I might start using them at work. Oh wait, never mind - I already do that. Either way, I need more exercise in extreme procrastination.

So, I figured I need a project. Something that I could neglect, put away for later, and generally feel guilty about not doing. Yes, that is exactly what I need.

So for the lack of better ideas I created a Java Twitter Client project on Google Code. Note that I haven’t written a single line of code yet. I haven’t really did much research on this either, beyond scanning through the Twitter API.

Why twitter? Perhaps because twitter is cool. It is still very hot on teh internets, and it’s API seems relatively straightforward. I’m not really looking to compete with Twitterific, Twitteroo and similar clients. This is more of a fun project for me to mess with.

Any input would be greatly appreciated. If you want to get involved and help out with coding, testing or whatever, let me know and I’ll add you to the project. Note that you will need a google account. If this project ever goes anywhere, we can always move it over to Source Forge. Google Code seems sufficient for now.

Of course I could host it here. I have subversion running on this very server. But Google Code offers integrated Wiki, and a bug tracking system which is nice. The 100 MB quota is kinda lame. Come on Google, I get 3 gigs for email, but only a hundred megs for code? WTF? Still, my current Eclipse workspace with 17 different projects in it, is only 30 MB. It should be enough, at least for the time being.

So, what do you guys think? Suggestions?

I decided to implement the Ackermann function in Java using the BigInteger class. Mainly I wanted to see something generating really big numbers, to see how the class scales. Ackermann seemed to be a good place to start, because this recursive function grows really fast.

My second goal was to see exactly how slow Ackermann would really be with bigger numbers. I admit that I was intrigued by the supposedly scarry xkcd number which can be obtained by calling Ackermann with Graham’s Number as both parameters.

Here is the code:

public static BigInteger ackerman(BigInteger m, BigInteger n)
{
	BigInteger r = null;
	if(m.compareTo(BigInteger.ZERO) == 0)
		r = n.add(BigInteger.ONE);
	else if(m.compareTo(BigInteger.ZERO)>0 && n.compareTo(BigInteger.ZERO)==0)
		r = ackerman(m.subtract(BigInteger.ONE), BigInteger.ONE);
	else if(m.compareTo(BigInteger.ZERO)>0 && n.compareTo(BigInteger.ZERO)>0)
		r = ackerman(m.subtract(BigInteger.ONE), ackerman(m, n.subtract(BigInteger.ONE)));
	return r;
}

I did couple of test runs and it gave me the same results as the ones shown in Wikipedia article. It seems that the second parameter of the function really doesn’t impact the performance that much. I ran ackerman(1, 10000) and it finished in 1314 milliseconds. Running it with 100,000 gave me a stack overflow error. What I see happening there is many, many recursive calls one after another. We are dealing with pretty big numbers here so no wonder that it craps out.

This tells me that, just as I expected Ackermann can’t be effectively implemented just BigInteger because our memory is limited. So we have to be clever here, and write stuff out to disk before taking each recursive branch - this will of course be slower, but the practical limit then is holding two BigIntegers in memory.

Interestingly enough, the first Ackermann attribute is the one that affects performance. I ran ackermann(4, 1) and it was chuging along for around 3 hours before I killed it. Please check the code and tell me if this is an infinite loop, or is this functionreally that slow? I’m not sure at this point. But if it is this slow, then the xkcd number is really, really scarry.

Now… Would it be possible to paralellize the Ackerman function? I’m not sure - because of the recursive nature this might be tricky. I will have to ponder this for a bit.