Fuwjin Suite v0.9.6

The Fuwjin Suite v0.9.6 is released to Maven Central. Some fun new features in there.

• There’s a first stab at a maven plugin that runs a Grin Script during the build. In fact chessur is using the maven plugin to compile itself.
• The full Grin Specification is supported 100% in the GrinParser, GrinSerializer, GrinFormatter, and GrinCodeGenerator.
• The performance is substantially improved. The system tests alone used to take around 2 minutes to run, now the whole project builds in 20 seconds.
• The API has been overhauled to allow more direct calls to the Scripts.

The suite really is ready for general use, and I’d be happy to help folks understand what it does and why it’s different. I’m planning on taking a break from active development to get some posts up here and a few screencasts on the googlecode site. Let me know if there’s anything in particular you’d like to see.

Near-Closures in Java

Closures in Java are always a ripe source for debate, discussion, flame wars, angst ridden blog posts about the joys of other languages etc. But we’ve been able to do something very near closures all along. First, the test…

public class WishfulTest{
  String greet = "hi";

  @Test
  public void test(){
     final String name = "Bob";
     <<< V() => greet + " " + name >>>
     assertThat(doSomething(<<< V >>>), is("howdy Bob"));
  }

  private String doSomething(<<< WishfulThing V >>>){
     greet = "howdy";
     String ret = <<< V.invoke() >>>;
     greet = "hola";
     return ret;
  }
}

There are 4 places in the above test that we just don’t really know how to fill in. The first is creating the closure. The next is passing it as a parameter. Then we have to accept it as an argument. Finally, we have to invoke the deferred object. Now, Java has always had some means of doing just this, namely, anonymous classes. They get the local context where they’re created, and they get an implicit reference to the “this” object where they were created. The problem is that they’re very bulky. So this example might use the following anonymous class:

