For those of you who don’t know, polyglotism is not some weird religion but actually a growing trend in the programming industry.  In essence, it is the concept that one should not be confined to a single language for a given system or even a specific application.  With polyglot programming, a single project could use dozens of different languages, each for a different task to which they are uniquely well-suited.

As a basic example, we could write a Wicket component which makes use of Ruby’s RedCloth library for working with Textile.  Because of Scala’s flexible syntax, we can use it to perform the interop between Wicket and Ruby using an internal DSL:

class TextileLabel(id:String, model:IModel) extends WebComponent(id, model) with JRuby {
  require("textile_utils")
 
  override def onComponentTagBody(stream:MarkupStream, openTag:ComponentTag) {
    replaceComponentTagBody(markupStream, openTag, 
        'textilize(model.getObject().toString()))
  }
}

# textile_utils.rb
require 'redcloth'
 
def textilize(text)
  doc = RedCloth.new text
  doc.to_html
end

Warning: Untested code

We’re actually using three languages here, even though we only have source for two of them.  The Wicket library itself is written in Java, our component is written in Scala and we work with the RedCloth library in Ruby.    This is hardly the best example of polyglotism, but it suffices for a simple illustration.  The general idea is that you would apply this concept to a more serious project and perform more significant tasks in each of the various languages.

The Bad News

This is all well and good, but there’s a glaring problem with this philosophy of design: not everyone knows every language.  You may be a language aficionado, picking up everything from Scheme to Objective-C, but it’s only a very small percentage of developers who share that passion.  Many projects are composed of developers without extensive knowledge of diverse languages.  In fact, even with a really good sampling of talent, it’s doubtful you’ll have more than one or two people fluent in more than two languages.  And unfortunately, there’s this pesky concern we all love called “maintainability”.

Let’s pretend that Slava Pestov comes into your project as a consultant and decides that he’s going to apply the polyglot programming philosophy.  He writes a good portion of your application in Java, Lisp and some language called Factor, pockets his consultant’s fee and then moves on.  Now the code he wrote may have been phenomenally well-designed and really perfect for the task, but you’re going to have a very hard time finding a developer who can maintain it.  Let’s say that six months down the road, you decide that your widget really needs a red push button, rather than a green radio selector.  Either you need a developer who knows Factor (hint: there aren’t very many), or you need a developer who’s willing to learn it.  The thing is that most developers with the knowledge and motivation to learn a language have either already done so, or are familiar enough with the base concepts as to be capable of jumping right in.  These developers fall into that limited group of people fluent in many different languages, and as such are a rare find.

Now I’m not picking on Factor in any way, it’s a very interesting language, but it still isn’t very widespread in terms of developer expertise.  That’s really what this all comes down to: developer expertise.  Every time you make a language choice, you limit the pool of developers who are even capable of groking your code.  If I decide to build an application in Java, even assuming that’s the only language I use, I have still eliminated maybe 20% of all developers from ever touching the project.  If I make the decision to use Ruby for some parts of the application, while still using Java for the others, I’ve now factored that 80% down to maybe 35% (developers who know Java and Ruby).  Once I throw in Scala, that cuts it down still further (maybe at 15% now).  If I add a fourth language - for example, Haskell - I’ve now narrowed the field so far, that it’s doubtful I’ll find anyone capable of handling all aspects within a reasonable price range.  It’s the same problem as with framework choice, except that frameworks are much easier to learn than languages.

The polyglot ideal was really devised by a bunch of nerdy folks like me.  I love languages and would like nothing better than to get paid to learn half a dozen new ones (assuming I’m coming into a project with a strange combination I haven’t seen before).  However, as I understand the industry, that’s not a common sentiment.  So a very loud minority of developers (/me waves) has managed to forge a very hot methodology, one which excludes almost all of the hard-working developer community.  If I didn’t know better, I would be tempted to say that it was a self-serving industry ploy to foster exclusivity in the job market.

I want to work on multi-language projects as much as anyone, but I really don’t think it’s the best thing right now.  I’m working on a project now which has an aspect for which Scala would be absolutely perfect, but since I’m the only developer on hand who is remotely familiar with the language, I’m probably going to end up recommending against its adoption.  Consider carefully the ramifications of trying new languages on your own projects, you may not be doing future developers any favors by going down that path.

I usually try to avoid such negative topics, but this time I really couldn’t help myself.  Once in a while something in the “current events” section of the blogosphere will bug me enough to merit a slam post.  The “support” for Google Guice in the latest stable release of Wicket is one of those things…

To start with, the good news: Martijn Dashorst has announced the release of Apache Wicket 1.3!  This really is a great release all-around and the guys in the band deserve a round of applause.  This release fixes the number one “bug” with Wicket: it’s rather odd package namespace.  (wicket.*)  :-)  Welcome to the land of happy packages and tired fingers.

