apache/beam · error · IllegalStateException

The other CEPLiteral should have type , given:

Error message

The other CEPLiteral should have type , given: 

What it means

After confirming the other object is a CEPLiteral, the Byte-typed CEPLiteral's compareTo additionally requires both literals to have the same SqlTypeName (both SMALLINT/TINYINT byte-typed). If the other literal was created with a different type, the library throws this IllegalStateException with the expected and actual type names. It guards against silently comparing literals of different SQL types.

Source

Thrown at sdks/java/extensions/sql/src/main/java/org/apache/beam/sdk/extensions/sql/impl/cep/CEPLiteral.java:79

        throw new SqlConversionException("SQL type not supported: " + lit.getTypeName().toString());
    }
  }

  public static CEPLiteral of(Byte myByte) {
    return new CEPLiteral(Schema.TypeName.BYTE) {
      @Override
      public Byte getByte() {
        return myByte;
      }

      @Override
      public int compareTo(Object other) {
        if (!(other instanceof CEPLiteral)) {
          throw new IllegalStateException("The other object should be an instance of CEPLiteral");
        }
        CEPLiteral otherLit = (CEPLiteral) other;
        if (getTypeName() != otherLit.getTypeName()) {
          throw new IllegalStateException(
              "The other CEPLiteral should have type "
                  + getTypeName().toString()
                  + ", given: "
                  + otherLit.getTypeName().toString());
        }
        return myByte.compareTo(otherLit.getByte());
      }
    };
  }

  public static CEPLiteral of(Short myShort) {
    return new CEPLiteral(Schema.TypeName.INT16) {
      @Override
      public Short getInt16() {
        return myShort;
      }

      @Override

View on GitHub (pinned to 12126d8942)

Solutions

  1. Create the other CEPLiteral with the same SqlTypeName as this literal
  2. Cast/convert the value to the expected SQL type before wrapping it in a CEPLiteral
  3. Log/inspect both getTypeName() values in the exception message and align the condition definition in the SQL pattern
  4. Update the CEP pattern's parameter typing so operands of a comparison share one type

Example fix

// before
CEPLiteral other = CEPLiteral.of(42, Integer.class); // INTEGER
byteLiteral.compareTo(other); // throws
// after
CEPLiteral other = CEPLiteral.of((byte) 42, Byte.class); // matching TINYINT
byteLiteral.compareTo(other);
Defensive patterns

Strategy: validation

Validate before calling

// before comparing two literals
if (a.getTypeName() != b.getTypeName()) {
  throw new IllegalArgumentException("type mismatch: " + a.getTypeName() + " vs " + b.getTypeName());
}

Type guard

static boolean sameType(CEPLiteral a, Object b) {
  return b instanceof CEPLiteral
      && a.getTypeName().equals(((CEPLiteral) b).getTypeName());
}

Try / catch

try {
  int cmp = byteLiteral.compareTo(otherLit);
} catch (IllegalStateException e) {
  // handle type mismatch: convert other literal or skip comparison
}

Prevention

When it happens

Trigger: Calling compareTo/equals (or evalCondition during pattern matching) with two CEPLiteral objects whose getTypeName() differ, e.g. comparing a Byte literal against an Integer or VarChar literal; CEP condition code pairing a pattern parameter with a column value of a different SQL type.

Common situations: Event-pattern conditions comparing literal constants against fields whose inferred Calcite type differs (TINYINT vs INTEGER); tests building literals with mismatched factory methods; schema evolution changing a field's type so existing literals no longer match.

Understand the failure class

Background: Type mismatch errors: IllegalArgumentException, TypeError and type guards across 150 open-source libraries — this error's family across 150 libraries.

Related errors


AI-assisted analysis of apache/beam@12126d8942 (2026-09-13). Data as JSON: /api/errors/40672d1c79b671b7. Report an issue: GitHub.