Bypassing Java Checked Exception Verification

So, Java checked exceptions. Of all the Java hot-points, this one still has the power to invoke avid flame wars between those who feel they make the platform “enterprise” class and those who are so disgusted with writing try/catch blocks to wrap them that they are willing to defect to .Net & C# simply to escape the drudgery of it all (.Net does not have checked exceptions).

Now, to be honest, while I have tried to look at the issue from multiple perspectives over the years, I tend to find myself leaning toward the latter camp for one very simple reason:

Checked exceptions are great in theory, but in practice lots of developers use them poorly and then the rest of us are left to clean up their mess.

Truthfully, as a developer that’s somewhat par for the course, you get used to paying for the mistakes of other developers and to be honest I know that when pressed for time I’ve written less than stellar code that I’m sure someone else has had to clean up. It’s just part of being a developer.

However, the problem with checked exceptions is that when they are done wrong you suffer in really really ugly ways that take your suffering to completely new levels. In this article I’m going to first cover some of the various problems that exist with using checked exceptions and then… for the finale, I’m going to show you a technique I’ve started using in the ThinWire Ajax framework and other projects to force checked exceptions into behaving like plain old RuntimeExceptions. Yup, you read that correctly. If you just can’t wait to see how that’s possible, you can jump to the end.

Adventures with java.sql…

To get started, the most common way checked exceptions make you suffer is when you are forced to deal with an API that has chosen to throw checked exceptions whenever anything at ALL goes wrong. A classic and widely known example of this is the java.sql API. I’ve been fortunate enough to avoid having to write much code against that API and when I have had to use it, I’ve usually developed a pattern that makes working with bearable. However, as I mentioned, the real problem is not necessarily the code you write, it’s the code other’s write and I know I’ve seen one too many code blocks that look like this:

A real-life in the wild example

