Is there some syntax (other than a series of if statements) that allows for the use of a switch statement in Java to check if an object is an instanceof a class? I.e., something like this:

switch (object) {
     case instanceof SecondObject:
     case instanceof ThirdObject:

Sidenote: I recognize that as a design pattern, checking against instanceof and making decisions based on it is not as preferable as using inheritance. To give some context why this would be useful to me, here's my situation:

I'm working on a project that involves a kryonet client/server. For communication over KryoNet, you pass objects that it serializes using kryo. Anything added to the object increases the size of these packets,1 so to minimize the network traffic, you keep these objects as light weight as possible. When you receive a packet, you need to know what to do with it, so I'm making this determination based on what type of packet object the passed object is an instanceof. This approach is the same undertaken in the examples included with Kryonet's distribution. I'd love to clean up the hideous class that translates these packets into action, and figure a switch statement would at least make it look moderately more organized.

1As I wrote the statement above, I had doubts about whether what I was saying was accurate. The answer below seems to disagree:

Methods don't add anything to the runtime size of an object. The method code is not transmitted, and nothing about the methods requires any representation in an object's state. This is not a sound reason for instanceof testing, etc.

I guess the real issue is I don't know what happens under the hood for Kryo to serialize an object and I was nervous to do anything that increased the bandwidth. Your answers have inspired me to do it with inheritance and add the appropriate methods to the objects. So thank you!

  • 1
    Whatever you intend to do before each break violates the LSP. Feb 20, 2013 at 20:26
  • I think this is a good workaround. Feb 2, 2015 at 19:06
  • man, coming back to java after using scala... I miss the kind of feature like the match-case :(
    – Juh_
    Jul 4, 2019 at 10:12

5 Answers 5


I fully realize that I am 2 years late to the party :-) but probably few clarifications will help other devs.

What the other answers missed to address was the mentioning of the "Kryonet" which adds additional twist to the problem: usually when kryonet is used it means that

a) the client is an android app and

b) the client is some game

If both conditions are met IMHO using the instanceof if-else sequence is the way to go.

The usual way of structuring client/server app in our case android game + "pure" java server is to use (at least) 3 projects:

  • "common" - which contains code common for the server and the client, most importantly all the message classes (which usually implement some tag/marker interface as GameMessage).
  • server - contains the server and includes the common project. Usually all messages are simply registered in Kryonet, i.e. no pooling is used (because on server GC is not considered a problem)
  • android client - contains the android app (game) and includes the common project. Because in java games creating objects during the game may trigger the GC it is considered the biggest mortal sin (which leads straight to the hell of missed frames) it is considered good practice1 to use object pooling for the game messages (this requires little customization on the Kryonet/kryo in order to use object pools). All messages are (must be) registered in kryonet in the same order as on the server in order things to work.

First, lets look at the alternatives and see why they are not fit for the structure/implementation described above:

1. They say 'Use polymorphism and method overriding'

Take a look here for an example of the proposed solution (accepted answer by jmg). It looks very elegant but there there are at least 2 big problems:

  1. You can't just use parameterless overrided method like do() because in real implementation you will some need external data to act upon. For example when receiving PlayerAbandonedGame message on the server you will need at least the particular game object as parameter in order to call removePlayer(Player pl) method. NewGameState message will require reference to the particular GameState variable that will be updated and so on. One very ugly solution is overrided method to have single parameter like TheWholeThing which contains all the objects that may be needed. It is needless to say that this not only violates the principle of encapsulation but also "spreads" the game logic across multiple message classes.

  2. Remember that we have the common project and all the messages are defined there. Even if server-to-client messages are completely distinct set to client-to-server messages it will be simply stupid to put server or client logic in the common project.

Game message objects are just data containers. It is up to the server or the client to handle that data in a particular way (or even ignore it as often happens with out of order UDP messages).

2. They say 'Use reflection'

Our context is 'a) the client is an android app'. The reaction of every android developer hearing Use reflection should be to stand up, clear his/hers throat and with his/hers best british accent to say: 'Are you completely mAd?!' :-)