Wicket is really starting (or just proceeding at an accelerated rate) to feel like a rock solid, production-ready framework.  I’ve used it quite a bit over the last few years, and I’ll say flat-out that I don’t think any framework matches it for productivity and maintainability (that includes Rails, dynlang notwithstanding).

One of the new features in 1.3 (important enough to merit inclusion in Martijn’s 20-odd points) is support for Google Guice dependency injection.  This is a huge deal for those of us who have nominated Guice for the “cleverest framework of the decade” award.  Support for Guice in Wicket makes it possible to utilize dependency injection right in your page classes (where it’s most needed).  Wicket has had similar support for Spring for a while now, but it was only recently that Al Maw got the chance to refactor the guts out into the wicket-ioc project and thus enable support for alternative DI frameworks like Guice.

This all seems well and good, but unfortunately Wicket’s Guice support is not quite up to par with the rest of the framework.  I tried the support a while back in beta4 and ran headlong into a fairly serious problem.  The following code doesn’t work:

public class MyModule extends AbstractModule {
    // ...
 
    @Override
    public void configure() {
        EntityManager manager = new EntityManager(uri, username, password);
        bind(EntityManager.class).toInstance(manager);
    }
}

This is fairly standard Guice configuration code.  All that’s happening here is I’m binding all injected fields of type EntityManager to a given instance.  Of course the classic use of DI is to have it instantiate the injected values based on classname (or class literal in Guice’s case).  However, this panacea of IOC breaks down when working with classes which lack default constructors (like EntityManager).  This is why Guice enables developers to bind classes to instances (as I’m doing above).  The problem is this code will crash when executed using wicket-guice.

I opened an issue in the Wicket JIRA back in November when I first identified the bug (WICKET-1130).  I even included some simple example code I could use to repeat the problem!  Since then the issue has been reassigned and bumped back in fix version twice, all without any word on if the problem is being looked at or how soon I could expect a solution.  Now I know the Wicket devs are busy and all with tons of more sweeping issues and last-minute polish for the 1.3 release, but this is pretty absurd.

Honestly, if this were a trivial edge-case that only effected me and my neighbor’s cow, I wouldn’t put up much of a fuss.  But the fact is, this is something so broad and repeatable that it will touch just about anyone who seriously uses Guice with Wicket.  Even if there wasn’t time to fix the problem before the 1.3 release, I would hope there would be some sort of prominent notice (”KNOWNBUGS” anyone?) included with the distributable.  Unfortunately the only reference to the problem I was able to find on the Wicket site was an obscure wiki article (well written though) done by Uwe Schäfer.  All this entry serves to do is further aggravate me since it means someone else has run headlong into this problem and been annoyed by it enough to write an article (still without receiving response from the Wicket core devs).

Uwe does propose a workaround (add a protected no-arg constructor to the injected class), but that’s impractical for my use case (and if I ran into it, you can bet your boots half a dozen other people did too).  I’m certainly not going to randomly add broken constructors to the ActiveObjects API, and I wouldn’t even have the option to consider doing so except for the fact that I’m the developer on the class I was trying to bind.  If I was trying to bind an instance from a third-party library, I’d be out of luck completely.

I’m very disappointed in the Wicket project for dropping the ball on this issue.  I really have the utmost respect for those guys, which is why it’s so surprising to see something like this happen.  As it stands, WICKET-1130 is slated for 1.3.1, but given its track record of reassignment I’m not holding my breath.  Hopefully this posting will serve as a more prominent warning for those considering using Wicket and Guice together in their project.

• WICKET-1130 in the Apache JIRA

As some of you may know, I’ve been doing some work for Teachscape (think Eelco Hillenius) on their Wicket-based application.  It’s been a learning experience for me as much as a working position in that I’ve got to experiment with a lot of technologies and techniques I haven’t tried before.  For example, Teachscape is based on Hibernate and Spring, so I’ve been getting some really in-depth exposure to both technologies (I still dislike them both).  More interesting to me though is the way the application is run in a developer environment. 

It uses Jetty, not Tomcat or Glassfish.  There’s a main class within the application which sets up the Jetty instance, configures it to use the Wicket servlet and starts the server.  This means that running the web application is as simple as “Run As…” -> “Java Application”.  It starts fast, is more responsive than a straight-up Tomcat instance, and best of all, hot code replace works properly in debug mode.  Now having used this approach at Teachscape for some time, I’m starting to really miss it when I jump back to my own, WTP-based Wicket projects.

