spring-projects/spring-security · error · IllegalStateException

invalid item:

Error message

invalid item: 

What it means

ComparableVersion's IntItem.compareTo throws IllegalStateException('invalid item: ' + item.getClass()) when an integer version item is compared against an item type it cannot handle (LONG_ITEM or BIGINTEGER_ITEM per this branch). ComparableVersion parses version strings into typed items; the switch must cover every item type, and this default arm signals a comparator/parsing invariant break. In practice it means version items of mixed types reached a comparison path that was not designed for them.

Source

Thrown at core/src/main/java/org/springframework/security/core/ComparableVersion.java:141

		}

		@Override
		public boolean isNull() {
			return value == 0;
		}

		@Override
		public int compareTo(@Nullable Item item) {
			if (item == null) {
				return (value == 0) ? 0 : 1; // 1.0 == 1, 1.1 > 1
			}

			return switch (item.getType()) {
				case INT_ITEM -> Integer.compare(value, ((IntItem) item).value);
				case LONG_ITEM, BIGINTEGER_ITEM -> -1;
				case STRING_ITEM -> 1; // 1.1 > 1-sp
				case LIST_ITEM -> 1; // 1.1 > 1-1
				default -> throw new IllegalStateException("invalid item: " + item.getClass());
			};
		}

		@Override
		public boolean equals(@Nullable Object o) {
			if (this == o) {
				return true;
			}
			if (o == null || getClass() != o.getClass()) {
				return false;
			}

			IntItem intItem = (IntItem) o;

			return value == intItem.value;

		}

View on GitHub (pinned to 96852e8860)

Solutions

  1. Normalize version strings before comparison so numeric items stay in the same type class (e.g. compare '1' and '1.0' consistently, avoid gigantic numeric segments)
  2. Upgrade to a Spring Security version with the fixed/complete ComparableVersion switch handling mixed INT/LONG/BIGINTEGER comparisons
  3. Catch IllegalStateException around version comparison and fall back to string comparison for exotic inputs
  4. If you feed ComparableVersion programmatically, only construct it from well-formed version strings (digits, dots, hyphenated qualifiers)

Example fix

// before
boolean ok = new ComparableVersion("1").compareTo(new ComparableVersion("9999999999999999999999")) < 0; // IntItem vs BigIntegerItem
// after
boolean ok = new ComparableVersion("1.0.0").compareTo(new ComparableVersion("2147483648.0.0")) < 0; // keep segments within int range
Defensive patterns

Strategy: fallback

Validate before calling

if (!version.matches("^[0-9A-Za-z][0-9A-Za-z.\-]*$") || version.matches(".*\\d{15,}.*")) { throw new IllegalArgumentException("unsupported version format: " + version); }

Try / catch

int cmp; try { cmp = new ComparableVersion(a).compareTo(new ComparableVersion(b)); } catch (IllegalStateException e) { cmp = a.compareTo(b); }

Prevention

When it happens

Trigger: Comparing two version strings whose parsed item types disagree in a way this branch does not handle (e.g. '1' vs '9007199254740993' where the second parses as a long/bigint item); passing a hand-built or foreign ComparableVersion item into the comparison; a modified/patched ComparableVersion with an incomplete switch.

Common situations: Dependency-management code (this class originates from Maven) comparing unusual version strings with extremely large numeric segments; frameworks embedding ComparableVersion for feature/version gating receiving unexpected formats.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors


AI-assisted analysis of spring-projects/spring-security@96852e8860 (2026-09-10). Data as JSON: /api/errors/4349575fb4206bc6. Report an issue: GitHub.