Reflection is very slow on older Android versions, it is slow even now (5.0). Also IMO using reflection is the ugliest possible solution not just for this particular problem. It should be avoided up in the stack, i.e. in app dev.

Way to go

Back to the original question: if one really insist on using switch the solution is to have base class like:

public abstract class GameMessage {
    byte mCode; // not private because of kryo

    public GameMessage(byte code) {
        mCode = code;

    public byte getCode() {
        return mCode;

concrete message will look like:

public class PlayerAbandonedGame extends GameMessage {
    // some fields

    public PlayerAbandonedGame() {
        super((byte) 42);

and then message handler will look like:

public synchronized void onMessageReceived(GameMessage msg) {
    switch(msg.getCode()) {
        case 42:
            // do something
            mLogger.error("Unknown message code {}", msg.getCode());
            // may be even throw an exception?

    // ...

Of course it is advisable to use enum values instead of hardcoded numbers...

Potential drawback is (as mentioned in other answers) if you create new message class and forget to add it to some of the switch statements. The compiler cannot catch this problem and you will hit it only runtime (in the default case).

Real (small) drawback is that code field is send each time and adds to the traffic. In reality this adds about 1-10% to the size of the messages (if you use byte for the code field).

How I do it

I personally use if-else sequence with instanceof test like:

public synchronized void onMessageReceived(GameMessage msg) {
    if (msg instanceof MyLetterAttemptResult) {
        handleMyLetterAttemptResult((MyLetterAttemptResult) msg);
    } else if (msg instanceof InAutoMatchQueue) {
        handleInAutoMatchQueue((InAutoMatchQueue) msg);
    } else if (msg instanceof AutoMatchRetry) {
    // more else-ifs
    } else {
        mLogger.error("Unknown message {}", msg.getClass().getSimpleName());
        // throw exception may be?

Isn't that "code smell"? You bet it is, but after trying all other alternatives it seems to me that it is best. To reduce the smelliness it is better to try to keep code in the ifs short like above. Just call handle* method and release message back to the pool (if it is pooled).

Isn't that slow? It is a bit slower than the switch(msg.getCode()) but not that much. Here is some benchmarking (answer by Dan Mihai Ile). Advantage is that you don't have the code field send each time over the network. Keep the most frequently used messages at the top so they are found first.

Isn't that error prone? There is a risk if you create new message class and forget to add corresponding else if. The thing is that you have just two separate message handling methods - one on the server and one on the client. Both are the single most important code pieces repectively on the server and the client. You will simply have to not mess it up. Just add the new message class immediately to the unit test that tests onMessageReceived().

This is not OOP! I have a better solution! I will be very happy to discuss it and use it :-). btw, I wonder if @Cameron (the author of this question) found better solution. After all this question is 2 years old...

1 For me avoiding the GC is more like "utter crap" than "best practice". As Eonil commented in 1: I regard avoiding GC on GC based language is a kind of insane trial.

  • 1
    Really do appreciate your response, even if it is a little... untimely. To your question: did I find something better, answer is no. Ended up doing it in the manner you described. Feb 2, 2015 at 20:17
  • To build on what you talk about here, I found this suggested approach. Basically you build a generic matcher class that contains delegation methods. That allows you to use lambdas to build the "swith" on the fly. Little more elegant, but still a little more work.
    – end-user
    Feb 27, 2019 at 1:50

The answer is no.

But using Java 7 you could do this:

switch (object.getClass().getName()) {
  case "some.pkg.SecondObject":
  case "some.pkg.ThirdObject":

... which is not exactly the same, but may be close enough.

The problem is that this is "code smell", whether you do it using if ... instanceof tests or the switch hackery above.


Because any time you add a new class, you need to revisit all of the places where you do this class testing!! And there is the added problem that the code breaks if you rename the classes.

The recommended OO approach is to use polymorphism.

Anything added to the object increases the size of these packets, so to minimize the network traffic, you keep these objects as light weight as possible.

Methods don't add anything to the runtime size of an object. The method code is not transmitted, and nothing about the methods requires any representation in an object's state. This is not a sound reason for instanceof testing, etc.

  • 3
    +1 for mentioning tests and pointing towards polymorphism.
    – mhr
    Feb 20, 2013 at 9:43
  • 2
    I would just like to point out that it might be a better solution to compare not against a concrete string, but against SampleType.class.getName(), as the second would survive an automatic refactoring. Not that I approve this practice...
    – K.Steff
    Feb 21, 2013 at 2:13
  • 2
    @K.Steff - That would not work. The strings in a Java 7 string switch need to be compile time constants ... in the sense defined by the JLS.
    – Stephen C
    Feb 21, 2013 at 13:29
  • @StephenC Sorry, my bad. This makes it one more argument against this practice.
    – K.Steff
    Feb 21, 2013 at 16:34

No, and it's very unlikely that such a thing will be added.

You see, checking for the type of an Object and then doing different things for different types is considered terribly inelegant, because there already is a much better pattern for doing that: using inheritance and overridden methods. (Granted, that's only of use when the "do something" can be formulated as a method call on the checked Object, but usually it can.)

  • revised my question to add some additional background on why I'd be doing it this way in the first place. Feb 20, 2013 at 9:05

In Java, it's only possible to switch on primitives. But you could do something similar.
I think it's some kind of design pattern though I could not find it...

You could hide the if-then-else stuff (which is needed in this case) and wrap it in a kind of switch-class:

public abstract MySwitch{
    public MySwitch(MyObject obj){

        if (obj instanceof SecondObject)
        else if (obj instanceof ThirdObject)

    protected abstract void secondObject(SecondObject obj);
    protected abstract void thirdObject(ThirdObject obj);
    protected abstract void onDefault(MyObject obj);

You could use it then like this in your code:

new MySwitch(obj){

    @Override protected void secondObject(SecondObject obj){

    @Override protected void thirdObject(ThirdObject obj){

    @Override protected void onDefault(MyObject obj){


Just be aware that normally, calling abstract methods from constructor is a bad idea... I think, in this case, it could be OK, because this is and always will be a stateless class. If you don't like it, add an additional method to do the stuff.

This also has the advantage that if you add new classes to your inheritance tree and add a new case, you are forced to update all occurrences and don't forget a switch somewhere.


I think we can do in this way too:

public enum Switch {

then create an interface Switchable:

public interface Switchable {
  public Switch getSwitch();

Then implement switches that take switch type as constrictor param:

public BedRoom implements Switchable {

  private Switch switch;

  public BedRoom(Switch switch) {
    this.switch = switch;

  public Switch getSwitch() {
    return switch;

  public int getBedCapacity() {
    return 2; // implement the way your wish

Then use like below:

Switchable switch = new BedRoom(Switch.BED_ROOM)
switch(switch.getSwitch()) {
  case BED_ROOM:
    BedRoom br = (BedRoom) switch;

    br.getBedCapacity(); // do anything with bedroom methods.
  • this doesn't seem to offer anything substantial over points made and explained in prior 4 answers
    – gnat
    Jun 14, 2018 at 19:24
  • 1
    Welcome to the site! In general there is no point to adding a redundant answer; this question has several long answers, and your answer doesn't add much to this 5 year old question that the existing answers don't. Try to find questions that don't have extensive answers already, and that you can add value to the question.
    – esoterik
    Jun 15, 2018 at 1:04
  • I would use private static Switch switch; and not put it in the constructor. The Switch is related to the class, not the instance, so let's not add weight to those.
    – Juh_
    Jul 4, 2019 at 10:00
  • I don't agree with the comment above: this proposition is indeed an improvement of a solution proposed already but (apart for being mentioned in the middle the other answer) here the use of enum is emphasized from the start. Also the other answer is so long there is a full page of text before reaching the part that is similar.
    – Juh_
    Jul 4, 2019 at 10:07

Not the answer you're looking for? Browse other questions tagged or ask your own question.