Bees Are Social By Nature

Transcribed thoughts and experiences about computer programming.

A First Glance at jSeamless

After a few days of attempting to connect to, I was finally able to download the binaries and see if it was as wonderful as I hoped it would be. Since I had recently went through a quick implementation, though hack might be more appropriate, of a simple single player Blackjack game using Echo2, I thought it would be great to take the same logic and apply it to my first glance at jSeamless. I had the game, I just needed the user interface.

Using the HelloJSeamless Sample Application and the Eclipse Web Tools Platform, I was able to quickly get my development environment and my first project set up. I set the project to run on Tomcat 5.5, hit run, and the HelloJSeamless Sample Application was up and running. I am not a big fan of “Hello World” type applications as they don’t really show me much, but it was great that one was provided.

The next step for me was to see how easy it was to “port” my simple, and needlessly server-side, Blackjack game from Echo2 to jSeamless. As I started digging in, I realized that I had forgot to download any documentation or the source and found I was fumbling around in the dark, with nothing more than the jar containing the class files and the HelloJSeamless sample applications. I tried to go back to the website to get more information, yet the jSeamless site was experiencing technical difficulties to my great frustration, at which time I reminded myself that this is a Beta release. Being as determined as I am, I decided to work through to get some sort of working version by hoping my experience with Swing, QT, MFC, and other GUI Frameworks and the class files would allow me to come up with something that worked.

I quickly found classes like Window, Grid, Label, Button, Table, TableRow, TableCell, and Style and started to feel a little more comfortable. With some minor experimentation I was able to get a simple Window with some Labels and some Buttons. I set up the buttons to take my implementation of the ActionListener and implemented the action(ActionEvent) method and was confused because I couldn’t figure out how to drill down and get specific information about the ActionEvent that occured when a given button was pressed. My first pass at the code looked like:

public class JSeamlessBlackjack extends Application implements ActionListener {
public void initPane() {
hit = new Button("Hit");
public void action(ActionEvent e) {
// if () doHit(); I want to do some conditional on ActionEvent
// Since I don't have docs lets see what an ActionEvent has in it.
... more output statements

The results of this first pass, were simply Click and CLICK, with nothing to differentiate it from any other button that my ActionListener may have been listening to. As such, I was forced to implement as follows:

hit.addActionListener(new ActionListener() {
public void action(ActionEvent e) {
doHit(); }

While this isn’t “bad”, it’s just not my preferred way of implementing ActionListeners. Please note that I had no documentation at this point, so I had no idea if I had other options. I stumbled around for about an hour “porting” my Blackjack application, hit run, and I got decent results, which can be found at

The performance of my first application was not as good as I had hoped and the lack of documentation made this first experiment much more painful that I would have hoped. I just went back to the site, about an hour prior to this posting, and found that the site was operational again and I immediately downloaded the source and the javadocs. I have hopes that they will provide greater insight into using the framework, but my expectations are fairly low, as I keep forgetting this is a Beta version.

In the end, I wasn’t as “wowed” as I hoped I would have been, but I must say that Matthew Hicks has done some excellent work with this project. I realize I may voice some level of disappointment, but I had extremely high expectations. While those expectations were not met in his Beta 3 version, this is still GREAT stuff and I look forward to future versions, and maybe after reading the Javadocs and Source files I will appreciate what he has accomplished with jSeamless even more.

My extremely ugly hackage I call my JSeamlessBlackjack source can be found at

Update: Unfortunately, reading the Javadocs and Source for jSeamless provided no greater insight that just reading the byte-code.

May 30, 2007 Posted by | java, Programming, technology, Web 2.0 | 3 Comments

Introducing Myself to Echo2

On May 22, 2007, I read an article, jSeamless – UI Abstraction for Java, by Matthew Hicks, on that mentioned jSeamless 1.0 Beta 3 was available for download.  I had not been following these types of technologies, but the concept sounded extremely interesting to me.  As a former thick client developer, I thought the concept of developing an application without dealing with the mess of fusing HTML, JavaScript, CSS, and whatever backend I was dealing with at the moment, was very enticing.  As mentioned by Matthew Hicks, to also be able “develop your UI once and then deploy it as a web application and/or a desktop application without writing any additional code” got me very interested. 

With such a great introduction, I couldn’t help but immmediately head over to  Unfortunately, it appeared that others had also read the article and the site was not accessible, I recieved a connection timeout every time I tried to reach the site. I could not contain my excitement though.  I started reading what other people had to say about jSeamless and I noticed a framework called Echo2 was frequently referenced.  Since I couldn’t see what jSeamless was all about, I quickly headed over to

 While Echo2 did not offer the ability to deploy my application as something other than a web application, Echo2 does claim to “[remove] the developer from having to think in terms of ‘page-based’ applications and enables him/her to develop applications using the conventional object-oriented and event-driven paradigm for user interface development.” I thought this is what I am looking for, but I had my doubts as to it ability to deliver on this claim.  After taking a look at the demos on the site and doing some additional web search for tutorials using Echo2, I decided to try it out for myself.

For my first application, I decided to implement a simple single player Blackjack game.  The results, found at, were great.  Within a few hours, I was able to get a simple Blackjack game working.  For my first experience, I was greatly impressed.

I am definitely going to play around with Echo2 some more, yet I am now even more curious how frameworks like jSeamless compare.

I was able to quickly get started using Echo2 thanks to Deitrich Kappe’s Tutorial, Ajax with Echo2 and Eclipse, located at

For reference, I placed a zipped version of my code at

May 29, 2007 Posted by | java, Programming, technology, Web 2.0 | 2 Comments

Old News: Java Checked vs. Unchecked Exceptions

I know this is beating a dead horse, but I was recently part of a  discussion with a fellow developer that did not see the value of checked exceptions.  I realize my position is arguable, but I see checked exceptions as a valuable part of the Java language. Checked exceptions communicate to the implementor that the method being called may return with unexpected results and it is the implementors responsibility to deal with it appropriately.

I am a proponent of Programming By Contract for designing computer software.   Checked exceptions are an essentional part of this contract, especially when the method being called depends on the availability of an external system, such as a database, file system, network, etc.  The contract establishes that the “supplier” will operate perfectly in an ideal condition, yet should something unexpected happen that he cannot control, such as an intermittent network failure, then the “client” should be prepared to handle it accordingly, enabling some level of Fault Tolerance.  It could be argued that this information does not need to be forced or communicated within the code, yet I am personally very grateful that the contract can be so eloquently documented within the code.

A friend of mine argued that many of the Checked Exceptions in Java are really fatal errors and should be categorized as RuntimeExceptions.  While I am not willing to speak for all of the possible checked exceptions, some of the exceptions named were SQLException, IOException, and NamingException.  I argue that each of the above named exceptions are accurately identified as checked exceptions within Java.  An SQLException might just be describing a transient failure within the system and a robust system should degrade gracefully, reporting the error and alerting the relevant parties.  I would even go so far to say that a robust system should even self recover, should the issue with the external system correct itself, depending on the system requirements.  I am not going to qualify IOException and NamingException in this weblog entry, but the same sort of proper exception handling and reason for the handling applies.

I think effective exception handling is a lost art, or at least poorly utilized in much of the code I have read.  I can see why many developers may feel that checked exceptions are a waste, especially when I repeatedly see code that looks like

try { 
  // do something that can throw an exception. 
} catch (Exception e) {}

I must say this is a worst case scenario, but with the exception (wow a pun) of maybe adding a logging statement, it happens to be one of the most common errors I find in code using static analyzers, like FindBugs or PMD.

In his article, Effective Java Exceptions, Barry Ruzek does an excellent job at describing how a Java developer can make effective use of the Java exception model.  I realize he implies that in many cases IOException, and other checked exceptions, are often not recoverable, which differs, in part, from my position, yet his article captures the essense of how and why exceptions should be handled.  From his abstract:

One of the most important architectural decisions a Java developer can make is how to use the Java exception model. Java exceptions have been the subject of considerable debate in the community. Some have argued that checked exceptions in the Java language are an experiment that failed. [Barry Ruzek’s] article argues that the fault does not lie with the Java model, but with Java library designers who failed to acknowledge the two basic causes of method failure. It advocates a way of thinking about the nature of exceptional conditions and describes design patterns that will help your design. Finally, it discusses exception handling as a crosscutting concern in the Aspect Oriented Programming model. Java exceptions are a great benefit when they are used correctly. [Barry Ruzek’s] article will help you do that.

I am sure I haven’t even touched the surface on this topic, but I think there is enough here to start a decent discussion. 

May 24, 2007 Posted by | java, Programming, technology | 9 Comments