About Tomasz Nurkiewicz

Java EE developer, Scala enthusiast. Enjoying data analysis and visualization. Strongly believes in the power of testing and automation.

instanceof operator and Visitor pattern replacement in Java 8

I had a dream where instanceof operator and downcasting were no longer needed but without clumsiness and verbosity of visitor pattern. So I came up with the following DSL syntax:

Object msg = //...
    is(Date.class).    then(date -> println(date.getTime())).
    is(String.class).  then(str -> println(str.length())).
    is(Number.class).  then(num -> println(num.intValue())).
                     orElse(obj -> println("Unknown " + obj));

No downcasting, clean syntax, strong-typed and… perfectly achievable in Java 8. Using lambdas and a little bit of generics I created a tiny library called typeof that is clean, easy to use and more robust than instanceof and Visitor pattern taken together. Advantages include:

  • no explicit downcasting
  • avoids instanceof
  • clean and easy to use
  • strongly typed
  • works with classes that we have no control over, including JDK

This small utility was developed with Akka and Java API in mind to limit the usage of instanceof operator, but it’s much more general. Similarly you can return something depending on the runtime type:

int result = whenTypeOf(obj).
    is(Date.class).thenReturn(d -> (int) d.getTime()).
    is(TimeZone.class).thenReturn(tz -> tz.getRawOffset() / 1000).

The library examines every is() clause from top to bottom and stops if it finds first matching class, including parent classes – so is(Number.class) will match both Integer and Float. If none of the conditions matched, calling get will fail with exception. You can override this behaviour using orElse() (easier to read than equivalent is(Object.class)):

int result = whenTypeOf(obj).

DSL takes advantage of static typing in Java, making it nearly impossible to use the library incorrectly – most mistakes are caught immediately during compilation. All code snippets below won’t even compile:

//ERROR - two subsequent is()
//ERROR - then() without prior is()
    then(x -> println(x))
//ERROR - mixing then() and thenReturn()
    is(Foo.class).then(foo -> println(foo)).
    is(Bar.class).thenReturn(bar -> bar.getB());

Basically you start by typing whenTypeOf() and Ctrl + space will tell you precisely what is allowed. The key to designing type-safe and robust DSLs in statically typed languages is to limit the API as much as possible so that invalid states and calls are avoided at compile time. You will end up with a proliferation of tiny classes, but that’s OK, your users won’t see this. For example check out FirstIs.java – an object returned after first is() invocation:

public class FirstIs<S, T> {
    final Then<S> parent;
    private final S object;
    private final Class<T> expectedType;
    public Then<S> then(Consumer<T> thenBlock) {
        if (matchingType()) {
            return new TerminalThen<>();
        return parent;
    public <R> ThenReturn<S, R> thenReturn(Function<T, R> result) {
        if (matchingType()) {
            return new TerminalThenReturn<>(object, result.apply(castObject()));
        return new ThenReturn<>(object);
    public <R> ThenReturn<S, R> thenReturn(R result) {
        if (matchingType()) {
            return new TerminalThenReturn<>(object, result);
        return new ThenReturn<>(object);

Writing DSLs is much harder than using them, but it’s quite rewarding in the end. Notice how different return types are used (Then vs. ThenReturn) just to make sure only valid methods are accessible at each stage. An alternative is to implement run-time checks (for example that you don’t write is(...).is(...).then(...)) – but why bother if compiler can do it for us?

I hope you enjoyed this article, let me know if you are willing to try this utility in your project. It’s available on GitHub.

Related Whitepaper:

Bulletproof Java Code: A Practical Strategy for Developing Functional, Reliable, and Secure Java Code

Use Java? If you do, you know that Java software can be used to drive application logic of Web services or Web applications. Perhaps you use it for desktop applications? Or, embedded devices? Whatever your use of Java code, functional errors are the enemy!

To combat this enemy, your team might already perform functional testing. Even so, you're taking significant risks if you have not yet implemented a comprehensive team-wide quality management strategy. Such a strategy alleviates reliability, security, and performance problems to ensure that your code is free of functionality errors.Read this article to learn about this simple four-step strategy that is proven to make Java code more reliable, more secure, and easier to maintain.

Get it Now!  

Leave a Reply

six − 2 =

Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books