Sadek Drobi’s Blog

The use of dynamic type-checking in static languages is often perceived as unavoidable on complex projects, even though workarounds necessary to enforce it tend to negatively impact the quality of code. According to Debasish Ghosh, new features in static languages, i.e. Java generics, offer an opportunity to avoid runtime type checking and optimize the advantages of static typing.

http://www.infoq.com/news/2008/04/get-advantages-of-static-typing

Echoing at a discussion on dynamic vs. static languages, Debasish Ghosh raises the issue of using dynamic type-checking while programming with static languages. He recalls the common generalization of Greenspun’s 10th Law: "any sufficiently complicated program in a statically-typechecked language contains an ad-hoc, informally-specified bug-ridden slow implementation of a dynamically-checked language." 

Ghosh believes that this is not necessarily so today. He argues that Java generics, e.g. Guice and EasyMock, allow avoiding workarounds necessary to enforce runtime type checking:

Using Java generics, these frameworks allow compile time type checking for cases which would earlier have to be implemented using a slow and bug ridden simulation of runtime type checking. Guice and EasyMock stand out as two frameworks I have been using that have used the power of generics to implement extraordinary typesafety. […]

Have a look at this piece of code, which binds an implementation

SpecialServiceImpl to the interface Service using Guice Binder.

public class MyModule implements Module {
public void configure(Binder binder) {
        binder.bind(Service.class)
                     .to(SpecialServiceImpl.class)
                     .in(Scopes.SINGLETON);
}
}”

Even though “it may seem that the "implements" relationship between Service and SpecialServiceImpl is done during runtime”, all type checking is actually done during compile time:

A peek at the source code of Guice reveals that BinderImpl.bind() returns BindingBuilderImpl<T> ..

public <T> BindingBuilderImpl<T> bind(Class<T> clazz) {
return bind(Key.get(clazz));
}

and BindingBuilderImpl<T>.to() takes as input Class<? extends T> - the bound on the wild card enforces the above "implements" relationship as part of compile time type checking of the arguments ..

public ScopedBindingBuilder to(Class<? extends T> implementation) {
return to(TypeLiteral.get(implementation));
}

Debasish Ghosh advocates for using this kind of solutions rather than trying to achieve dynamic type checking. Not only does it allow avoiding the Greenspun’s10th Law but it optimizes the advantages of static typing because it guarantees strong type-safety:

When you are programming in a statically typed language, use appropriate language features to make most of your type checking at compile time. This way, before you hit the run button, you can be assured that your code is well-formed within the bounds of the type system. And you have the power of easier refactoring and cleaner evolution of your codebase.