Member Avatar for trishtren

Iv been developing a parser using java, however due to testing on multiple machines i have errors now on one machine i corrected as the machine was using jdk/jre v1.6, and on my newer machine jdk/jre 1.7

The question i have is, what are the implications of using the String in a case statement in v1.7 vs the use of a series of if conditions that i implemented in java 1.6?

Will a String casestatement as a finite state machine perform any better or worse than lets say an optimal series of if conditions?

Is there any benefit to one over the other when it comes to string comparison?

Example :

If(testString.equals("test"))
{
return true;
}


Switch(testString)
{
case "Test": return true;
default : break;
}

Should i use the if conditons only for backwards compatibility in java versions?
What is the best structure to use for large string based state machines?

Any advice on any of those points will be appreciated :)

  • 2 Contributors
  • 1 Reply
  • 314 Views
  • 3 Hours Discussion Span
  • Latest Post Latest Post by delta_frost

Dani AI

Generated

Short answer: String switches were added in Java 7 and are fine to use there; they don’t change program semantics, only how the compiler implements the dispatch. As noted, there’s a hash computation cost involved — that’s true, but it’s only part of the picture and usually not a reason to avoid switch on String by itself.

Under the hood the compiler typically uses the expression’s hashCode to narrow candidates and then calls equals to resolve collisions. That means one hashCode() + a small number of equals() checks instead of potentially many equals() calls in a long if/else chain. In standard OpenJDK/String implementations the computed hash is cached, so repeated switches on the same String won’t recompute the full hash each time. For very small numbers of cases an if/else chain can be slightly faster; for many cases a switch (or a lookup) is usually better — but the only reliable way to know is to measure with your real inputs.

If you need backward compatibility with Java 6, or you want a cleaner design for a large state machine, prefer one of these patterns:

  • Map<String,Handler> — O(1) lookup, easy to extend and test.
  • Enum for states: map the incoming token once to an enum and then switch on that enum (fast and readable).
  • Trie/automaton for prefix-based parsing or thousands of states.

Example (enum approach):

enum State { START, TEST, END, UNKNOWN }

static State toState(String s) {
    if (s == null) return State.UNKNOWN;
    try { return State.valueOf(s.toUpperCase(Locale.ROOT)); }
    catch (IllegalArgumentException ex) { return State.UNKNOWN; }
}

Practical notes: normalize input (trim/case) if matching should be case-insensitive, avoid premature optimization, and benchmark (a profiler or microbenchmarks like JMH) if the dispatch is on a hot path. For a parser, maintainability (enums/maps) usually beats micro-optimizing string comparisons.

Member Avatar for delta_frost

I hate to post a link to a different page but the explanation there seems clear.
Click Here

Summarizing it,the if-else_if-else statements will perform better in general cases because of the hash computation of the string that takes place when using switch statement with a String.To view the fully explained answer,click on the link provided.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.