The other thing I want to touch on is what the frameworks future will likely be and to ask if there are developers who might be interested in joining the project to help establish the future of the framework.

Where We’re At Currently

First, let me talk about the delays in development/releases. Part of the delay has been a result of backward compatibility testing that’s been going on by Custom Credit Systems (the company backing ThinWire) to make sure that the latest builds work correctly with the existing applications they have deployed with their customers. And since CCS’s customers are top U.S. banks, they tend to have a very rigorous testing process that spans months.

However, I’m not going to try and convince you that’s the only reason for the delays in ThinWire development. The other, more important, reason is that both CCS and I have been discussing various options for ThinWire’s future over the last six months. It was just about six months ago that I decided to leave CCS to consider other options. I won’t bore with you some run-on about why I left; it’s suffice to say that CCS is a good company and I just wanted to try other things since I’d been working for them for over 7yrs.

Where does this leave ThinWire? Well, I’m the lead developer who started the project back in early 2003 (it was an internal CCS project then) and while there has been help from others along the way, most notably the bright guy Ted C. Howard, there really hasn’t been any other developer working on the framework since it’s inception. Granted, there have been bug fixes from CCS and other community members, but generally, it’s been a one or two man show for most of it’s life.

So when I decided to leave, CCS and I had to sit down and figure out what was going to happen with ThinWire as a whole. In the beginning we started down the path of creating a new company dedicated to ThinWire that I would be in charge of and that CCS would only oversee from a distance. This idea worked on paper, but as time drew on three things became apparent:

1. There are legal issues with who owns the codebase and the ThinWire trademark, as well as what the operational guidelines for this new company would be. Now, it’s easy to just squawk at such statements and say… What do you mean, this thing is open source!?!?! But in order to be competitive in the market, the new ThinWire company would have to have the ability to commercially license the code to others, which it could not do with the opensource LGPL code. Additionally, just because the code is open-sourced, doesn’t mean that you have the right to use the ThinWire(R) name. The same holds true for many open-source projects.. heck, even the term “Open Source” is trademarked. That’s just the way things work in the business world. This means that the new company would need ownership of the codebase and trademark in order to control it’s own destiny and it turns out that ironing out all the issues that brings up is not as easy as you may think.
2. Unlike many other open-source projects, ThinWire is smack in the middle of the largest development paradigm shift since the internet came on to the scene 15+ years ago. Before Ajax it was possible that the web would be the primary platform of the future. Now it’s unquestionable. By utilizing the various techniques championed by Ajax, it’s possible to entirely replace all but the most resource intensive desktop applications and to do so while providing the user with a BETTER experience, not a watered down experience like you got with old school Web applications. So what does this mean with regards to ThinWire? Well, it means that the market is insanely competitive. Everyone knows this technology is the future, so everyone wants to own as much of it as they possibly can. And when market conditions are like that, it’s very difficult for a 1 1/2 person gig with no funding and no major company backing to get noticed or make much more than a dent regardless of how much effort is put in:
   
3. For a number of developers, ThinWire doesn’t fit the definition of Ajax or Web 2.0 development:
   1. First, it’s built on a proprietary component model similar but not identical to Swing or JSF. Swing’s API is not designed for web development and when ThinWire was started, JSF was just a twinkle in Craig McClanahan’s eye and it most certainly was not taking an Ajax-driven model into account. IMO, to this day it tries to straddle too much and therefore collapses in it’s own weight. But that’s besides the point. CCS and I spoke with a few people from Sun early on (2004) to see if they had any interest in taking on ThinWire, but they pretty much said… if it ain’t JSF, then we aren’t interested. Sun could have been an industry leader and beaten Google to the Ajax punch.
   2. Then you have the fact that ThinWire is meant to be like Visual Basic for web development, which seems to be about the worst thing you could say about any web framework. However, ThinWire is all about allowing developers to craft web applications as quickly as possible… not as sexily as possible. And stability and memory footprint are much higher on the priority list for big banking applications then spiffy Fisheye widgets, transparencies or animations. Unfortunately, boring business applications don’t exactly get the blood of most developers sizzling Most developers look and think: it’s server-side, it looks like a desktop app, it’s Java (oh the humanity), therefore it can’t be cool! Sure, it’s not the kind of framework you want to build your next Facebook killer on, but that doesn’t mean it’s not the most appropriate solution for back office applications. As always, it’s about using the right tool for the job.

How You Can Help

Don’t take my “State of the Framework” as some kind of death sentence for ThinWire, because it’s not. The framework has a lot to offer developers in it’s current state and both CCS and other developers will continue to use it for years to come. However, if you and/or other developers are willing to help by joining the project and doing one of the following listed below, then there can be an active and bright future for the framework:

1. Implementing some of the features from the rather extensive feature request list.
2. Help find and fix the known bugs.
3. Add javadoc documenation to the sourcecode or write tutorials of your own.

So, please, if you want to join, shoot me an email: josh at truecode dot org. I’m going to be trying to add 5-10 developers/contributors that are willing to take an active interest in pushing forward. I will still be involved and help as much as I can, but like so many other open source hackers, I’ve got other things going on that I have to attend to as well.

The Near-Term Future

To wrap things up, I’m am still working with CCS to persuade them to open the framework further, ideally under a BSD license. My goal in doing this is that it would free the codebase for any and all use and would ease the difficulty of managing code committers since there wouldn’t be any “who owns what code” issue to contend with. Under a BSD style license, all code would be owned by everyone… and even if you simply want to grab a small piece of the framework to include in your work, you’d have no trouble doing so. I believe this approach is the best option for the benefit of the community and everyone involved. If you have some thoughts you’d like to share on all this, either send me an email at: josh at truecode dot org, or add a comment to this post.

Thanks Again.

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;
}

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 reasonably 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 issues 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 boundary
public 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);
 
        // Unreachable code
        return null;
    }
}
 
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 constructor
try {
    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!

Using Ajax Makes Sense Sometimes

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.

Full Integration Saves Time

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.

Planning Trumps All

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.

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.

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 to 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.

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!