Submission: switch (...) instanceof feature

Ulf Zibis Ulf.Zibis at
Wed Apr 22 09:27:10 PDT 2009

Am 22.04.2009 18:06, Gabriel Belingueres schrieb:
> Do you mean memory footprint? You may implement those Strategies as
> Singletons if you know they do not store any state, or even as a
> Flyweights if the different instances are limited. I would keep it as
> simple as possible.

1st I mean jar-footprint, but 2nd I also mean memory footprint and not 
to forget class loading, object initialization and indirection time.

> IMO, readability is not important very important if the application
> life cycle will be short. I would apply the KISS principle again.

Do you think, sun.nio.cs.FastCharsetProvider is kind of short life cycle 
? ;-)

> If the lookup method is the only place you do the instanceof test,
> then it seems reasonable to keep it that way, instead of creating all
> that strategy pattern code.
> However, I can not see how changing the instanceof by a switch
> statement would improve the code,


if..else is good for 2-way fork, but IMHO is better for 
n-way fork.

In case of instanceof additionally casting could be omitted.

>  UNLESS the switch statement adds
> some value, for example that it would perform far better than an
> if-elseif-else chain AND do some checks, like throwing a compiler
> error when I write something like this:


> class A {}
> class B extends A {}
> ...
> switch(o) instanceof {
> case A:
>   // do something with this A instance
>   break;
> case B:
>   // never enter this branch if it's a B because it is always catched by the
>   // previous case
>   break;
> ...
> }

More information about the coin-dev mailing list