I had the opportunity of attending the last day of the Lone Star Software Symposium in Austin (one of the
NoFluffJustStuff events). Every speaker I saw gave a solid presentation and I considered the time well-spent. However, rather than reviewing the whole conference, I'm going to tell a story of my brief but so far fruitful exploration of alternative Java technologies that began at the conference and has led me to
Nice and
Echo 2.
Having used Java for a little over 5 years now, exclusively building business applications for intranet and extranet use. These applications all follow the same basic pattern:
1) Thin-client UI generally for Internet Explorer (with a smattering of Netscape compatibility)
2) Java business tier
3) Relational database back end
Having built this type of application over and over again, I'm convinced of three things: 1) Java's web UI frameworks are too verbose and downright clunky compared with technologies like
ASP.net Web Forms, 2) The Java language itself is too verbose and not as productive as it could be for implementing business logic and 3) transparent persistence a-la Hibernate is definitely the way to go, but if you can build your application from scratch and keep your DBA's in check, you will use the same O/R Mapping patterns 95% of the time and shouldn't have to deal with repetitive XML mapping activities. Several sessions at the symposium brought this into stark relief and set me out to understand and address all three of these problems.
Rod Cope gave a presentation on Advanced
Groovy. The session included demonstrations of a bunch of whiz-bang features in Groovy, including closures, safe navigation (avoids a lot of null-pointer issues), template engines, XML-RPC and Active Proxies (COM interoperability). Using very few lines of code, Rod was able to do lots of cool stuff with Groovy, including setting up an XML-RPC server and client as well as creating an Excel Spreadsheet with graph from Java. He had me hooked, and I think that he piqued the other audience member's interest as well. Yes, you read that right, the session had only two audience members (including myself). This may be attributable partially to the fact that the panelists at the previous day's panel discussion had pronounced Groovy dead, and partially to some Java developers already having learned what I only recently did - Groovy is not a productive language (more on this later).
Earlier in the day,
Eitan Suez gave a presentation on
Naked Objects. Naked Objects is a GUI framework that attempts to expose plain old java objects (POJOs) directly to users. The idea is that, using the Naked Objects framework, one can build complete business applications in this manner, without writing a single line of GUI code. Furthermore, the Naked Objects framework attempts to abstract data access as well, so that really all the developer needs to worry about is the object model and business logic contained therein. This, in theory, makes the developer much more productive. It all sounds very nice, but the framework itself is half-baked and has not seen consistent development or releases. Liking the ideas but frustrated by the implementation, Eitan created his own version of Naked Objects that follows a lot of the same principles but that actually works. He demonstrated an application that he wrote using his framework and it looked impressive, but Eitan's framework is proprietary--look for a potential commercial version down the line. Also, being thick-client focused, it won't scale and is really only applicable for small businesses.
The symposium also included some coverage of
Ruby on Rails, which was well-attended and generated lots of excitement. I didn't catch any of it, but I was impressed by the fact that arguably the most interesting and exciting technology discussed at a Java software conference doesn't use the Java language nor run on a Java platform. I think that's as powerful indictment of the Java language as can be made.
Being duly impressed by what I had heard of Ruby on Rails, I decided to take it for a spin. I only played with it for a few hours, but quickly learned something that turned me off to Rails and sent me in a different direction--Ruby on Rails is not Java. All the syntax, the handy toolkits and the awesome server-side power (JMS, distributed transactions, etc.) I had come to love are not supported. This may seem like an obvious comment, but it really hit home when I tried accessing my test database. It just so happened that I had an Oracle instance available, so I decided to use it while going through the Ruby on Rails tutorial. To my shock, I learned that the Oracle driver for Active Record (Rails' data access framework) is in alpha. It looks like the author has done a lot of good work on it, and writing a database driver from scratch and giving it to the community is certainly an awesome contribution. Also, the author seems to be taking an honest approach to numbering his releases, which I find refreshing. However, I've gotten used to production-quality JDBC drivers for production databases and I'd like to continue using them. At this point, I concluded that there had to be a way to make Java productive without tossing out the massive amount of work that's gone into JVM-compatible libraries and frameworks by switching to a new language and runtime platform.
Okay, so it looks like I'm stuck with Java. However, my look at Rails and Naked Objects highlighted a key lesson - presentation and data access should be transparent and require little or no code and configuration.
On the data access front, pure JDBC certainly doesn't fit the bill. Fortunately, there's
Hibernate, which brings transparent persistence to Java, utilizes the power of production-proven JDBC, and is itself in its 3rd production release. The only downside compared with Rails' Active Record is that it requires configuration. The latest version of Hibernate supports annotations (in Java 1.5), which helps relieve the problem somewhat. Still, I thought it would be an interesting experiment to implement the
Active Record pattern using Hibernate. Groovy happens to have some nifty support for generating XML, so I decided to use Groovy to build this experimental Hibernate Active Record framework.
At first, all seemed well. I installed the
Groovy Eclipse plugin and set to coding. Groovy's MarkupBuilder allowed me to implement a basic mapping builder that could create XML Hibernate mappings from a POJO. In order for this to work, I needed to add the ability for these POJO's to provide some information about their properties and relationships (similar to what Hibernate uses annotations to address). Thankfully, Groovy has a nifty language construct called "use" that essentially implements
multiple-dispatch and that allowed me to do just that.
All was fine in Groovy-land until I started trying to run and debug my application. As
occasionally happens when I code, there were a few bugs. Groovy doesn't yet have a debugger (which is excusable, given that it's a new language), but it also suffers from atrocious error reporting. For the most part, if an exception is thrown, there's no way to trace it back to a particular line of code (or even a source file) unless you use extensive debug output statements in your code. Rod Cope had warned of this during his presentation, but it didn't really sink in until I actually tried doing something substantial with the language. At the end of the day, implementing my automated mapping builder in pure Java would have taken a lot more code, but with the Eclipse debugger plus the line-precise error reporting that's built into the language, I would have saved myself time, which is ultimately what I care about most. Groovy, as it turns out, was dead to me.
On the UI front, I was faced with a lot of options from which to choose. Struts/JSP/HTML/JavaScript/DOM was not an options, since this is what I was trying to escape. Between Struts Actions, Struts configuration, Tiles configuration (if you use Tiles), JSP pages, embedded HTML and associated JavaScript (not to mention CSS if you go that route), this industry-standard architecture presents the developer with a bewildering array of languages and technologies, often intermingled in the same source code files. And that's just for the UI!
What else is out there?
A lot! The few frameworks I looked at were:
Open Laszlo - Laszlo is a Flash-based rich client platform that has been around for a while in commercial form and was recently open-sourced. From playing with it for a couple of weeks, I found that it is really neat for building highly interactive applications with lots of neat GUI tricks. Getting it to interoperate with dynamic data is possible, but it essentially requires the use of JavaScript and XML on the client side and XML on the server-side (either through SOAP or XML-RPC). As you can see from my previous posting about Laszlo, I was pretty gung-ho about it. I still think that it can make me more productive than the traditional Java thin-client stack, but I think there are better options for building basic business applications. I've also read some disparaging comments about the size and performance of GUIs built using Laszlo. After spending days debugging XML and JavaScript problems, I was left with a bit of a sour taste in my mouth and decided to move on for now.
Tapestry - Tapestry's aim is to bring a true component-based thin-client GUI framework to the Java platform (much in the vein of ASP.net Web Forms). From what I read, it largely succeeds in this aim and has become fairly popular. I've experimented with it a couple of times and have been turned off by a couple of things. One, the documentation is constantly in a state of flux--work on Tapestry 4 began before the Tapestry 3 documentation was even finished, so now we have both incomplete Tapestry 3 documentation and incomplete Tapestry 4 documentation. To be fair, the tutorials seem to have improved quite a bit since the last time I looked at Tapestry 3, but it still feels like it's hard to get started with it. The second problem is that Tapestry 3 is very configuration heavy. Tapestry 4 improves on this somewhat, but I wasn't able to find a way to programmatically configure it. Since I was interested in emulating a Ruby on Rails type experience (which is very code centric and light on configuration), this ruled out Tapestry for my purposes.
Wicket - Wicket looks like a lightweight Tapestry. It's pretty well documented, and I found it easy to get started with. The framework uses HTML templates into which you can embed Wicket components. This allows for a great deal of reuse, and allows designers to mock up pages much the way that Tapestry does. I was getting pretty excited about Wicket when I realized that I was still using HTML, which I don't find enjoyable and which also raises the specter of using JavaScript/DOM if I want to do anything moderately interactive. That was when I ran across Echo.
Echo attempts to bring a Swing-style programming model to thin-client applications, and from what I've seen so far it succeeds. Things that I really like about Echo are: 1) Unless you're creating a new component, you don't need to use HTML, 2) Event-based controllers (ie clicking a button fires an event that you can handle with Java code), 3) a stylesheet system that allows you to externalize look-and-feel to avoid cluttering your code with colors, fonts and other formatting nonsense. The second version of Echo (Echo 2) is currently in beta, and it includes transparent Ajax support. I'm in the process of building a simple demo application using Echo 2 and hope to post some code examples soon.
Echo 2 does have one major potentially downfall, which is performance. It essentially operates on a similar model to X-Windows, in so far as Echo's server-side components act as a GUI server for the client. Put plainly, each user's GUI widgets are stored in a server-side HttpSession. This might present some scalability problems, but I wouldn't know without some actual performance testing (this would be the logical next step for me after getting a basic sample app out the door). I'm also somewhat concerned about how chatty the components are, given the event-based controller style. Again, something to look at during performance testing.
Okay, so we have a potentially workable solution to Java's GUI deficiencies, but where did we leave off on the language problems? Groovy seemed to be a dead-end, so I started looking around for an alternative JVM-compatible language. The are various scripting languages available for the JVM, including JavaScript, Python and others, but none seemed to have as clean integration with Java, nor Java-similar syntax, the way that Groovy did. By chance, I ran across a language called
Nice that not only does well in the
Computer Language Shootout, but also works well for me in practice.
While the intent of Groovy is apparently to provide as much syntactical sugar and as many gee-whiz language extensions as possible (I'm guessing since I haven't found a coherent explanation of the philosophy behind the language), the primary intent of Nice is to address some of the fundamental shortcomings of the Java language and to create a safer programming environment. Safer in this case means finding more bugs at compile-time than standard Java, while the shortcomings to which I'm referring are primarily the lack of closures (including anonymous functions and function pointers/references) as well as the lack of multiple-inheritance.
One of the best ways to understand what Nice has to offer is to go read this excellent
article on IBM's DeveloperWorks site. Through a variety of language constructs, Nice reduces the likelihood of null pointer and class cast exceptions at runtime. In addition to reducing bugs, this has the side-benefit of eliminating repetitive
if (variable != null)
and
if (variable instanceof SomeClass) {
SomeClass newVariable = (SomeClass) variable;
}
calls, leaving your code less cluttered. Nice also doesn't force you to catch checked exceptions, which goes a long way toward reducing code clutter.
On the multiple-inheritance front, Nice implements both multiple-dispatch as well as a novel-concept called
Abstract Interfaces. Together, these features provide a powerful way to extend the functionality of existing libraries as well as address cross-cutting concerns without resorting to AOP. AOP is a powerful technology and has it's place, but it also tends to be configuration-heavy and so is not in keeping with my attempt to emulate Ruby on Rails.
Nice didn't have the MarkupBuilder type functionality provided with Groovy, but using it's language features I was able to quickly implement something similar to support my Hibernate mapping generator. Furthermore, although it also doesn't include a debugger, Nice provides better error reporting than Groovy and allows me to at least trace problems back to a particular source file. There are a few quirks to which I had to become accustomed, but I'm finding that after a week or so of acclimation, I'm being very productive with Nice.
Another thing that sets Nice apart from Groovy, and that I think is emblematic of what is currently wrong with Groovy, are the unit tests. Nice has several continuous integration environments
running builds and tests. Groovy, on the other hand, doesn't seem to have anything of the sort. The Groovy site includes a link to
JUnit reports, but I've never actually seen an actual test run on there (and I've checked a few different times over about a 6 month period). The fact that Nice grew out of academic research into programming languages reassures me, and from what I can tell, the Nice team is focused on putting out a robust and usable programming language without getting distracted by whiz-bang features.
As I'm sure you've noticed, I just made a bunch of knee-jerk observations about a bunch of technologies that I've never used in production, so 1) take it with a grain of salt and 2) call me out on any inaccuracies, please. I hope to post a working application built using Nice, Echo2 and Hibernate soon, which should provide some more discussion points.
