Re: String-based Switch Request...

Dan wrote:
[] A string-based switch would have the following benefits for JAVA,

   1) Increase maintainability of code (especially GUI code)
   2) Facilitate good callback programming design and modularization
within GUI code

I think you'll find that it would do neither of those two things. If we had String based switches, why stop there? why not Enums, User defined types, etc.? Because ...

1) When ever switch statements are used, they are typically over used being favour over polymorphism, which leads to brittle shoddy design. Switch statements are best used in isolated cases (no pun intended) like Abstract Factories. These use the switch to decide which object to create, and then we can take advantage of polymorphism.

As for GUI code explicitly, Java actually moved away from Conditional logic to polymorphism because of these problems.

2) Switch statements have nothing to do with callbacks. Sure we CAN use them for that purpose, but then we can use any of the languages constructs for the same purpose (arrays, If/else, Collections, etc.).

[] A string-based switch would have the following drawbacks for JAVA,

   Umm,...actually there are none.  C, Fortran lovers can still do
their integer-based switch.  If overcoming inertia it's such a big
concern, why not just call it sswitch (string-switch) or wswitch
(word-switch) or something else.

Umm, actually loads, at best they would give another procedural programming construct to an OO language. At worst see above.

The best alternative I have used to date (although ugly)
is for a String S:

while (true) //String-based switch mimic...
    if (S.equalsIgnoreCase("run"))
        System.out.println("Do one thing");

    if (S.equalsIgnoreCase("jump"))
        System.out.println("Do another thing");


    System.out.println("Otherwise do something here.");


I take it your application has 'type codes' that are string based and this is why you are posting this 'idea'. If it does then one approach would be to use a HashMap. Use the string type-code as the Key and a Command or Strategy Object as the Value.

e.g using inheritance and polymorphism...

interface Command {
   void execute();

class abstract AbstractPrintlnCommand implements Command {
   public void execute() {
      String msg = getMessage();
      System.out.println("Do one thing");

   protected String getMessage();

class RunCommand extends AbstractPrintlnCommand {
   protected String getMessage() {
      return "Do one thing";

class JumpCommand extends AbstractPrintlnCommand { protected String getMessage() { return "Do another thing"; } }

class LetsUseOO {

   public LetsUseOO() {
       commands.put("Run", new RunCommand());
       commands.put("Jump", new JumpCommand());

   public void printMessage(String typeCode) {
      Command command = commands.get(typeCode);

   private Map commands = new HashMap();

Now that we have this simply pattern, we can populate the hashmap in numerous ways.

As above it could be hard coded - exactly like the switch is hardcoded.

Or better yet we could populate at runtime by using a config file which specified the typeCode and name of the Command implementing class, then with reflection to instantiate the command and populate the hashmap.

And many many more ways of changing the program dynamically - which is much more maintainable that hard coded switch statements. We could ship and deploy a system and then later on ship a new or modified Jar which just contains new Commands and these would be able to be used without us having to ship and deploy a whole new system.

Trying to use C constructs in Java is the problem - don't do it, it will make your job more difficult and the maintainers job a nightmare.