By the way, I can see one class with 40 or more dependencies. This is what we call a Façade.

Best regards,
George.

bean class="org.springframework.beans.factory.annotation.RequiredAnnotationBeanPostProcessor"
p:requiredAnnotationType="Mandatory"

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Mandatory {
}

Register this annotation with the RequiredAnnotationBeanPostProcessor

You can now use @Mandatory on the setter methods.

public class Foo{
private final Service service;
private final SomethingElse somethingElse;

public Foo(FooOptions opts){
assert( null != opts );

service = opts.service;
somethingElse = opts.somethingElse;
//don't perform checks on opts, instead on local vars, as callers may have changed opts in the meantime
assert( null != service );
assert( null != somethingElse );
}
}

public class FooOptions{
public Service service;
public SomethingElse somethingElse;
get/set….
}

You could also use the getters/setters in the options bean.

IMHO the advantage of this approach is that if subclasses need further args, just subclass the options bean, and no further changes to your classes are required.

It would be nice if Java supported automatic generation of constructor options beans (ie like named arguments I guess), or allowed inner classes without the need for an instance of the outer class so that these options can be kept in the same file.

Another approach is using an interface:

public class Foo {
public Foo(FooOpts opts) {
//..assert(…)
service = opts.getService();
somethingElse = opts.getSomethingElse();
//..assert(…)
}

public interface FooOpts {
public SomethingElse getSomethingeElse();
public Service getService();
}
}

and an example usage might be:

Foo foo = new Foo(new Foo.FooOpts(){
public Service getService() {
return "My Service";
}
public SomethingElse getSomethingElse() {
return "SomethingElse";
}
});

My personal take on setters vs constructors, is that the setters clutter up the API you are trying to expose, and you also end up with a lot of boring boilerplate get/set. IMHO objects should expose business logic, and not all the other junk for settings the object up. In the case of an options object, it doesn't contain any business logic, its just a transfer object, in which case get/set is fine and doesn't add to the confusion

Does anyone know how to configure Spring to use the Common Annotations 1.0 which come with Java 6. e.g. @PostConstruct, @PreDestroy, @Resource and @ConstructorProperties ?

thanks for your comments. I'll try to update the blog post when I have time, because mentioning the possibility to mix constructor injection and setter injection is definitely something that should have been done from the start.