public class WishfulTest{
  ...
  public void test(){
     ...
     Closure v = new Closure(){
        public String invoke(){
           return greet + " " + name;
        }
     };
     ...

I’ll leave the rest of the implementation to your imagination. But essentially, we must declare a method and a class to pass around a closure in Java.

Really, we just want the method. But methods aren’t first class objects in Java, only classes. So we have to have a class definition, there’s no way around it. Then can we ditch the method? The answer again is no. Java only associates code with methods. There’s just no escaping it in Java, if you want code, you must have a class and you must have a method.

You can cheat a little. You can stick your code in something called an initializer. An initializer is code that’s run with your constructor. Basically, you just throw your code into a block outside of any method and java creates an unnamed method. You can’t just call it whenever you want though, it will only be invoked during instantiation.

That doesn’t really buy us much, does it? Anonymous classes are instantiated as they’re declared, so you can’t defer the initialization. Inner classes are great, but they don’t pick up the method state if you declare them in the class body. But it turns out that there’s a tiny little feature that is generally completely useless. You can declare classes in your methods. They aren’t visible outside the scope, so you can’t generally do anything with them, but here’s that example again.

public class WhenUsingFunky{
  String greet = "hi";

  @Test
  public void test(){
     final String name = "Bob";
     class V extends Funky<String>{{ret = greet + " " + name;}}
     assertThat(doSomething(V.class), is("howdy Bob"));
  }

  private String doSomething(final Class<? extends Funky<String>> cls){
     greet = "howdy";
     final String ret = Funky.invoke(this, cls);
     greet = "hola";
     return ret;
  }
}

So essentially our closure is a Class instance. By using an initializer (notice the double curly brace) we effectively declare a constructor which sets an instance variable named “ret” to the concatenation of the WhenUsingFunky.greet field and the final local variable named “name” in the declaring method. But this code does not execute until the Funky.invoke line in the doSomething method. Which means that instead of picking up the value of “greet” set in the declaration, it uses the latest value at the time of the invoke call.

Funky itself is a fairly simple class. Here’s the gist of it:

public class Funky<T>{
  public static <T> T invoke(final Object self, final Class<? extends Funky<T>> cls){
     try{
        final Constructor<? extends Funky<T>> c = cls.getDeclaredConstructor(cls.getEnclosingClass());
        return c.newInstance(self).ret;
     }catch(final Exception e){
        throw new RuntimeException(e);
     }
  }

  public T ret;
}

So we grab the constructor that is generated by the compiler for non-static inner classes. Then we create a new instance using the supplied value as the target. The constructor should be accessible (though it’s fun to try to figure out why) even though the class V itself is not visible outside the declaring method. The field ret is public since if it were private, then V couldn’t set it in its initializer, and if it were protected or default access, the invoke method couldn’t see it (though again, it’s fun to try to figure out why). It doesn’t hurt encapsulation much though, since the only instances of V exist for a short time just inside the invoke method itself.

So, there you have it. A very concise, horribly complex syntax for declaring closures. The next step is to try to pass parameters to the invoke method, that should be fun.

Java Exception MicroBenchmark

Maybe you can tell from my previous post that I’m completely fed up with Java Exception FUD. I attempted to point out my major reasons behind using exceptions liberally without directly attacking the arguments from the anti-exception folks. I can’t even begin to address all the ridiculousness out there.

But perhaps you, gentle reader, don’t care about the pros or cons. You just want to see for yourself whether Exceptions are expensive or not. I told you my anecdotal evidence on performance of infrequent failure reporting performance efficiency. But as an informed, astute reader you really care about performance where it matters, in the high frequency, high failure case. You deserve an answer. But you deserve one that actually matters to you. I run my tests on a 4 year old Mac Book Pro. It’s Intel, but it’s only 2 cores. And it looks absolutely nothing like your high end Linux server blade, or your Windows 7 VM running on a virtual service environment on who-knows-what box in central Connecticut.

So who cares about my anecdotal evidence or some fancy numbers somewhere. Here is my microbenchmark for Java Exceptions. Why not see what it looks like on your environment?

Just in case you don’t want to investigate the code, let me explain the output, in particular the table. There are 6 strategies, each with a “Time” and a “Fail %”. The “Fail %” is really just a check to make sure I haven’t done anything too crazy on the implementation, so don’t worry as much about that. The key is the “Time”; this is the median of the batch average execution time for batches after the warm up period. Roughly speaking, this is a best-we-can-get-but-still-biased indicator for the 50th percentile of the distribution of execution times for each of the strategies.

The key here is that you can’t place too much weight on the relative values until they start getting consistently higher or lower. I’ll try to work out a confidence test for comparisons between the strategies, but I’m not sure that there’s a decent test for median averages. At any rate, try running the test a dozen or so times to get a feel for the variance. Keep in mind that the time units are in nanoseconds, so we’re a little limited in how we can generate these times within the JVM.

The strategies are as follows: The Control strategy generates a validation failure message but does not detect whether the returned value is a success or failure. The Detect strategy does not generate any failure information, but does detect failure by checking for null. The Exception strategy throws a runtime exception with the failure message. The NoTrace strategy also throws a runtime exception, but that exception overrides fillInStackTrace() to disable stack tracing. The Result strategy returns a typed result object with an isSuccess() method. The Sentinel strategy returns two different types, the valid value on success and the failure information on failure, and expects the caller to perform an instanceof check to determine success.

To summarize my personal results on my computer, There is little cost surrounding building the failure information string (compare Control to Detect), as long as the values being concatenated are already strings. In other words, StringBuilder is pretty optimized. There is little cost in generating a new object that is immediately used in a return/throw statement (compare NoTrace, Result, and Sentinel). My assumption is that this is due to the new performance optimizations surrounding the allocation of objects and/or the fact that object creation/access can now be inlined. The performance of raw exceptions is about 2 to 3 times worse than the other strategies pretty much all the time, but disabling the stack trace gives very comparable performance until the failure rate is about 25% or so. Since disabling the stack trace requires a subclass (without any bytecode manipulation), this can only be used effectively on locally written exceptions. In particular, when creating business failure exceptions, simply overloading this method will give comparable performance to other solutions while using the language feature exactly as it is intended.

How slow are Java Exceptions?

This is a response to a StackOverflow question, but it got a bit too long to leave as an answer on the site.

The real question here is not “How slow are ‘failures reported as exceptions’ compared to ‘code that never fails’?” as the accepted response might have you believe. Instead the question should be “How slow are ‘failures reported as exceptions’ compared to failures reported other ways?”

It’s commonly accepted that the paradigm for exceptions is “Never throw an exception you intend to catch.” So, it’s appropriate to throw an exception when someone else will catch it, such as platform/framework API’s, or when writing some utility API such as logging or messaging that needs to communicate extra-VM failures such as file or network IO errors.

This is all well and good, and no one would debate throwing an exception in these cases. But let’s look at what happens in a simple method that could fail sometimes. Let’s say we have the following method signature:

   /**
     * Transforms SomeClass into SomeOtherClass.
     * @param input some class instance
     * @return the transformed instance,
     *         or null if the transformation was unsuccessful
     */
    public SomeOtherClass transform(SomeClass input)

Which means our callers all look something like this…

    SomeClass input = ... // get the input from somewhere
    SomeOtherClass result = transform(input);
    if(result == null) {
       // handle the failure
    } else {
       // use the result
    }

But now we want to start communicating what went wrong when transform returns null. The easy thing to do is the following:

   /**
     * Transforms SomeClass into SomeOtherClass.
     * @param input some class instance
     * @return the transformed instance, never null
     * @throws TransformationException on failure
     */
    public SomeOtherClass transform(SomeClass input) throws TransformationException

To pull this off inside the method implementation, you just turn all those “return null;”‘s into “return new TransformationException(“reason”);”‘s. And how would the callers change?

    SomeClass input = ... // get the input from somewhere
    try {
       SomeOtherClass result = transform(input);
       // use the result
    } catch(TransformationException e) {
       // handle the failure
    }

It’s worth noting that absolutely no one read the previous code block. It’s unsurprising. You see that kind of stuff every day in your code. It doesn’t register as a smell, because in fact, it isn’t. But let’s say that one day you start reading about how bad it is to use exceptions on “expected” failures. Now, the very concept of catching an “unexpected” exception is ridiculous, as the act of writing the catch block and handling the exception clearly indicates an expectation. But that doesn’t matter, we all start churning our code looking for a smell that’s very hard to identify. When we find such a place, we fall back on the ancient C practice of returning a sentinel value.

   /**
     * Transforms SomeClass into SomeOtherClass.
     * @param input some class instance
     * @return the SomeOtherClass instance or, 
     *    if the transform fails, a TransformFailure instance 
     */
    public Object transform(SomeClass input)

Which means our callers now have to write some pretty psychic code.

    SomeClass input = ... // get the input from somewhere
    Object result = transform(input);
    if(result instanceof SomeOtherClass) {
       SomeOtherClass success = (SomeOtherClass)result;
       // use the result
    } else {
       TransformFailure failure = (TransformFailure)result;
       // handle the failure
    }

So, if you consider using exceptions to be a smell but were perfectly fine with breaking type-safety, you’d wind up with something that’s difficult to maintain, impossible to use, and only about twice as fast as the exception-based solution. But you’re not fine with breaking type-safety, because it’s horribly reckless behavior unjustified by a simple 2x improvement. So instead of sentinel values you decide to use a result object.

   /**
     * Transforms SomeClass into SomeOtherClass.
     * @param input some class instance
     * @return the TransformResult instance
     */
    public TransformResult transform(SomeClass input)

And now the calling code looks something more like the following:

    SomeClass input = ... // get the input from somewhere
    TransformResult result = transform(input);
    if(result.isSuccess()) {
       SomeOtherClass success = result.getSuccess();
       // use the result
    } else {
       TransformFailure failure = result.getFailure();
       // handle the failure
    }

And now we have a solution that is cryptic, though manageable, but this time, it’s twice as slow as using the exceptions in the first place, even if you merge the code between TransformResult and TransformFailure. Again, let me be clear: Result objects are slower than exceptions even when failures happen half of the time. You’re creating a new result object every time, instead of exceptions only when you need them. It just doesn’t make sense.

There’s one more argument for exceptions I’d like to make. Let’s say someone comes along and uses the transform method without checking the javadocs. In the exception case we see the following:

    SomeClass input = ... // get the input from somewhere
    SomeOtherClass result = transform(input);
    // use the result

In the exception case, they will know the return type, and if it’s a checked exception, they’ll either have a compile failure or have to declare it in the throws clause. Even if it’s unchecked, the failure will still propagate. Now consider the sentinel case:

    SomeClass input = ... // get the input from somewhere
    SomeOtherClass result = (SomeOtherClass)transform(input);
    // use the result

Here the unaware user will write code that looks perfectly acceptable until it fails at runtime. At that point, all of that failure information you worked so hard to provide will be lost to a ClassCastException. And the result object is no better.

    SomeClass input = ... // get the input from somewhere
    SomeOtherClass result = transform(input).getSuccess();
    // use the result

Again, this looks like perfectly normal code. There’s no reason to suspect at runtime there will be the same NullPointerException they would have seen if they blindly used the first method in this post that had no failure information.

The main point here is that in the event of a failure handling logic error, the exception case works exactly like it should, reporting the failure information. But the other solutions result in absolutely useless exceptions, which even if you correct and redeploy the software, will still result in the failure, just this time with the information you thought you were getting the first time.

So, the only logical conclusion is this. If you need to report failure information, then use an exception. It’s faster than result objects, safer than sentinels, and is far and away the least surprising solution.

Identity over Zealotry

I think “Identity over Zealotry” belongs in the list. Just because I think there’s a right way to do something or say something or approach something doesn’t make it right, or better-than-yours, or even good. I find that the Agile Manifesto comes pretty close to expressing my values in a clear concise way. That said, I’m not sure too many other people find it clear and concise. I know quite a few folks who look at the list as binary and binding; a statement of what I as a agile adopter expect, or demand, or just flat out won’t do. But that’s not it at all, at least for me. It’s a set of statements I identify with; it expresses what I’ve learned to value.

So from time to time I rewrite the Agile Manifesto in a way that hopefully more clearly and much less concisely captures how I’m feeling about it at the time. My latest one is patterned after story cards, or at least, patterned after the story card pattern. Basically I wrote a Mad-Libs style statement and filled it in with words consistent with my value system. Here’s the structure for the value statements:

Your <something you value> is important to me. If I ask that we change <some action we engage in>, it is to improve our shared understanding of <some quality of our working relationship>. So to help you better <manage the “something you value”>, I believe that I should <act in ways that respect the things you value>.

Let’s look at the first one, a rewrite of “Individuals and Interactions over Processes and Tools”.

Your time is important to me. If I ask that we change what we do or use, it is to improve our shared understanding of each other. So to help you better utilize your time,

• I should make deployable software available as part of my routine. (3)
• I should meet with stakeholders regularly and frequently. (4)
• I should prefer to use more personal forms of communication. (6)

Basically I think the agile manifesto is making a value statement that we care more about the relationships between the Who’s rather than constraining the How’s. The numbers off the ends of the “I should” statements are mappings back to the Agile Principles, for those folks who might be interested. In particular, it’s worth noting that in this way of looking at the manifesto, it’s an expression of what you can expect from me given that I have this outlook. It’s about the changes I’m going to introduce. I’m not going to ask that we follow new processes or introduce new tooling for the sake of my time, but rather for the sake of yours. I’m interested in us understanding each other, in communication and dialog, not in shiny gadgets and constraining workflows.

On to “Working software over comprehensive documentation”.

Your project is important to me. If I ask that we change what we generate, it is to improve our shared understanding of where we are now. So to help you better manage your project,

• I should write software that speaks for itself as early and as often as possible. (1)
• I should provide reliable and current information to encourage emergent solutions. (11)
• I should understand my effectiveness to become more effective. (12)

Here I’m making a statement about the kinds of artifacts I’m going to introduce. I don’t value a bunch of pre- or post-documentation. And I’m not going to hide behind artifacts to give you a rosier picture of the state of the project. But that doesn’t mean I don’t value the documentation you’ve asked me to produce.

What about “Customer collaboration over contract negotiation”?

Your vision is important to me. If I ask that we change what we agree to, it is to improve our shared understanding of where we are going. So to help you better achieve your vision,

• I should accept that agreements can and will change. (2)
• I should maintain a sustainable pace in my work effort. (8)
• I should pay continuous attention to technical excellence and good design. (9)

And finally, “Responding to change over following a plan”.

Your experience is important to me. If I ask that we change what we commit to, it is to improve our shared understanding of how we get there. So to help you better leverage your experience,

• I should structure my environment to best get the job done. (5)
• I should demonstrate progress with working software. (7)
• I should increase the work that doesn’t need to be done. (10)

I don’t think there’s anything wrong with planning. I do think it is dangerous to commit when your experience tells you it is not safe to commit. I want to structure my environment and the software in a way that you can commit with confidence. And I want to identify and eliminate waste so that no one has to commit to doing it.

So there you have it. My latest exposition on the manifesto. The manifesto isn’t taking a box of 8 things you really care about and throwing 4 of those things out the window. It’s making a statement that says that I know you’ve been burned by software developers and teams before. I know you’ve had developers try to convince you that the only way to succeed is to follow some convoluted process or rigorously use a bunch of time-waste inducing tools. I know you’ve had developers dump mounds of documentation on your desk and claim that the system they’ve designed is perfect for your needs, they just need X more years to finish the software. I know you’ve had developers put line items in their contracts so they get paid even if you don’t get what you paid for. I know you’ve had developers try to force you into a plan covering months or years that completely ignores the fact that your business and the market changes. I’m not one of those developers.

And moreover, I’m not asking you to trust me. I’m showing you how you can test me. I’m going to introduce change. You’ve hired me because you want change; you want success where you’ve only had failure. I’m going to work with you to achieve that success, and here’s how you can tell: You’re going to talk to me, not my email, not my layer, not unreadable documentation, and not a convoluted process.

And when you talk to me, you’ll see the software. You’ll get to poke it and prod it and tell me to my face what you hate about it. And then I’ll fix it and show it to you again. And after we do that enough times, you won’t hate it so much. And we’re going to get to that point as soon as possible, because that’s when we’re going to start developing software that matters.

The Agile Golden Rule

The Manifesto for Agile Software Development is perhaps one of the greatest published works in the field of software development. It has had a tremendous effect on the software community and inspired any number of processes, tools, documents, contracts and plans. This is somewhat curious, since the very essence of the Manifesto is that these things, while valuable, are of lesser value when compared to motivated individuals collaborating and interacting to produce working software even in the face of certain change.

So Agile adoption is a very precarious precipice. If you believe you’re Agile because you’ve implemented the latest Agile Methodology across your organization, you’ve completely missed the point. You’re not putting control in the hands of the motivated individuals, but in the hands of the processes, tools, documents, contracts, and plans. A few people who have come to this conclusion and have dubbed their reaction to this revelation as Post-Agile. So rather than recommending the Agile Methodology du jour they advocate instead one should “simply do whatever works for you.”

Now, this is all well and good, but if you’ve ever experienced the flaming hoops through which you must dive just to get a well-published, oft-implemented official Agile Methodology pushed through your organization, the hairs on the back of your neck stand up when someone suggests you should instead simply do whatever works for you. Management has a difficult enough time with things like Scrum and XP. They’ll laugh you out of the room if your best defense for a new practice is “well, I think it’ll work for us.”

So, where are we then? The Manifesto stays silent on how we should actually achieve the Principles. The Methodologies tend to fail miserably when implemented strictly by the book. The Post-Agilists have left us with hopelessly little. Agile is worthless if we can’t do it.

This is one of the deepest misunderstandings surrounding Agile. Agile is not prescriptive, instead it’s the realization that being proactive is to be intensely reactive. Agile is characterized not by what you do, but by how you can do it better. Agile Methodologies are not Agile in themselves, they are snapshots of the current process and practice of a few agile shops. If those shops are truly Agile, by the time you implement what they were doing, they’ll be doing something completely different.

Agile is not a set of rules, it’s a set of principles; ideals to move towards, not laws to govern. So in a sense the Post-Agilists are right, do whatever works. But if that’s the case, how do we know what will work? If Agile isn’t prescriptive, how do we know what to do? How do we know how to do it better? What are the guidelines for determining whether something is more Agile than something else?

It is my claim that there is only one rule to Agile, the Agile Golden Rule, and it is simply this: Communicate with others as you would have them communicate with you.

The most critical point here is that communication is possible under any methodology. Whether you’re an agile shop or following strict waterfall, you have the right and privilege of having a completely transparent, trusting, open dialog with your fellow stakeholders on the project.

That said, while communication is independent of the methodologies in place, it is a sad but true fact that processes, tools, documents, contracts and plans can make open dialog difficult to the point of impossible. In those circumstances, I’m afraid I can do little more than offer my condolences; I have been there before and I know your frustration. But at the very least, you have a clear indication of the barrier to developing better software. I encourage you to work to remove the barrier or work to remove yourself.

Dialog is difficult even when the channels for communication are fairly open. Work to keep the channels open; make sacrifices if it comes to that. Protect your right to engage in dialog with your fellow stakeholders. This is the core and heart of Agile; if we put our heads together we can come up with something better.

My Development Creed

I believe software development is a conversation between individual developers, users, clients, managers, testers, analysts, architects, operators, lawyers, accountants, CxO’s and occasionally the janitor.

I believe software is valuable in as much as it satisfies the concerns of all these parties; specifically, valuable software is maintainable, usable, and cost-effective.

I believe compromises between these concerns are an unavoidable and necessary consequence of the conversation.

I believe processes, tools, documents, contracts, and plans can help manage these compromises.

I believe the individual participants, through collaboration and interaction, can respond to inevitable change to produce working software more valuable than compromise alone could deliver.

I believe change can be more efficiently handled by more confidently understanding the current state and direction of the individuals, rather than the current state and direction of the processes, tools, documents, contracts, and plans.

My goal is to research and develop ways to facilitate open dialog throughout the software lifecycle from inception to retirement.