Proposal: Strings in Switch (original) (raw)

Joseph D. Darcy Joe.Darcy at Sun.COM
Fri Feb 27 15:20:11 PST 2009

To start the discussions, here is my proposal for allowing Strings in switch.

-Joe

PROJECT COIN SMALL LANGUAGE CHANGE PROPOSAL FORM v1.0

AUTHOR(S): Joseph D. Darcy

OVERVIEW Provide a two sentence or shorter description of these five aspects of the feature: FEATURE SUMMARY: Should be suitable as a summary in a language tutorial.

Add the ability to switch on string values analogous to the existing ability to switch on values of the primitive types.

MAJOR ADVANTAGE: What makes the proposal a favorable change?

More regular coding patterns can be used for operations selected on the basis of a set of constant string values; the meaning of the new construct should be obvious to Java developers.

MAJOR BENEFIT: Why is the platform better if the proposal is adopted?

Potentially better performance for string-based dispatch code.

MAJOR DISADVANTAGE: There is always a cost.

Some increased implementation and testing complexity for the compiler.

ALTERNATIVES: Can the benefits and advantages be had some way without a language change?

No; chained if-then-else tests for string equality are potentially expensive and introducing an enum for its switchable constants, one per string value of interest, would add another type to a program without good cause.

EXAMPLES Show us the code! SIMPLE EXAMPLE: Show the simplest possible program utilizing the new feature. String s = ... switch(s) { case "foo": processFoo(s); break; }

ADVANCED EXAMPLE: Show advanced usage(s) of the feature. String s = ... switch(s) { case "quux": processQuux(s); // fall-through

case "foo": case "bar": processFooOrBar(s); break;

case "baz": processBaz(s); // fall-through

default: processDefault(s); break; }

DETAILS SPECIFICATION: Describe how the proposal affects the grammar, type system, and meaning of expressions and statements in the Java Programming Language as well as any other known impacts.

The lexical grammar is unchanged. String is added to the set of types valid for a switch statement in JLSv3 section 14.11. Since Strings are already included in the definition of constant expressions, JLSv3 section 15.28, the SwitchLabel production does not need to be augmented. The existing restrictions in 14.11 on no duplicate labels, at most one default, no null labels, etc. all apply to Strings as well. The type system is unchanged. The definite assignment analysis of switch statement, JLSv3 section 16.2.9, is unchanged as well.

COMPILATION: How would the feature be compiled to class files?

One way to support this change would be to augment the JVM's lookupswitch instruction to operate on String values; however, that approach is not recommended or necessary. It would be possible to translate the switches to equivalent if-then-else code, but that would require unnecessary equality comparisons which are potentially expensive. Instead, a switch should occur on a predictable and fast integer (or long) function value computed from the string. The most natural choice for this function is String.hashCode, but other functions could also be used either alone or in conjunction with hashCode. (The specification of String.hashCode is assume to be stable at this point.)
If all the string labels have different lengths, String.length() could be used instead of hashCode. Generally a String.equals() check will be needed to verify the candidate string's identity in addition to the evaluation of the screening function because multiple string inputs could evaluate to the same result.

A single case label, a single case label with a default, and two case labels can be special-cased to just equality checks without function evaluations. If there are collisions in String.hashCode on the set of case labels in a switch block, a different function without collisions on that set of inputs should be used; for example ((long)s.hashCode<<32 ) + s.length()) is another candidate function.

Here are desugarings to currently legal Java source for the two examples above where the default hash code do not collide:

// Simple Example if (s.equals("foo")) { // cause NPE if s is null processFoo(s); }

// Advanced example { // new scope for synthetic variables boolean $take_default = false; boolean $fallthrough = false; $default_label: { switch(s.hashCode()) { // cause NPE if s is null case 3482567: // "quux".hashCode() if (!s.equals("quux")) { $take_default = true; break $default_label; } processQuux(s); $fallthrough = true; case 101574: // "foo".hashCode() if (!$fallthrough && !s.equals("foo")) { $take_default = true; break $default_label; } $fallthrough = true; case 97299: // "bar".hashCode() if (!$fallthrough && !s.equals("bar")) { $take_default = true; break $default_label; } processFooOrBar(s); break;

  case 97307: // "baz".hashCode()
      if (!s.equals("baz")) {
          $take_default = true;
          break $default_label;
      }
      processBaz(s);
      $fallthrough = true;

  default:
      $take_default = true;
      break $default_label;
  }

} if($take_default) processDefault(s); }

In the advanced example, the boolean "fallthrough" variable is needed to track whether a fall-through has occurred so the string equality checks can be skipped. If there are no fall-throughs, this variable can be removed. Likewise, if there is no default label in the original code, the $take_default variable is not needed and a simple "break" can be used instead.

In a translation directly to bytecode, the synthetic state variables can be replaced with goto's; expressing this in pseudo Java source with goto:

// Advanced example in pseudo Java with goto switch(s.hashCode()) { // cause NPE if s is null case 3482567: // "quux".hashCode() if (!s.equals("quux")) goto $default_label; goto $fooOrBarCode_label;

case 101574: // "foo".hashCode() if (!s.equals("foo")) goto $default_label; goto $fooOrBarCode_label;

case 97299: // "bar".hashCode() if (!s.equals("bar")) goto $default_label;

$fooOrBarCode_label:
processFooOrBar(s);
break;

case 97307: // "baz".hashCode() if (!s.equals("baz")) goto $default_label; processBaz(s);

default: $default_label: processDefault(s); break; }

Related to compilation, a compiler's existing diagnostics around falling through switches, such as java's -Xlint:fallthrough option and @SuppressWarnings("fallthrough"), should work identically on switch statements based on Strings.

TESTING: How can the feature be tested?

Generating various simple and complex uses of the new structure and verifying the proper execution paths occur; combinations to test include switch statements with and without fall-throughs, with and without collisions in the hash codes, and with and without default labels.

LIBRARY SUPPORT: Are any supporting libraries needed for the feature?

No.

REFLECTIVE APIS: Do any of the various and sundry reflection APIs need to be updated? This list of reflective APIs includes but is not limited to core reflection (java.lang.Class and java.lang.reflect.), javax.lang.model., the doclet API, and JPDA.

Only reflective APIs that model statements in the source language might be affected. None of core reflection, javax.lang.model.*, the doclet API, and JDPA model statements; therefore, they are unaffected. The tree API in javac, http://java.sun.com/javase/6/docs/jdk/api/javac/tree/index.html, does model statements, but the existing API for switch statements is general enough to model the revised language without any API changes.

OTHER CHANGES: Do any other parts of the platform need be updated too? Possibilities include but are not limited to JNI, serialization, and output of the javadoc tool.

No.

MIGRATION: Sketch how a code base could be converted, manually or automatically, to use the new feature.

Look for sequences of if ("constant string".equals(foo)) or if (foo.equals("constant string")) and replace accordingly.

COMPATIBILITY BREAKING CHANGES: Are any previously valid programs now invalid? If so, list one.

All existing programs remain valid.

EXISTING PROGRAMS: How do source and class files of earlier platform versions interact with the feature? Can any new overloadings occur? Can any new overriding occur?

The semantics of existing class files and legal source files and are unchanged by this feature.

REFERENCES EXISTING BUGS: Please include a list of any existing Sun bug ids related to this proposal.

5012262 Using Strings and Objects in Switch case statements. http://bugs.sun.com/view_bug.do?bug_id=5012262

URL FOR PROTOTYPE (optional):

No prototype at this time.

More information about the coin-dev mailing list