Norman Richards

Seamless in San Diego

I'm heading to San Diego to give a Seam talk at SDJUG tomorrow. That's Tuesday, August 19th at 7pm, to be specific. This will be be the "10 things you need to know about Seam" presentation, where I go over what I consider to be the most important details someone needs to know to make an informed decision about whether Seam has a place on their project.

Hope to see you there if you are in the area.

Seam talk in St. Louis (this time for real)

I was supposed to give a Seam talk at the St. Louis JUG earlier this year, but due to some particularly nasty weather the meeting had to be cancelled. Fortunately we were able to reschedule for the warmer month of July.

I'll be there this Thursday (July 10th) giving a brand new Seam talk: 10 things you need to know about Seam. I'll cover my own take on the 10 most important things you should know about Seam. If you have been considering Seam, but haven't been able to pull the trigger or if you just haven't figured out why Seam is worth considering in the first place, then you should definitely stop by.

Hope to see you there!

updated with correct link to the meeting

Technologies I'm learning now

It's about half-way through the year, so I thought I might catch up my new "stuff I'm learning" list. Here's the three things that are (or soon will be) taking up most of my learning time:

Git

At the beginning of the year, I wanted to learn about distributed version control. The two choices were git and mercurial. After a bit of research, I decided to give git a try. I've been using git (hosted at github) for 3 or 4 months, but for some book work and for some of my side projects. I still don't have it completely figured out, but I really like it. I want to learn about the svn bridge so that I can do my Seam development locally in git, pushing my work back into the project svn later.

Cocoa Touch

I've been working on an iPhone app in my spare time. While I'm still troubled by how absolutely primitive Objective-C is compared to Java, I really am liking Cocoa Touch. The APIs are still a bit slim, but like desktop Cocoa, it's really well thought out and easy to use. App store here I come!

Amazon WS

I've just barely gotten started here, but I'm fascinated by S3 and EC2. I'm definitely going to play with them over the next few months. As a software guy, I really like the idea of commoditizing server power and bandwidth like this so that I can just focus on getting my app working.

Seam talk at Houston JBUG

I'll be heading down to Houston tomorrow (Wed 2/27) to give a talk on Seam at the Houston JBUG. Since I've given a few Seam talks to the group over the last few years, so instead of my typical intro to Seam talk, I'll be giving more of a roadmap talk. I'll spend a little time talking about the new features in Seam 2.0, then I'll talk about our plans for the 2.0 and 2.1 branches. Finally, I'll talk about plans for Seam 3.0 and WebBeans.

If you are in the area, I hope to see you there!

Seam talk at St. Louis JUG (Thurs 2/21)

I'll be giving a Seam talk tommorrow (Thursday) at the St. Louis JUG. In the talk I'll give an intro to the basic concepts of Seam and demo the Seam support in JBoss tools. If you are in the area, please stop by and say hi!

Seam talks at Denver and Boulder JUGs

I'm just about to fly out to Colorado for a few JUG talks. I'll be at the Boulder Java Users Group on Tuesday (Jan 8th) and at the Denver Java Users Group on Wednesday. (Jan 9th) In both cases, I'll be talking about Seam. I'll talk about Seam and demo the Seam part of JBoss Tools / JBoss Developer Studio. This will be my first Seam talk since we released Seam 2.0, so it should be a lot of fun showing off some of the new stuff. Hope to see you there!

EL in JSP should be escaped by default

I just ran across a proposal by Matt Raible for an extension to Tomcat for defaulting to escaped EL. This is something that absolutely needs to be done, not just for Tomcat but for all web containers.

It's absolute lunacy that the default is to not escape values. If you've ever created a publicly accessible web application, it takes all of about 15 minutes before you quickly realize that you need to aggressively escape any displayed data that is potentially modified by the user. You should really escape everything, even things that are assumed to be "clean" already. Since you almost always want escaping, a ${simpleExpression} should default to escaping so you don't have to litter your page with <c:out>ugly tags</c:out>.