public void testRetrieval() throws SQLException, IOException {    try {        Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");    } catch (java.lang.ClassNotFoundException e) {        System.err.print("ClassNotFoundException: ");        System.err.println(e.getMessage());    }

    try {        Connection con = DriverManager.getConnection("jdbc:odbc:test",                "user", "password");        System.out.println("Connection To The Database Established...");        stmt = con.createStatement();    } catch (SQLException ex) {        System.err.println("Connection SQLException: " + ex.getMessage());    }}

public Info getData(String rNum) {    Info info = new Info();

    try {        ResultSet rs = stmt.executeQuery("select * from itable where po =" + rNum);

        if (rs.next()) {            info = getResultSet(rs);        } else {            //do nothing        }

        rs.close();    } catch (SQLException ex) {        System.err.println("SQLException: " + ex.getMessage());    }

    return info;}

public Info getResultSet(ResultSet rs) {    Info info = new Info();

    try {        info.setPo(rs.getString("po"));        info.setType(rs.getInt("type"));    } catch (java.sql.SQLException se) {        System.out.println("Info retrieval from ResultSet failed." + se);    }

    return info;}

Putting aside some of the more obvious coding issues this developer has made, ask yourself whether there is any benefit whatsoever provided by the exception handling that this developer is doing? The answer should be no. Sure, you can argue all you want about what the developer should do, but the truth is that a LOT of developers write code just like this when using the java.sql package… and then you get to be the lucky one who has to decipher it. Here’s the same code without the pointless checked exception handling:

Real life example without checked exceptions

public void testRetrieval() {    Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");    Connection con = DriverManager.getConnection("jdbc:odbc:test", "user", "password");    System.out.println("Connection To The Database Established...");    stmt = con.createStatement();}

public Info getData(String rNum) {    Info info = new Info();    ResultSet rs = stmt.executeQuery("select * from itable where po =" + rNum);

    if (rs.next()) {        info = getResultSet(rs);    } else {        //do nothing    }

    rs.close();    return info;}

public Info getResultSet(ResultSet rs) {    Info info = new Info();    info.setPo(rs.getString("po"));    info.setType(rs.getInt("type"));    return info;}

That’s a little bit clearer don’t you think? The more savvy of you might be balking at the lack of proper Statement & ResultSet closing within a finally block, but keep in mind that the developer wasn’t doing that anyhow and additionally the use of a finally block has nothing to do with the handling of checked exceptions.

Different Recovery Strategies

Now, I want you to consider something else about this code. What do you suppose you could do to reasonable recover from an exception being thrown by any random java.sql method? Lets see:

Option 1: You could retry the whole block I suppose, but without extensive investigation of the SQLException details and a solid understanding of the error states presented by the specific DB you are connected to, that would really just be a shot in the dark.

Option 2: You could log all the exception details so that it’s easier to troubleshoot. But wait, wouldn’t it make sense to handle that in a centralized place further upstream in your code? Oh, I know… throw another exception that your upstream code catches! Although that’s somewhat repetitive when you think about it. You catch an exception just so you can throw it upstream. Hmm.

Option 3: Well, I guess you could log the details and return a default empty value or default object and then your upstream code could still process the empty value, but that seems kind of senseless. You’d either have to write your upstream code in such a way that it made sense to process an empty value or you’d have to write it to detect the empty value and treat it like an error has occurred. But wait, wouldn’t that kind of put you back into the same mode of development that used to exist prior to exception handling in languages? The kind of development where you always have to check the return value to see if an “error-value” was returned. I shudder at the thought!

Handling Checked Exceptions Sensibly

So, hopefully you see what I’m saying here. Generally, there is very little you can do to sensible respond to an SQLException, at least not that close to the SQL code. This leads me to Option 4, which is hardly ever used, but is in fact the most appropriate way to handle this case: Declare your SQL processing method declarations with “throws SQLException” on the end. The theory here is that somewhere up the call stack, in code that the SQL processing methods do not know about, there is a place in the application where the current “Operation” began and it is at that point in the application that you can generally handle an exceptional situation the most gracefully.

For instance, a web application may receive a request to display a specific record. In response, the application prepares a pretty HTML view that contains a number of sections, such as a header, footer, navigation, top-level record information and finally the specific details of an item. To assemble all of the information, the view will likely call out to entity objects, other framework layers or at the very least other methods to retrieve the data records. Whatever the structure, the point is that it’s in the view presentation code that it’d make most sense to setup a try/catch and often times that’s a few method calls removed from the SQL code. In the simplest case you could just wrap the whole body in a try/catch, excluding the header/footer/navigation sections, and then if a failure occurs you could display an error message in the body while still allowing the user to attempt to navigate to other parts of your application.

Third-Party API’s Prevent Elegant Handling

Unfortunately, even if the developer gets smart and decides to try something like this, they often times run into another major issue with checked exceptions. Declaring that a method throws a checked exception, binds the method that calls it to the contract of either handling the checked exception or declaring that it also throws the exception. So by placing “throws SQLException” on all the methods, you’d be forcing all upstream users of your API to handle the SQLException in some way. At first the solution may sound straight forward. Just have all upstream methods declare “throws SQLException” and then the exception will unroll up the call stack to the desired spot.

It’d be great if that worked, but often times there are road-blocks in that wonderful idea. The primary one being that you most likely don’t have control over every single method declaration. Often times a layer of your code implements an interface from a third-party library and the interface probably doesn’t throw SQLException or whatever checked exception type you need to pass up the call stack. So, what do you do. You’re stuck. Well, if you’ve ever found yourself in this situation, you do the only thing you can (unless you use the technique below). At the interface method implementation, you wrap the checked exception in a RuntimeException and throw it up the call stack. Talk about ugly!

Rethinking the Value of Checked Exceptions

About this time you should be trying to reassure yourself that checked exceptions are a good thing and that such issue are just part of creating highly robust code. Ok, hopefully you’re not saying that, because again, ask yourself: What do you suppose you could do to reasonably recover from an exception being thrown by any random java.sql method?

Answer: Very Little. Keep in mind I said “reasonably recover”. Remember, that is in fact the purpose of checked exceptions. If the operation cannot be reasonably recovered from then the API should be throwing unchecked exceptions. In the case of the SQL API, there is very very few cases where a reasonable recovery is possible and even if you could dream up a recovery scheme, it’d probably be very costly to implement and unreasonable for 95% of the applications. And when you think about it, many API’s that use checked exceptions do so improperly. java.io? Hmm… IOException… couldn’t read from my file. What can I do to recover from that within the context of my file read method? Nothing.

What About Mission Critical Applications?

But what if you’re writing a 100% mission-critical cannot go down under any circumstance or else I’ll loose my job and life kind of application? The kind of application that runs the Mars Rovers or the New York Stock exchange or eBay. Well, great, invest in redundant servers, clusters, backups, replication models, use transactions, do extensive unit testing, end-user testing, stress testing, and apply sensible exception handling. But checked exceptions will not in anyway determine your success or failure.

Ok, ok. Enough on that. If you still think checked exceptions are great then no one will convince you otherwise and I’m sure the following code will really make your blood boil.

How-To Bypass Checked Exceptions

Recently I checked in a class called Reflector to the thinwire.util package of the framework’s dev trunk. One of the static methods on it has the signature:
public static void throwException(Exception e);

It’s intended to be used in the following manner to first catch and then re-throw a checked exception in a manner that bypasses the checking that both compiler and byte code verifier do to make sure that checked exceptions are handled properly. Here’s how you might adjust the prior example to leverage the checked exception bypass:

public void preformOperation() {    //You can simply call the retrival method without a try/catch    testRetrieval();

    //Or you can wrap it in a try catch to catch the checked exception    try {        testRetrieval();    } catch (Exception e) {        if (e instanceof SQLException) {            //do something        }    }}

//Assuming testRetrieval is the public API boundarypublic Info testRetrieval() {    try {        Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");        Connection con = DriverManager.getConnection("jdbc:odbc:test", "user", "password");        System.out.println("Connection To The Database Established...");        stmt = con.createStatement();        Info info = getData(1);        return info;    } catch (Exception e) {        //Calls the special method that bypasses checking        throwException(e);        return null; //Unreachable code    }}

private Info getData(String rNum) throws Exception {    Info info = new Info();    ResultSet rs = stmt.executeQuery("select * from itable where po =" + rNum);

    if (rs.next()) {        info = getResultSet(rs);    } else {        //do nothing    }

    rs.close();    return info;}

private Info getResultSet(ResultSet rs) throws Exception {    Info info = new Info();    info.setPo(rs.getString("po"));    info.setType(rs.getInt("type"));    return info;}

What Does It Do?

Assuming that the testRetrieval() method is a public API defining an operation. I added a higher level performOperation() method to serve as the user of the API. With that in mind, getData() and getResultSet() are really just methods used by testRetrieval and shouldn’t be part of the public API, so I made them private and altered them to just throw all Exceptions’ (which includes checked exceptions) so that testRetrieval() receives all SQLExceptions’ as well as all other Exceptions’. Then testRetrieval() serving as the public API, wraps it’s code-block in a try/catch. The trick is that the catch block calls the bypass method thorwException(), which in turn re-throws the checked exception so that performOperation() can recieve it. Notice how the testRetreival() method does not declare that it throws any exception types.

Then in the performOperation() method that uses the testRetrieval() call, I can have the method called outside a try/catch, in which case any checked exceptions generated by testRetrieval() will simple be passed further up the call stack and eventually to the console or log file (hmm… sounds like a good default don’t you think?).

Optionally I can wrap the testRetrieval() call in a try/catch on the Exception type and then do an instanceof check in the catch block to see if the exception is in fact of the the checked exception type SQLException. It’s important to note that I cannot just catch SQLException because the compiler doesn’t know that we’ve just spoofed it so it’ll still expect testRetrieval() to declare that it throws an SQLException if you try to catch the exception as an SQLException.

The throwException() Bypass Code from thinwire.util.Reflector

public static void throwException(Exception ex) {    if (ex instanceof RuntimeException) throw (RuntimeException)ex;

    try {        synchronized (CheckedExceptionThrower.class) {            CheckedExceptionThrower.exception = ex;            CheckedExceptionThrower.class.newInstance();        }    } catch (InstantiationException e) {        throw new RuntimeException(e);    } catch (IllegalAccessException e) {        throw new RuntimeException(e);    }}

private static class CheckedExceptionThrower {    private static Exception exception;

    CheckedExceptionThrower() throws Exception {        Exception ex = exception;        exception = null;        throw ex;    }}

How In The Heck Does That Work?

Well, an interestingly little nugget that I stumbled upon in the javadoc for java.lang.Class led to this solution. In the “newInstance()” method documentation it states:

“this method propagates any exception thrown by the nullary ‘zero-argument’ constructor, including a checked exception. Use of this method effectively bypasses the compile-time exception checking that would otherwise be performed by the compiler.”

This somewhat makes sense when you think about it. It means that if the reflection method newInstance() is used to dynamically create an object instance and the constructor for the object throws an exception, that exception whether checked or otherwise will be thrown by the newInstance() method. Thus, calling newInstance() behaves identically to statically constructing the same object in code (i.e. MyObject.class.newInstance() will throw the same exceptions that new MyObject() will). Of course, if you constructed the same class statically in code and the classes constructor threw a checked exception, the compiler would force you to use a try/catch to handle it. But since this is reflection based creation, it bypasses this behavior.

What’s Happening Behind the Scene

Ok, so this probably still doesn’t sit well with you. You’re probably wondering how does newInstance() get away with this? My first guess was that it was making a native call and it is, but in a manner different then you’d expect. The body of newInstance contains the following block of code that makes this all work:

// Run constructortry {    return tmpConstructor.newInstance((Object[])null);} catch (InvocationTargetException e) {    Unsafe.getUnsafe().throwException(e.getTargetException());    // Not reached    return null;}

Isn’t that pretty! The Unsafe class comes from the ’sun.misc’ package. Interestingly enough it offers all sorts of unsafe operations, such as raw memory allocation, but that’s off topic. The bottom line is that the throwException method on the Unsafe class allows checked exceptions to be thrown without the compiler knowing about it. And ultimately that’s what the throwException() method I provided above leverages.

Compatibility Across VM’s

So, you are probably wondering, does this work in other environments or just on Sun’s VM? Truth is that I’m not 100% sure, but if the environment is compliant with the the Class.newInstance() method specification, then this approach should work in that environment. And for compatibility reasons it’s unlikely that Class.newInstance() behaves differently in other environments. As far as I can tell, in the worst case scenario, another environment might wrap up the exceptions caught from the constructor in one of the documented checked exceptions that newInstance() can throw. But in those cases the code above will at least wrap those exceptions in a RuntimeException, thus guaranteeing solid compatibility in all environments. Of course the real solution would be for Sun to wake up and just eliminate or significantly reduce the burden of checked exceptions. But in the meantime, happy hacking!

Keeping the User in Perspective with Ajax

Although I am a technologist and I like pushing the limits of technology, I try to look at things from a users perspective as often as possible to make sure that I’m creating value and not just making decisions that would lead to things that I think are cool. End users, as most of us know, just want an application that works well and helps them do something they find important. The technology used to implement the application does not matter to them at all. You get bonus points for going above and beyond that bar with flashy effects and eye candy, but only if you’ve got your bases covered first.

So development managers need to ask themselves at least these two questions before adopting Ajax on a project. First, will you make up for the time invested in adopting a new technology through increased development speed? And second, will Ajax allow you to offer a more useful application to your users? Development managers are accustom to asking the first question about new technology because most organizations keep them focused on deadlines, budgets and getting functional requirements implemented quickly. However, really great organizations encourage their development managers to think about the user experience as well.

Now of course, nothing is that black and white, you also need to pick a project that makes sense. Success with Ajax has a lot to do with picking the right project to apply the technology to. Ideally, you want to bring in Ajax on an entirely new project or on a complete rewrite effort of an existing application. While enhancement projects to existing applications can work, they take a lot more planning and coordination and should only be done if you are positive the results will be a big gain with the users. Since users have a certain expectation of how an existing application should work, any change to the application will be scrutinized much more closely and any negative reaction may overshadow the benefits you tried to add by using Ajax.

In terms of a time savings, there is no question that Ajax and especially full scale Rich Internet Application (RIA) frameworks have the potential of significantly reducing the time it takes to develop web applications. The main hurdle that exists right now is legacy applications and the prior web development paradigms on which they are built. Many of the Ajax frameworks out there focus on adding another layer to the existing web development model, which typically leads to increased application complexity since there are more moving parts.

Therefore, IMHO the greatest gains with Ajax are to be realized with fully integrated frameworks that are designed around the power of Ajax from the start. Frameworks like Rails, Grails and others provide tighter integration but they stop short of eliminating the request/response model, page flow semantics as well as other outdated paradigms. Additionally, they still require the developer to work with a number of separate technologies ([D]HTML, DOM, JS, CSS, etc.) and toolkits (Dojo, Prototype, Scriptaculous, etc.) rather than providing a single development technology like desktop applications have traditionally done.

In contrast, server-integrated Ajax RIA’s such as ThinWire, Echo2 and others, cut out the complexity and provide the developer with a single homogeneous development environment. Such frameworks allow the developer to focus on building a great application and not on the underlying details. Anytime a technology can do that for your developers, you can realize a significant reduction in the time required to finish your projects.

In fact, these kinds of frameworks nearly close the gap between web and desktop applications. Unless you explicitly need access to lower-level desktop resources like the graphic card, sound card or file system, there is no longer any reason to build desktop applications. And even in those cases, you’re better off building an RIA app and then using browser extensions to provide the appropriate restricted access to desktop resources where required.

The bottom line is that a little proper planning and the right Ajax framework selection for a project can lead to excellent wins for the developers in terms of time savings and for the users in terms of a more powerful and useful application. However, improper planning and implementing Ajax technology just for the sake of saying you use “Ajax” is almost always a loosing scenario for everyone involved.

Happy Coding,

Josh < G >

Belated ThinWire JavaOne 2007 Conference Details

Ok, well this is coming a bit late I realize, but we have been quite busy working on a surprise for the ThinWire community, so I haven’t had a good moment to sit down and tell everyone about our JavaOne experience. As for the surprise, details arriving soon… in another post.

As a basic exhibitor at JavaOne, we didn’t get to attend the actual sessions. This is a departure from the other conferences where you’re usually given at least one full conference pass. In the end, it probably wouldn’t have mattered that much though because I’m usually too busy talking to people about the framework to spend time in any of the conference sessions. The good news is that unlike my New York experience, I had someone along to help out. In this case it was Brian Shaw, the CCS company CEO & President. I guess it figures that he’d leave me hanging at the other shows and only pop in for an appearance at the biggest show… hehe, he knows I’m kidding. Brian has long been a major supporter of my teams effort to bring this framework to the people. In any case, here’s what the startup booth on the Pavilion floor looked like with the new and updated splashy ThinWire graphics:

Like the other conferences I’ve been to, the first day was the the toughest. Usually it’s more hectic because you’re getting setup, you’re double-checking everything to make sure everything is working and you’re warming up your “Hey! Have you heard about ThinWire!” speech. In this case, the pavilion floor was open from 10am till 8pm the first day and we had a strong stream of visitors to our booth all day long. We gave out well over 100 fliers and held countless conversations. I thought for sure I was going to loose my voice due to all the conversations I was having. One thing that I found interesting was getting reminded throughout the day that not every Java developer writes web applications. It was definitely the largest contingent there, but there were a surprising number of mobile and embedded developers at the show as well as some big name companies that had embedded Java products. Here’s a few of our direct neighbors:

Another contingent that made a decent showing were various robotics developers. While I got the impression this was more for the “cool” factor than anything too practical, it was still neat to meet some of these people and see what they had done:

The first is a submarine that sits in the tang you see behind it. I was talking to the guys and they were having trouble getting the WiFi connection between it and their computer working (WiFi overload), so instead they were using a hot glue gun to attach an actual cat5 cable to the robot directly… hmm… cat5 and water. I saw the thing running later on, so I guess they got it working. The helicopter on the right just sat on display the whole time, nothing to fancy. The robot below claims to be the fastest robot in the world… I guess at drawing pictures, but I’m not too sure that Java has anything to do with it’s speed. Gotta love the hype machine!

While at the conference, I met up with a number of interesting people from some of the other big Java and open-source companies. In particular, I had a good conversation and provided many demos of ThinWire to various people from JBoss that wandered over to our booth. They seemed really impressed with what we were doing… and at one point Ram Venkataraman, Director of Product Management, showed up to get a preview as well. So don’t be too surprised if one of their initiatives suddenly starts to look something like ThinWire In truth, we might be talking to these guys more in the future.

I also made it a point to stop by the Interface 21 booth and speak to some of their folks. If you don’t know this, Spring is a great alternative framework to Java EE and a couple people I personally know have integrated Spring with ThinWire to create a powerful solution. One of my friends runs a local Spring User Group here in the Dallas area and happens to have met Keith Donald, the Spring principal I spoke with. In any case, I drug Kevin to our booth and warmed him up to the ThinWire way. He arrived somewhat begrudgingly, but by the time he had to leave, the other Spring guys had to drag him away reluctantly! (I exaggerate a bit… but hey… at least he was impressed with the framework).

Another cool person I met is Greg Wilkins of WebTide. The brains behind the Jetty Servlet engine. We’ve been very impressed with Jetty for quite sometime now because of it’s small size, super fast speed and it’s Servlet spec enhancements that make true Ajax Push a possibility. At some point we’d like to explore the changes that are necessary to enable this feature in ThinWire when you’re running on the Jetty platform.

Finally, I ran into Chris Richardson, the author behind “POJOs in Action”. Chris has experience with some of the concepts that we use in ThinWire and he finds the approach to be very powerful. We spoke with him for a bit and showed him the usual fair of demos. He apparently liked what we had because he went back home and started getting to work on a project that uses ThinWire with the Groovy scripting language. Here’s the first part in a blog post he recently did about his efforts.

Here’s the classic JavaOne bean bag picture:

We had a great time talking to everyone at the conference. The audience at JavaOne is exactly the kind of people who would be interested in the framework and everyone who did web development that stopped by to talk to us was quite amazed by ThinWire. We even ended up with a couple people who just couldn’t get over it and hung around all slack jawed as they repeatedly said how they couldn’t believe what we were doing. Not sure I’d call those people groupies, but if there is such a thing in the software world, I guess that would be it. In any case, we are always happy to see that kind of feedback as you might imagine.

Now if Sun could just get over themselves and wake up to the realities of the web & Ajax… I mean seriously, they wouldn’t shut up about JavaFX… as if repackaging an Applet with some new features is going to offer a superior solution. If you follow the hype machine they’ve been fueling, they essentially claim that JavaFX will kill Ajax… uhh… yeah… good luck with that Sun… cause you have a great record recently of making some great strategic decisions. In any case, maybe I’m just venting because they didn’t pick ThinWire for a Duke Choice award and instead picked… well, other projects that I’m sure are way more worthy, but I’ll let you all be the judge of that.

We wrapped up the conference on the last day by doing an interview with our friends at Sys-Con TV. They fit us in before the conference floor open because we had to catch an early flight back. Neither Brian or I are very lively in the interview because it was so early… and then my cell phone goes off in the first minute (*doh*)… but other than that it was a good end to a great conference.

Back from AJAXWorld East 2007 & Other Interesting Bits

I just got back last night from New York and I thought I’d spend a few minutes letting everyone know how things went. The first day was a little taxing… I had to lug a 22″ flat panel screen, large suite case with conference goodies, and my laptop bag over a half mile from my hotel to the Roosevelt hotel that was hosting the event. As a side note, I have to say that New York was quite amazing. It was my first time there and I tried not to act to much like a tourist, but I couldn’t get over how enormous the place is and how the buildings are crammed right next to each other. Additionally, it was pretty cool to see the culture and people change from street to street… lots to see and do.

In any case, after lugging everything to the hotel, I hunted down the conference reservation & sign-in desk, which was somewhat difficult to get to on a mezzanine above the lobby. After signing up, I made my way back down to the lobby and to a little landing right off the lobby where the empty ThinWire table awaited. Here’s what it look like after getting set up:

After getting setup, I spent the remainder of the first day talking to people and sitting around hacking on code while I waited for people to show up. Since most of the attendees were there to see the sessions, there were only certain times during the day when they were out and about visiting the various exhibitor booths. At the conclusion of the first day, the largest sponsor of the event, Laszlo Systems (a Flash based solutions provider), hosted a boat party at New York harbor, at which I got the opportunity to meet a lot of other vendors and find out what they had to offer. Here’s a picture I took from the boat:

On the second day, things got a little more interesting. The bulk of the day was pretty much the same, answering lots of questions and telling people about ThinWire, but in addition to that I had the chance to participate in a recorded one-on-one interview with Jeremy Geelan, the conference chair. I’ve spoken with Jeremy a few times in the past via email and in person and he’s a great guy with a lot of enthusiasm for technology. Well, he and the technology chair of the conference Dion Hinchcliffe, have been interested in ThinWire for a while now and what it can mean for the enterprise, so when a slot became available for an interview I was asked to participate. Here’s a picture of another guy doing an interview with Jeremy (guy on the left), unfortunately no one grabbed a photo of me during my interview:

The interview was a great time to talk about a recent development with ThinWire. We’ve recently announced an arrangement with another Ajax company called Helmi Technologies, who has a client-centric component framework with some unique capabilities. We’ve been in talks with these guys for the past six months, but the conference provided the perfect opportunity release a press statement about this arrangement. I’ll elaborate more on what this will mean in a future blog post, but feel confident in the fact that ThinWire will remain LGPL forever and we will not do anything to the server-development model that will impact your investment in using the framework. The initial goal is simply to make our technologies inter-operate with each other so that both technologies will have the option to leverage the advantages of the other.

While the second day was great, the third day was even better. Like the past two days I met with a number of people who found ThinWire’s approach powerful and were very interested in using it for their development. Additionally, I had the opportunity to participate in one of the discussion panels, moderated by Jeremy Geelan. The focus of the panel was discuss SYS-CON.TV Power Panel “How Far Are We Along On Our Way To The Rich Web?”. The video of this will also be online in a few days, so I’ll be sure to post it when it becomes available. While the power panel opportunity was cool, it was nothing like what happen next.

My session was scheduled for 2:40pm and when I first walked into the room I’d been assigned, it was nice and it could easily sit 60 people. The cool thing is that upon walking in, there was already 30 people there, so it looked like it might fill up. But before I could get settled, Geelan walked up to me and said, well… it turns out that we have an opening in the Grand Ball room, would like to move over there? I said, sure… so, we proceeded to move everyone who was there into the huge room that was adjacent to one I was in. And man, this place could easily sit 400 people… it was huge, and it had two projection screens on which to display my slides. But the coolest thing is that sessions in the grand ball room are filmed and put up online for everyone to watch, so again, I’ll post the link as soon as it becomes available. Thanks to the ballroom’s size and the fact that there were other people just hanging out in the room when I walked in, I ended up presenting to well over 100 people. Here I am at the podium after giving the presentation, you can see the playground app that I just demonstrated running in the background:

And here’s the short article that the conference organizers put up about this presentation. In any case, as you can see, things went really well… lots of interest in what we are doing in this grassroots framework. There’s more exciting things to come, but I can’t divulge too much right now.

Effective AJAX for Everyone ‘Including the Enterprise’

Well, this has been in the works since November and it’s finally arrived. An article I wrote last year titled Effective AJAX for Everyone ‘Including the Enterprise’, has just been published in the February edition of AJAXWorld magazine. The great thing about this is that you can go download the entire magazine for free, or view it online directly on AJAXWorld magazine website. The February edition is the one of the right with the title “AJAX On The Enterprise” on it’s cover. I’ve been told that the paper publication of the magazine will be available at your local news stand sometime in the next couple weeks. The prior edition appears to have made it to the Barns & Noble book stores, so keep an eye out for this latest volume:

On a related note, keep in mind that I’m going to be presenting at the AJAXWorld conference next month in New York City (March 19 - 21). So if you can, sign up for the conference and come talk to members from the ThinWire team in person. The topic I’m going to be covering is centered around the article that was just published in February’s edition, but it will be much more hands on and interactive. Hope to see you all there!

Thoughts for ThinWire and the New Year 2007

Hey Everyone,

Just a heads up to let you know that the team is going to be taking time off here and there from now through the new year and some of us will have limited internet access. In any case, some of us will be checking the forums every now and then but our responsiveness may be somewhat slow until the new year has begun.

While we have accomplished some amazing things in 2006, we have even bigger plans for 2007 and we are hopeful that our community will continue to accelerate in it’s growth and that ThinWire can become the standard for developing Ajax RIA applications, especially in Java. To make that happen, I’d like to take a minute to remind everyone that this is truly an open-source and community driven project.

Unlike some of the other commercial entities that have released there code under an open source license as a gimmick to attract developers and press, all in the hopes of getting revenue through indirect means. I personally have been driving the framework to an increasingly open-source, community oriented existence… not because I think we’re all going to get rich from this, but because I know we have made something great with this framework and I felt obligated to share what we had done with others who could use it. You see, I use many open source tools and products myself and I thought it was time to give something back to the community.

With that said, I really want to instill in those who use the framework, that you are responsible for it’s long-term success. The team we have working on ThinWire has accomplished great things and will continue to innovate by adding great things to the framework in 2007, but ultimately, it’s up to you to help us grow. Therefore, I’d like to ask everyone’s help in making that possible. There are a number of ways that anyone can contribute to the future of ThinWire. Here are some thoughts:

1. First and foremost, if you like ThinWire and you want to help to keep innovation in the framework strong, tell everyone you know about it! If you come across a website talking about Ajax and it doesn’t include a mention of ThinWire, drop a quick comment about us. If you know an industry contact, drop them a note to let them know about us. Find a press contact and shout out to them about how the framework has helped you succeed with your goals. We don’t have a dedicated marketing arm like the big guys, so we depend exclusively on word of mouth communication.

2. For the more experienced developers out there, write a tutorial about how to accomplish something in the framework. We’ll be glad to attribute it to you and either link to your tutorial or host it on ThinWire’s website. While ThinWire is powerful, it is also quite different from the standard web development model, so anything that makes it easier for people to start using the framework effectively is very important. We want to keep focused on adding new capabilities and improving performance, so helping us in this area would be greatly appreciated.

3. Build something cool with ThinWire and share it! We haven’t placed up a section for this yet, but we’d love to start collecting things that people in the community have built. Build a style sheet, build an app, build a compound component that’s useful… then send us screen shots and if you can, the code behind what you’ve done. We’ll gladly showcase it directly by hosting it on our website or indirectly by linking to a blog that you may have. Another thought along this line is to start an open-source project of your own, that focuses on building a useful tool with the framework. Examples might be, an admin console for Tomcat/MySQL/Etc., bug tracking software like Mantis or Bugzilla, a project management tool, a database query tool. The list of things that could be built with the framework are quite endless.

4. Share your thoughts more openly in the discussion forums. We honestly want to incorporate all of your ideas into our plans… so make sure we know what your thinking. If you love the framework, but would love it more if it only had XYZ feature… then let us know.

5. Encourage the company you work for to support our efforts by signing up for a support subscription. You can use the inquire form on the Products page to get a quote. All the income generated form support and related services goes directly back into working on the framework. The more companies we can get to directly support our development, the more developers we can dedicate to project and the better the support will be for everyone.

That’s about all I have to say at this point, but I’m interested to hear any thoughts that you may have on how we should further grow this project. Thanks and I hope everyone enjoys the holidays.

Object Oriented Super Class Method Calling with JavaScript

The Problem:

Every programmer who’s tried to apply classical Object Oriented techniques when developing with JavaScript, has at one time or another asked themselves the question: How do you call or invoke a super class method? Before the Ajax craze got into full swing, this question rarely arose because most developers were only exposed to the language when doing client-side form validation or simple DHTML / DOM element visibility toggling. In those simple situations, functional programming is sufficient and OO is of lesser importance. Now that Ajax is all the rage, programmers have been building increasingly complex systems involving large amounts of client-side JavaScript. As a result, many have tried to apply OO techniques to JavaScript as a way to manage that complexity. In the process, most developers quickly realize that JavaScript is a prototypical language and as a result lacks many of the more familiar OO conventions.

The subject of OO design and it’s various topics is huge, but aside from class definition approaches, I think this particular topic is one that JavaScript developers try to solve more frequently than any other. As a result, there are many different examples that you can find on the Internet, but all of the ones I looked at have certain scenarios under which they do not work properly. My interest in this topic grew as a result of my team’s efforts in developing the ThinWire Ajax Framework. As the demands on the client-side portion of the framework increased, we reached a point where it became necessary to have a solid OO model that supported super class method calling. Through super class calls, you can further centralize common code in the class hierarchy and as a result, more easily eliminate duplicate code.

The following outlines a number of approaches that I came across in my search. Ultimately, I was unable to find an acceptable solution published anywhere, so I had to resort to a custom solution, which you’ll find toward the end of this article. While super class calling was the most important OO mechanism that I needed a working model for, I also wanted a more natural way to define classes using JavaScript since the accepted prototypical approach is somewhat ugly in my opinion. So, with that said, lets dive in. As many developers have discovered, it’s very easy to do basic inheritance in JS, in fact there are two widely known approaches.

Simple Inheritance without Super Calls:

// Ahead-Of-Time JavaScript Class Definition and Inheritance// Yikes, that's kind of ugly.function BaseClass() {  //BaseClass constructor code goes here }

BaseClass.prototype.getName = function() {  return "BaseClass";}

function SubClass() {  //SubClass constructor code goes here }

//Inherit the methods of BaseClassSubClass.prototype = new BaseClass();

//Override the parent's getName methodSubClass.prototype.getName = function() {  return "SubClass";}

//Alerts "SubClass"alert(new SubClass().getName());

And this approach, but you should avoid it:

// Run-Time JavaScript Class Definition and Inheritance// Looks more traditional, but JS enclosures can lead to// SEVERE memory leaks in Internet Explorer.function BaseClass() {  this.getName = function() {      return "BaseClass";  };  

  //BaseClass constructor code goes here }

function SubClass() {  //Override the parent's getName method at  //object instance creation time  this.getName = function() {      return "SubClass";  }

  //SubClass constructor code goes here }

//Inherit the methods of BaseClassSubClass.prototype = new BaseClass();

//Alerts "SubClass"alert(new SubClass().getName());

Like I mention in the comments the first approach is somewhat unsightly, but it’s preferred over the second approach due to memory, performance and other issues. Its only been included here so that I could point out that you should not use it! So focusing on the first example, which outlines the standard prototypical approach, the question is: How can a method of SubClass call a method of its BaseClass? Well, here’s one approach that a lot of people try and take.

A Common and Broken Super Calling Attempt:

function BaseClass() { }BaseClass.prototype.getName = function() {  return "BaseClass(" + this.getId() + ")";}

BaseClass.prototype.getId = function() {  return 1;}

function SubClass() {}SubClass.prototype = new BaseClass();SubClass.prototype.getName = function() {  //Call the getName() method of the super class  //Hmm... is an explicit reference really a super call?      return "SubClass(" + this.getId() + ") extends " +      BaseClass.prototype.getName();}

SubClass.prototype.getId = function() {  return 2;}

//Alerts "SubClass(2) extends BaseClass(1)";//Is this the proper output?alert(new SubClass().getName());

The code above is modified version of the first script, I just removed the comments and some white space so you can focus on the new getId() method and the super call. Although, you have to wonder if that really qualifies as a super call since it has a hard coded reference to BaseClass. Nonetheless, it does the job… or does it? One thing that a proper polymorphic super call must do, is guarantee that the ‘this’ reference always refers to the current object instance and class methods. With that in mind, look closely at the output that is alerted and then look closely at the getName() method declaration for BaseClass. Do you see the problem? The issue is subtle, but very important. Using the super call syntax above, the getName() method of BaseClass is called and it returns a string containing both the name of the class and the value returned by ‘this.getId()’. The problem is that ‘this.getId()’ should return 2, not 1. If this seems strange to you then you might want to read up on polymorphism in an OO language like Java or C#. In any case, here’s a slight modification you can make to solve the problem.

Static ( Hard Coded ) Super Calling That Works:

function BaseClass() { }BaseClass.prototype.getName = function() {  return "BaseClass(" + this.getId() + ")";}

BaseClass.prototype.getId = function() {  return 1;}

function SubClass() {}SubClass.prototype = new BaseClass();SubClass.prototype.getName = function() {  //A little 'apply' magic and polymorphism works!  //But ugh, explicit references!      return "SubClass(" + this.getId() + ") extends " +      BaseClass.prototype.getName.call(this);}

SubClass.prototype.getId = function() {  return 2;}

//Alerts "SubClass(2) extends BaseClass(2)";//Hey, we got the proper output!alert(new SubClass().getName());

The call() method is defined as a member method of all Function instances in the ECMA-262 JavaScript/EcmaScript standard and has been supported by all major web browsers for sometime now. You may already know this, but JavaScript treats all functions as though they are objects and therefore they can have methods and properties attached to them. The call() method allows you to call a function and specify what the ‘this’ variable should be during the invocation of the function. JavaScript functions are not tightly bound to their objects and therefore if you do not use call(), the object directly to the left of the function is always passed as the ‘this’ variable. Another method that you’ll probably see in use that works very similarly to call(), is the apply() method. The only difference between the two is that apply() accepts an array of arguments that it passes to the function, whereas call() accepts the arguments individually.

Now looking back at the last example, the only the problem with it is that the super class references are explicit and therefore hard-coded. This may be acceptable for small class hierarchies, but for larger hierarchies with deeper levels of inheritance, explicit references can be very tedious to maintain. So, what’s the solution? Unfortunately, there is no simple solution. Simply put, JavaScript was never built to support super class method calling via implicit references. There is no equivalent ’super’ variable like the one you find in other OO languages. As a result, many developers have proposed solutions but as I mentioned earlier, each solution I have seen breaks down in one way or another. For example, here is one of the most famous approaches outlined by the JavaScript guru Douglas Crockford in his article entitled “Classical Inheritance in JavaScript”.

Douglas Crockford’s Almost Working Approach:

One Time Support Code

//Crockford's approach adds the 'inherits' method//to all functions, as well as a per-class method//called 'uber' that allows you to make super calls.Function.prototype.inherits = function(parent) {  var d = 0, p = (this.prototype = new parent());

  this.prototype.uber = function(name) {      var f, r, t = d, v = parent.prototype;      if (t) {          while (t) {              v = v.constructor.prototype;              t -= 1;          }          f = v[name];      } else {          f = p[name];          if (f == this[name]) {              f = v[name];          }      }      d += 1;      r = f.apply(this, Array.prototype.slice.apply(arguments, [1]));      d -= 1;      return r;  };};

Working Example

function BaseClass() { }BaseClass.prototype.getName = function() {  return "BaseClass(" + this.getId() + ")";}

BaseClass.prototype.getId = function() {  return 1;}

function SubClass() {}SubClass.inherits(BaseClass);SubClass.prototype.getName = function() {  //Looks pretty clean and it calls  //the getName() method of BaseClass  return "SubClass(" + this.getId() + ") extends " +      this.uber("getName");}

SubClass.prototype.getId = function() {  return 2;}

function TopClass() {}TopClass.inherits(SubClass);TopClass.prototype.getName = function() {  //Looks pretty clean and it calls  //the getName() method of SubClass  return "TopClass(" + this.getId() + ") extends " +      this.uber("getName");}

TopClass.prototype.getId = function() {  //Ok, so this.getId() should always  //return the result of calling getId()  //on SubClass, which is 2. So does it?  return this.uber("getId");}

//Alerts "TopClass(2) extends SubClass(1) extends BaseClass(1)"//Hmm... this.getId() didn't always return 2.//What happened?alert(new TopClass().getName());

The first section includes Crockford’s ‘inherit’ and ‘uber’ method code verbatim. The next section looks very much like the previous examples, except that I’ve now added a third level of inheritance to illustrate an issue that exists in Crockford’s approach. Admittedly, Crockford’s approach is one of the most solid that I found and there is no arguing that based on the body of work he has done on JavaScript programming, he is a master of JavaScript. However, if you review the code for the three classes and then look at the output, you’ll notice that there is subtle issue.

The output reflects that this.getId() returned the correct value of ‘2′ for TopClass, but it returned ‘1′ instead of ‘2′ when called from the getName() method of SubClass and BaseClass. As you can see, the getName() super calls behaved correctly and the three class names are displayed accurately. It’s only when the additional this.uber(”getId”) super call is interjected into the call stack that a problem is revealed. Since the object is a TopClass instance, every call to this.getId() in the call stack should always result in the getId() method on TopClass being called, which it does. The problem is that the getId() method on TopClass performs a super class call via this.uber(”getId”), and that call incorrectly invokes the getId() method of BaseClass in two out of the three cases, thus resulting in ‘1′ being displayed twice. The correct behavior is for the getId() method of SubClass() to be called in all three cases and for a value of ‘2′ to be displayed three times.

That was kinda tricky to describe, and I’m not sure I explained it clearly. However at the very least, it should be clear that the results of the above example are incorrect. Additionally, a downside of Crockford’s approach and of many other approaches, is that every super call requires an additional method call and additional processing of some kind. Whether this is an issue for your situation, will depend on how many super calls you have in your code. ThinWire makes extensive use of super calling in it’s client-side code and therefore it’s important that super calls are as fast as possible.

With Crockford’s approach broken and with no luck finding a working approach on the web, I set out to see if I could devise a working design of my own. It took me about a week to work out something that behaved correctly under all situations, but once I felt confident that it was working, I quickly integrated the approach into the framework. As it stands now, both the beta and beta2 releases of ThinWire leverage that initial design.

Dynamic Super Calling That Works:

One Time Support Code

//Defines the top level Classfunction Class() { }Class.prototype.construct = function() {};Class.__asMethod__ = function(func, superClass) {    return function() {      var currentSuperClass = this.$;      this.$ = superClass;      var ret = func.apply(this, arguments);            this.$ = currentSuperClass;      return ret;  };};

Class.extend = function(def) {  var classDef = function() {      if (arguments[0] !== Class) { this.construct.apply(this, arguments); }  };

  var proto = new this(Class);  var superClass = this.prototype;

  for (var n in def) {      var item = def[n];                      

      if (item instanceof Function) {          item = Class.__asMethod__(item, superClass);      }

      proto[n] = item;  }

  proto.$ = superClass;  classDef.prototype = proto;

  //Give this new class the same static extend method      classDef.extend = this.extend;        return classDef;};

Working Example

//Hey, this class definition approach//looks much cleaner than then others.var BaseClass = Class.extend({  construct: function() { /* optional constructor method */ },

  getName: function() {      return "BaseClass(" + this.getId() + ")";  },

  getId: function() {      return 1;  }});

var SubClass = BaseClass.extend({  getName: function() {      //Calls the getName() method of BaseClass      return "SubClass(" + this.getId() + ") extends " +          this.$.getName.call(this);  },

  getId: function() {      return 2;  }});

var TopClass = SubClass.extend({  getName: function() {      //Calls the getName() method of SubClass      return "TopClass(" + this.getId() + ") extends " +          this.$.getName.call(this);  },

  getId: function() {      //Much better, this.getId() always      //returns the result of calling getId()      //on SubClass, which is 2.              return this.$.getId.call(this);  }});

//Alerts "TopClass(2) extends SubClass(2) extends BaseClass(2)"//Everything looks good!alert(new TopClass().getName());

There’s a lot going on in that example, but in general this approach includes a fairly clean class definition model and proper super call semantics, which are established by the ‘extend’ method. Essentially, ‘extend’ wraps every method in your class definition with an intermediate function that swaps the super class reference to the correct reference with every method call. The only real issue with this approach is that it requires a number of intermediate functions, which may have an impact on performance. So recently I revisited the design and came up with an improved approach that eliminates the intermediate functions entirely.

Dynamic Super Calling That’s Faster and Works:
One Time Support Code

//Defines the top level Classfunction Class() { }Class.prototype.construct = function() {};Class.extend = function(def) {  var classDef = function() {      if (arguments[0] !== Class) { this.construct.apply(this, arguments); }  };

  var proto = new this(Class);  var superClass = this.prototype;

  for (var n in def) {      var item = def[n];                            if (item instanceof Function) item.$ = superClass;      proto[n] = item;  }

  classDef.prototype = proto;

  //Give this new class the same static extend method      classDef.extend = this.extend;        return classDef;};

Working Example

//Hey, this class definition approach//looks much cleaner than then others.var BaseClass = Class.extend({  construct: function() { /* optional constructor method */ },

  getName: function() {      return "BaseClass(" + this.getId() + ")";  },

  getId: function() {      return 1;  }});

var SubClass = BaseClass.extend({  getName: function() {      //Calls the getName() method of BaseClass      return "SubClass(" + this.getId() + ") extends " +          arguments.callee.$.getName.call(this);  },

  getId: function() {      return 2;  }});

var TopClass = SubClass.extend({  getName: function() {      //Calls the getName() method of SubClass      return "TopClass(" + this.getId() + ") extends " +          arguments.callee.$.getName.call(this);  },

  getId: function() {      //Just like the last example, this.getId()      //always returns the proper value of 2.              return arguments.callee.$.getId.call(this);  }});

//Alerts "TopClass(2) extends SubClass(2) extends BaseClass(2)"//Looks good again, and there's no intermediate functions!alert(new TopClass().getName());

This final design leverages a little known feature in JavaScript, although one that is supported by all major browsers. During the execution of any function, you can refer to the arguments that were passed in via the ‘arguments’ array. That’s fairly well known, but the lesser known detail is that the ‘arguments’ array contains a reference in the property ‘callee’, which points to the current function that is being executed. This is important, because it’s the only way that you can get such a reference since the function reference available via the ‘this’ object, always refers to the overridden function that is defined in the class at the top of the hierarchy.

That’s About It:

Ok, so that was a bit exhaustive. But I wanted to document the details in case anyone is curious and so that I’ll have something to refer to if I ever need to refresh my memory. In any case, I welcome your comments and any suggestions you may have.

References:

• ThinWire RIA Ajax GUI Framework
• Classical Inheritance in JavaScript by Douglas Crockford
• JavaScript Tutorial by Kevin Lindsey
• Super Simulation in JavaScript OOP by Tom Wright
• Mozilla’s Core JavaScript 1.5 Reference
• Ajax: A New Approach to Web Applications by Jesse James Garrett
• Microsoft’s HTML & DHTML Reference
• World Wide Web Consortium’s (W3C) Document Object Model (DOM) Specifications
• ECMA-262 EcmaScript (JavaScript / JScript) Specification

ThinWire Compared to the Google Widget Toolkit: Seven Points to Consider

As the lead architect of Thinwire, I’ve had a lot of people ask me to explain some of the differences between ThinWire and the Google Widget Toolkit (GWT), so I finally sat down and outlined some points that you should consider when drawing comparisons between the two. I think ThinWire offers many unique benefits, but in this article I’ll outline seven points that I think are most important. Keep in mind, this has been well researched, but as is always the case with comparisons, there may be some fine points that are not articulated properly. If this is the case, then please post a comment or send me an email.

1. Full Java API Access - The Google Web Toolkit (GWT) takes the approach of compiling a Java application into JavaScript. This limits the number of Java features that a developer can use to the set of API’s that GWT currently supports. As it stands now, only two core packages are supported (java.util and java.lang). When you consider that the latest version of java has over 150 packages, two is a very small number and rather limiting. In contrast, a ThinWire application executes all program logic on the server and therefore gives the programmer direct access to anything the Java API or J2EE API’s offer. Additionally, since the GWT emulates the two packages of the GWT at compile time, there is nothing that would prevent a developer from accidentally using unsupported Java API’s, thus causing frustration.
2. Linear Flow of Logic - With GWT, accessing anything that is outside the scope of the two supported Java packages (java.util and java.lang), requires the developer to implement a server-side service that performs a given task. Then, to actually utilize the service, the application code must use a rather complex async callback RPC mechanism that the GWT offers. While GWT tries to make this fairly simple, there is no mistaking the complexity added by this break up in logic. Further, Async programming is complex in itself and even GWT provides a page discussing this fact Getting Used To Asynchronous Calls. In contrast, since a ThinWire application executes all program logic on the server, the developer is never bothered by this issue. If they need to access something from Java Messaging Service (JMS) or call an XML parser, they just do it… no fuss. The ThinWire UI does use Async calling to update the screen, but it’s completely abstracted away from the programmer.
3. Single Development Language - With GWT, the developer still routinely writes JavaScript client-side code and HTML as part of building an application. For instance, since the capabilities of the built in components are rather limited, you would have to extend a component using client-side code if you want pull off something outside of the scope provided. In contrast, ThinWire intentionally prohibits the developer from using client-side code or HTML in the development of an application. There are ways to get around this for super-rare cases, but as far as the developer is concerned, you develop in a single language throughout your application. This simplifies the application code and decreases the skill level necessary to build a powerful web application. Another side effect of a pure server-side model like ThinWire is that it supports having other programming languages such as Python, Ruby, Perl or any other language supporting a Java binding.
4. Richer Set of Dynamic Component Widgets - If you look at the GWT “Kitchen Sink” example that demonstrates each GWT Component, you’ll quickly realize that GWT only provides a bare minimum of functionality for each of its components GWT Kitchen Sink Demo. Buttons don’t support images, text editors don’t have real-time edit masks, item lists and dropdowns don’t support multiple columns and have no sorting feature and no support for checkboxes, and the tree widget and menu widget and tab widget do not support images. The list really does go on, but suffice to say that ThinWire supports all of these features and more, plus all the components in the ThinWire framework support keyboard navigation.
5. Full Scale Debugging - With the GWT, debugging is improved because you debug using an actual IDE and the GWT’s debug layer. This is a great step, but since much of an application’s functionality is built using async services, the debugging effort is more complex. This is further amplified by the hybrid programming approach that GWT condones where you use some HTML, some CSS and some client-side JavaScript. With any of those pieces, the debugging effort breaks down. In contrast, the unified programming model that ThinWire uses allows the developer to step through code using an IDE debugger in a very natural way. Application logic flows top down and there are no async services that may execute in other threads.
6. Easiest Learning Curve - While GWT does simplify web application programming in some ways, it adds complexity in other ways such as via async services. ThinWire on the other hand is intentionally built to mimic the programming model used by tools like Visual Basic, Java Swing, Windows Forms & IBM SWT. Therefore, experienced client-server developers who have never built a web application, can easily transition to using ThinWire without having to learn any new concepts. Additionally, web programmers who have been fighting through the complexity that makes up modern web applications will welcome the simplicity and richness that ThinWire brings with its unified development model.
7. Security - Many Ajax frameworks and techniques exasperate traditional web application security issues, and in some case, they introduce new issues. In the case of GWT, there are two main security issues. First, since your Java code is compiled into client-side code, you are basically exposing the inner workings of your application for all to see. Second, since the GWT uses async services to handle server-side processing, you are inadvertently exposing those services to malicious use; potentially without user-validation. Now, technically you could argue that these two issues are not new issues. However, the problem is that with most Ajax applications, you are creating a much larger number of these kinds of issues. Further, the technical expertise necessary to protect against such exploits is potentially high and therefore many applications will likely go unprotected. With ThinWire, all application logic executes on the server and is therefore hidden from end-users. Additionally, since there is no requirement to use services, none are exposed to end users. The only data sent to the client is that which must be displayed in the UI. No hidden values or application state is sent over the wire. Effectively, ThinWire apps are much more secure by default.

Like I said, that’s not the authoritative list of everything, but it touches on the most important parts. At some point, I’ll follow up with more details and describe other area’s where differences lie as well as include any feedback from the community.

Open Source & Available Now: ThinWire Framework SDK v1.2 beta

After weeks of hard work from those on the ThinWire development team, we have finally released the much anticipated ThinWire Framework SDK! So go download it! And just like I mentioned in my last post… its Open Source under the GPL so that you can play with it to your hearts content. We’re still working out the details of our Commercial License, so stay tuned!

The SDK includes documentation, binary thinwire.jar, source (if you opt to download it), two demo applications and a slimmed down Apache Tomcat server to make your life easy. The whole package is around 5MB depending on whether you download the source. The good news is that the ThinWire.jar comes in at only 306k of that! In any case, check out the Mail Demo application that Ted Howard put together in his off hours over the last few weeks. It’s pretty darn neat and he’s already got some cool plans for the next version too!

As for the web site, we’re going to be adding more examples and documentation over the next couple weeks. Additionally, now that the SDK is available we’re going to be looking at different ways to get the word out about ThinWire. If you have any suggestions, please let us know. Also, keep checking back on this blog for more information or just add the blog to your RSS feed reader so you can be up to date on ThinWire. Thanks for everyone’s interest in ThinWire, now go get the SDK and make some cool apps!

The Ajax Experience Conference with Swag!

Recently I had the opportunity to attend the Ajax Experience, a web technology conference held in everyone’s favorite technology hub, San Francisco. The conference website describes the event as “the first ever two day conference exclusively for the Ajax community” and I must say it is by far the best conference I’ve been too. The content was right on target and focused on the past, present and future of Ajax technology, as well as the technical challenges that remain to be solved (i.e. Accessibility, Mobile Device Support, Memory Issues, Debugging, Testing & more).

I went to the conference with a few goals in mind. First, I wanted to broaden my understanding of all the top Ajax frameworks on the market, both commercial and open source. I’ve had varying levels of experience with many of them in the past, but over the last couple years I’ve mainly been focused on building the ThinWire Ajax framework so I thought this would be a good opportunity to see what others have done. Second, I wanted to meet both the people behind these frameworks and also the people looking to apply Ajax techniques so that I could get a solid picture of the perceived deficiencies and some of the solutions that the frameworks were working on. Finally, I wanted to see how some of the other frameworks have solved the same issues that we encountered while building ThinWire.

Truthfully, there was so much information conveyed in such a short period of time that it would take pages upon pages to describe everything that I saw or heard. To give you an idea, the event had 35 break out sessions running 5 parallel tracks over two days and a half days. The last two days ran more or less from 8am till 10pm and then I hung around speaking with people until 11:30pm. Additionally, there were 5 keynotes, 3 expert discussion panels and numerous breaks for mingling with other attendees.

As you might imagine, with 35 sessions I only got to attend about a fourth of them. However, we were provided a CD containing almost all of the slide show presentations used in each session as well as the slide shows from the keynotes. And from what I heard, all of the conference attendees are going to get online access to video recordings of the keynotes and a number of interviews sometime soon. Overall I really can’t complain though… there was a lot of content, but I found it mostly thought provoking and interesting. As things start settling into my mind and as I go back through my notes, I’ll be posting more about the conference. But for now, I just thought I’d let everyone know the basics.

And finally, here’s some pics of the swag from the conference. Sorry for the terrible picture quality, my camera phone bites and its all I had with me. The only thing I don’t have a picture of yet is the iPod shuffle that we got, which was branded with conference title. I’ll post a picture of it when I get a chance to snap a pic.

-Josh < G >

-Josh < G >