So after much wrestling with pros and cons, I decided to switch one of my more substantial projects over to using embedded Jetty.  I did this partially for the experience, partially because Jetty makes development so much easier, and partially because it lets me do cool things like package the app up in a single JAR and easily run it from any Java-equipped computer.

Step One: Dependencies

Dependencies are always an issue.  Modern web applications have in excess of 20-30 JAR files which are either packaged into the WAR, or thrown into the app server’s lib/ directory.  Some applications (like the one I was working with) have many more.  As you can imagine, this poses a more-than-minor inconvenience.

WTP makes dependency management (comparatively) easy, since everything is just thrown indiscriminately into the WebContent/WEB-INF/lib/ directory.  Since the JARs just sit there in a centralized spot, deploying is easy, the Eclipse classpath configuration is trivial and I don’t need to work all that hard to upgrade a certain library (such as wicket-1.3-beta3 to beta4). 

Of course, I can keep this approach when I switch to Jetty, but it’s not the cleanest thing to do.  What’s best is to configure the Eclipse classpath to reference the JAR files in their unzipped directories in my system somewhere (preferably through the use of classpath variables).  After all, that’s what I would do for a standard Java project, and with Jetty, a web application is no different from any other Java app.  With this rosy-eyed decision having been made, I deleted the lib/ directory and began reconfiguring the classpath.

Eclipse wasn’t too bad, since I already had half the libraries set as variables to begin with, but the Ant build was another story.  Two hours of typing into a build.properties file and several cups of strong coffee later, I was just about at the end of my rope.  The dependencies were all set, and the project was building, but it was a nightmare.  I can only imagine what’s going to happen if I have a significant influx of libraries and dependencies…

Lesson learned: use Maven.  Actually, don’t use Maven, since it’s just more headache than it’s worth.  What I should have done (had I really thought things through), is take advantage of the now-incubating Apache project, Buildr.  It’s basically a Maven-like build system with scripts based on Ruby and Rake.  Instead of writing an epic-length POM file, you write a 10-20 line buildfile (which is actually a Ruby script with some DSL syntax) and Buildr figures out the rest.  Unfortunately, by the time I bethought myself of this option, I was almost finished with the Ant configuration, and I’m too stubborn to give up half-way through something.

Step Two: The Launcher

The next step in my evil plan was to create a main class somewhere in the project which could configure Jetty and start the server.  Unfortunately, this is a bit harder than it sounds on paper.

The problem is not that Jetty has a tricky API, or any sort of gotchas in its configuration.  The problem is there’s very little useful documentation which shows how to turn the trick.  So, for the record, here’s the source for the main class I wrote:

public class StartApplication {
    public static void main(String[] args) throws Exception {
        Server server = new Server(8080);
        Context context = new Context(server, "/", Context.SESSIONS);
 
        ServletHolder servletHolder = new ServletHolder(new WicketServlet());
        servletHolder.setInitParameter("applicationClassName",
                "com.myapp.wicket.Application");
        servletHolder.setInitOrder(1);
        context.addServlet(servletHolder, "/*");
 
        server.start();
        server.join();
    }
}

Not really too much there once you see it all laid out for you, but it took me way longer than it should have to figure out that it needed to be done that way.  Executing this class starts a new Jetty instance serving my application at http://localhost:8080.  I can start the app in debug mode, getting proper hot code replace (something WTP never got right) and every debug feature Eclipse offers for Java apps.  To stop the server, all I need to do is hit that cryptically labeled button in the Console view which kill the running application.  Oh, and there’s no need to maintain a web.xml file, Jetty doesn’t need it.

Surprisingly, that’s all that’s different between WTP and embedded Jetty from a code standpoint.  I had expected to have to make significant changes elsewhere in my code base, but that was the extent of my fiddling.  Pretty slick!

Evaluation

Once the Jetty environment was up and running, it was time to decide whether or not it was worth it.  After all, I could always do an svn revert if I really didn’t like the results.

Overall, I’ll take Jetty any day, but I definitely need to use something like Buildr the next time I do this.  That would have pretty much dropped the setup time from 3 hours down to maybe 30 min (if that).  Oh well, live and learn.

So the moral of the story is that I’m done messing around with Eclipse WTP, trying to beat it into submission and putting up with all its oddities and extreme slowness.  I’m keeping it installed, if only for the HTML editor, but no more will I attempt to use it as a runtime controller.