When you so do have a variable that contains HTML that needs to go directly to the page, then using the c:out tag with escapeXml="false" should be required. In those rare cases, the extra work required is reasonable. It also alerts anyone working on that page that the expression is potentially dangerous and should be handled with extreme care.

So, here's my +1 for Matt's proposal. I hope future JSP specifications will correct this horrible default so that we aren't limited to non-portible hacks in specific web containers.

Should developers define annotations?

I've said many times that I think annotations are a lot like AOP. AOP is great, but I don't believe application developers should be writing their own aspects. They should be making use of the aspects provided by framework developers. (As a side note, annotations are the best way I've seen to apply apply aspects) Similarly, developers should embrace the use of annotations wholeheartedly, but in general they should be using annotations created by framework developers and not creating their own application-specific annotations.

The reasoning behind that is that annotations (I'm referring primarily to runtime annotations here) need to be processed by something to have meaning. No framework is going to be able to attach useful meaning to a user-defined annotation, so user-defined annotations imply user-defined annotation processing code. I don't like the idea of that at all, so it's been quite easy to say annotation definitions should strictly be the domain of framework developers.

The flaw in the argument is rather obvious now. I stand by the assertion that application developers should not be writing annotation processing code. However, it's simply not true that user-defined annotations imply custom processing code.

The key to this is the meta-annotation. An annotation definition itself can be annotated in a way that tells the annotation processor how to deal with it. A simple example of this is a Hibernate validation annotation. Here's a validation annotation I wrote before Hibernate validator had the @Digits annotation. The @ValidatorClass annotation alerts Hibernate validator to pay attention the @Digits and defines what how the framework should interpret the annotation.

@ValidatorClass(DigitsValidator.class)
@Target({ElementType.METHOD, ElementType.FIELD}) 
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Digits {
    int integerDigits();
    int fractionalDigits() default 0;
    String message() default "invalid numeric value";
}

I've generally assumed meta-annotations would be the exception rather than the rule, but Web Beans has turned that assumption upside down. In Web Beans, it will be quite common for application developers to write meta-annotations for interactions with almost every part of the framework. Here's a quick example from Gavin's Web Beans Sneak Peak series. A type-safe injection point might look like the following:

@In @PayByCheque PaymentProcessor chequePaymentProcessor;

@In defines this as an injection point, and @PayByCheque is a user-defined annotation that defines what type of injection is to occur. Here's the definition:

@BindingType
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD})
public @interface PayByCheque {}

You might be wondering what is going on here. @BindingType is the meta annotation that tells Web Beans that this is annotation marks a binding type, but where is the information that tells Web Beans how specifically to deal with this annotation? For that, we have to look at the corresponding component definition.

@Component @PayByCheque
public class ChequePaymentProcessor implements PaymentProcessor {
    public void process(Payment payment) { ... }
}

One the injection side, the user-defined annotation is paired with @In. On the component declaration side, it is paired with @Component. The annotation provides the link between the points. Compare this to the current version of Seam (or Web Beans using named components) where this binding is done by a textual name. It might seem that annotations are just a unnecessarily complex replacement for a text string, albeit one that is much friendlier to refactoring and side-steps the messy name collision and namespace issues that you get with plain strings. But, actually Web Beans allows annotations to be combined in very interesting ways. Again, an example:

@In @Asynchronous @PayByCheque paymentProcessor;

Here, @Asynchronous is a user-definied annotation that is combined with @PayByCheque to uniquely reference a Web Bean. I think this is particularly clever because it eliminates name mangling and turns the name modifiers into language constructs that can re-used throughout a system.

If you look closely at the Web Beans draft, you'll see the concept permeates through Web Beans in a surprisingly diverse set of ways. It's enough to convince me that user-defined annotations really are useful and that application developers probably will be regularly defining their own annotations.

Getting closure on inner classes

On the most recent episode of The Stack Trace, Sam and I talked a bit about Java inner classes and how I solved a long-time problem I've had with trying to pass information out of a Java inner class. This can be rather hard, because inner classes really only for a very weak closure around their scope. The closure over the enclosing method (input parameters, local variables) is essentially read-only. Only final variables can be closed over, and final variables cannot be changed. The object referred to can be mutable, but the enclosing scope can never see a new object. For example:

public void myMethod() {
    String x = "original value"; // must be final

    new Runnable() {
        public void run() {
            x = "new value";  // but if it were, we couldn't do this
        }
    }.run();

    System.out.println("The value is " + x);
}

This is not valid in Java. The way inner classes are implemented, the Object that x refers to is basically passed by value into the object behind the scenes, and the inner class itself has a new field that just happens to be called x and just happens to point to the same object the outer x does. If the implementation doesn't have any link to the variable named x, there's no way to change the value. Thus, we have the infamous decision that made inner classes only able to close over final variables. If you make all the cases where your weak implementation doesn't work invalid, then your weak implementation works - Q.E.D.

(side note: in the special case of strings, the Java compiler actually optimizes the code by placing the String value in the constant pool of the inner class and doesn't actually pass it in. But in the general case, the description is correct)

The problem here is similar to the swap problem. In Java you can't write a swap function with side effects. In C++, it's trivial to do by passing references around:

void swap(int &x, int &y) {
  int tmp = x;
  x = y;
  y = x;
}

Java doesn't have the notion of being able change the value a variable points to by passing a reference to it along. However, it is obviously possible to get a similar effect in Java using a wrapper class.

public class Reference<T> {
    T value;
    public SimpleReference() { }
    public SimpleReference(T value) {
        setValue(value);
    }
    public T getValue() { 
        return value; 
    }
    public void setValue(T value) {
        this.value = value;
    }
}

Going back to the inner class example, we could then write something like the following. It's not beautiful, but Java generics make it relatively palatable. Conceptually it's not any different than thinking to pass an object pointer along.

public void myMethod() {
    Reference<String> x = new Reference<String>("original value");

    new Runnable() {
        public void run() {
            x.setValue("new value");
        }
    }.run();

    System.out.println("The value is " + x.getValue());
}

It really got me thinking though. Why doesn't the compiler just do that for me automatically? The compiler knows what variable in the enclosing scope need to be a part of the closure. It has to verify that they are all final. There's no reason that instead of checking that they are final that it couldn't wrapper all of them with a Reference object, calling getValue()/setValue() as necessary. The code would then read identically as the first Java example above, and inner classes would have had a much more interesting form of closure than they do now.

If you are concerned about too much magic behind the scenes, keep in mind that inner classes already can add a number of synthetic fields/methods to your classes as is. And having a method call behind the scenes is not really any different that a construct like Foo.class which generates bytecode to call Class.forName(). It may be too much magic for the Java 1.1 days, but by today's standards it's not the least bit wild. Think about what goes on behind the scenes for an enhanced for loop.

A couple final points. First, I'm sure the language designers could come up with a more interesting way to get a more powerful form of closures into inner classes. I'm just saying that it looks like there was at least one incredibly trivial implementation option available.

Second, I do realize that even if inner classes had a more complete closure, that doesn't really address all the things people want today. People want closures that don't feel like separate classes and that can be used to implement interesting control structures. Real blocks with closures would (we hope) also have much better syntax than inner classes do now. Nonetheless, I think it would still have been significantly better than what we have now.

Finally, I'm sure I'm not the first person to do this. However, I've never seen this technique before, and I have done quite a bit of searching to find solutions. It's nothing spectacular, but it did solve a very big problem I've had for years. I hope it helps someone else out there.

Finally learning Maven

Now that Seam has moved to Maven, I figure I need to actually learn a bit more about it. I've not been very motivate to dig very deeply into it, given that my past experiences with Maven haven't been entirely positive. However, the Ant/Maven combo we are using in Seam avoids most of the issues I've had with Maven, so I'm happy with what we are doing.

In any event, I need to learn Maven. Sam recommended Better Builds with Maven as a great resource. Since it's a free book, I thought I'd pass along the reference to anyone looking to learn Maven.