Nov 12 2005


Java Concurrency Stump the Chump

I was giving my talk on Java Concurrency this morning to a great audience in Denver. Several people knew quite a bit about pre-1.5 Java concurrency, so I was getting interesting questions. As I was demoing ExecutorService and friends, someone asked "But how do I efficiently wait for several Futures?"

Doh! I stop in my tracks. I know there is a simple trick for this, but cannot remember the helper class. Fortunately Brian Goetz is wandering the halls somewhere. Brian is way better than Javadoc, so at the next break he sets me straight (and teases me for not remembering every word of his excellent new book). Here is a little sample showing how you do it:

  public class Stump implements Callable {
    public final int serialNo;

    public Stump(int serialNo) {
      this.serialNo = serialNo;

    public static void main(String[] args) throws Exception {
      ExecutorService es = Executors.newCachedThreadPool();
      ExecutorCompletionService<Stump> service = new ExecutorCompletionService<Stump>(es);
      for (int n=0; n<10; n++)
        service.submit(new Stump(n));
      for (int n=0; n<10; n++) {
        Future<Stump> fs = service.take();
        System.out.println("Finished " + fs.get().serialNo);

    public Object call() throws Exception {
      Thread.sleep(new Random().nextInt(1000));
      return this;


Nov 10 2005


Enterprise Integration in Ruby

In my copious free time this week I read the newest Prag Beta Book, Enterprise Integration in Ruby by Maik Schmidt. As I have come to expect from the Prag series, the book is clearly written, from someone who clearly is both a coder and a writer.

It continues to amaze me how easy it is to get things done in Ruby -- and how much is already done for you. In demonstrating ActiveRecord in an integration scenario, Maik surprised me with a feature I hadn't used before: push_with_attributes. If you haven't used this method before, try it out. Then try to do the same thing with, e.g., Hibernate.

Another thing that stands out is how easy it is to apply existing Java knowledge to Ruby libraries. You'll find that log4r is log4j, but easier to use. And REXML is ElectricXML, but waay easier to use.

I also like that this book addresses Ruby's undisputed strengths. The success of Rails for web applications has fueled a lot of disagreement on when and how dynamic languages are suitable for application development. With enterprise integration there is more consensus: scripting languages are great for glue code. If you haven't done so already, check out Ruby on its home court.

Nov 05 2005


Debugger Today, Production Tomorrow

Want to predict the future of software development? Look for features that are currently used only by developers during development/debugging, and project them into a production world.

Consider AspectJ, for example. For years, developers have been pointcutting their own code in the debugger. In fact, gdb's scripting and breakpointing could definitely be used to implement a primitve Aspect environment

Or, take a more forward-looking example. Today developers are writing unit tests. Jim Weirich has blogged about the new RSpec project, which looks almost like unit tests, but recast as executable specifications:

  class EmptyMovieList < Spec::Context
    def setup
      @list =
    def should_have_size_of_0
      @list.size.should_equal 0

Of course it won't end there. RSpec (or something like it) will morph into a DSL for specifications. Once in this form, it will be reasonable to, for example, turn precondition checking on or off for specific portions of your code in production. What we now thing of as "development time" unit tests will be fully integrated into production software.

Is this just semantics? Yes, and I agree with Jim. Leave out the "just".

Nov 02 2005


JBoss At Work (with JAAS)

Congratulations to Scott Davis and Tom Marrs for shipping JBoss at Work. Scott gave me a copy at the Reston NFJS show last weekend, which was fortunate timing since my flight home was delayed and I was stuck in Dulles's delightful Terminal G.

I am not currently using the full JBoss stack on a project, but I was curious about JBoss's JAAS support, and was pleased with the proportion of the book devoted to the topic. The tutorial in the appendix reminded me of something I need to add to my JAAS talk: coverage of the command line JAAS debugging flags.

Addendum: Since reading the book I have poked around in the JBoss codebase a bit. If you're doing JAAS work; it is a nice source for inspiration.

Oct 29 2005


Gabriel Myron Gehtland

Originally uploaded by jgehtland.

Gabe was born Friday, Oct. 28th, at 2:26pm . Mom and baby are both well, and older sister Zoe is very pleased that the "cute baby" is coming home with us soon.

Oct 28 2005


Welcome, Gabriel Gehtland!

Here at Relevance, we are committed to organically growing the business. To that end, I am pleased to announce our newest junior member: Gabriel Gehtland, 6lbs11oz, born today at 2:20pm. Congratulations Justin and Lisa!

Justin, we're expecting a photo or two once you're home and reasonably sentient again. :-)

Oct 12 2005


Java in Action: Ajax Presentation now online

I've finally posted the slides and code samples for the Ajax presentation I gave at Java in Action in Orlando. They can be found on the Resources section of our website. They are called "JIA: Ajax Slides" and "JIA: Ajax Demos", respectively.

Be forewarned: the slides are 16.9mb and the demos are another 10mb. What can I say, I never said Ajax was SMALL, did I?

Oct 09 2005


Ajax at Java in Action

Man -- I didn't know how a three-hour extravaganza on Ajax was going to fly down at Java in Action. I mean, people like hearing about cool stuff, and Ajax qualifies, but three hours? I didn't know if the audience would revolt or something.

My fears, it seems, were unfounded. I got some really good responses to the talk, and feedback from the crowd that will directly influence "Pragmatic Ajax". In fact, Dion has already gone ahead and written the PHP chapter, which several of the attendees were asking about, so we're really proving out this Agile book writing thing. Good job, Dion!

For those who actually attended, I'm busy packaging up the live code demos I did, which I'll post here in our Resources section by tomorrow.

Thanks to everyone who came to the talk; it was a great crowd.

Oct 08 2005


List comprehensions versus blocks/closures

I have been catching up on reading lately and have particularly enjoyed Martin Fowler's Bliki. Reading CollectionClosureMethod helped me crystallize me why I much prefer blocks/closures over list comprehensions. In fact, I'd take things a step farther. The article argues that while closures are more general, list comprehensions offer a convenient syntax in some cases:

List comprehensions make it easy to combine the two.

  managersOffices = [ for e in employees if e.isManager]

You can also do this be chaining block methods together (which looks a little more clunky to my eye).

  managersOffices ={|e| e.manager?}.map {|m|}"

Let's make the block form look nicer:

  # usage: employees.mapsome {|e| if e.manager}
  module Enumerable
    def mapsome(&blk) {|e|}.compact

Ruby already has something quite similar to mapsome: Nano Methods'compact_collect. I love the implication that Nano makes about Ruby: the language is so concise & powerful that the useful unit of component reuse is the single method.

Oct 06 2005


Developer oriented languages

Ted Neward has responded to my post about the new C# features and how C# compares to more developer-oriented programming languages.

We seem to be talking past each other, so let me tighten my argument by reponding to a few specific points. Ted says

...the idea that a dynamic language doesn't have specific and detailed rules regarding inheritance, encapsulation, delegation, and so forth, is a fallacy: they have them, they're just not the same rules as those for a statically-typed language.

You're right Ted. That's a fallacy. It's also not what I said :-). Of course Ruby, Python, Lisp, et al provide the abstractions in question. The criticial point is that these abstractions are implemented in the language itself. Developers can (and do!) modify these core abstractions to work in different ways. To use C#'s new extension methods as a point of example:

  • Prior to C# 3.0, extension methods did not exist
  • Microsoft sees the need
  • Now, in 3.0., we get extension methods

Compare this to, e.g, Ruby:

  • The rules for adding new methods to existing classes aren't (for the most part) in the core of ruby -- they are implemented in Ruby source code
  • The default rules make it trivial to add new methods
  • Developers can easily change this default by writing a few lines of Ruby code. You can create a different "extension method policy", and you could choose to enforce it at the system level, or by class, or by instance, or any other criteria you could imagine.

It's all about control. With a vendor-oriented language like C#, core abstractions are much more firmly controlled by the language vendor. Conversely, developer-oriented langauges like Python leave more of these choices to the developer (although they tend to provide reasonable defaults). So, again, who do you trust?

Ted thinks I don't trust vendors:

I find this argument highly unfair and totally bigoted. It essentially suggests that vendors can't do anything right, and portrays them in the traditional "corporations are the root of all evil" that right now so deeply permeates the American social landscape. It also portrays everything done by "non-vendors"...

But I never suggested any of that. Competency and trustworthiness are sprinkled all over our industry, both among language vendors and application developers. My concern is who controls the abstractions. Developer-oriented languages (like Scheme) give a lot of control (and responsibility) to developers. Vendor-oriented languages (like Java) leave that control more firmly in the hands of the vendor.

Ted and I actually share a lot of common ground. We both know it is about trust and control:

all this "expressiveness" is like putting craftsman's tools in your hands; in the hands of a master craftsman, amazing things can result, but in anybody else's hands, it's putting a loaded gun into the hands of a child.

If I understand the analogy correctly:

  • We (readers and writers of blogs) == master craftsmen
  • Developers == small children
  • JavaScript (et al) == loaded gun
  • C# (et al) == board with a nail in it (?)
  • IT decision makers == adults

This argument certainly pulls no punches, and there are plenty of people who see the software world this way. But I actually think there are more nuanced defenses of "vendor-oriented programming". Here's one: Vendor-oriented languages help keep developers focused on their solution space. Company X builds widgets, not programming languages. Their developers are plenty smart enough to create (or improve) a programming language, but company X doesn't sell programming languages. Working in C# or Java imposes a structural barrier in front of non-productive activities.

The Company X example pushes the conversation toward the debate I'd like to have, with questions like these:

And some meta-questions too:

  • Does a strong culture of automated testing on a development team change your answers to the previous questions?
  • One size does not fit all. What non-technical factors guide platform choices in the real world?
  • How big a project (or team) does a company have before it becomes worthwhile to spend time improving languages, rather than just building with the tools we have?

Popular Tags