bug found in GWT rename-refactoring

I have found an error in the behavior of the rename-refactoring in the context of a GWT application. I will submit a JIRA. It may be causing you anguish, so I describe it here.

I take a shared point of reference the the sample application provided under new>Google Web Toolkit>GWT sample application. Start a new project and load that. Call it MySampleApplication.

The short version is that if you refactor-rename the .java class named MySampleApplication which is created, you'll break the application. This is because the refactoring renames (without giving you an option not to) a certain line in interface:

public interface MySampleApplicationService extends RemoteService

more exactly, this line:
((ServiceDefTarget) app).setServiceEntryPoint(GWT.getModuleBaseURL() +

and even more exactly second occurrence of MySampleApplication in the line:


my rename looks like this:

So that's the bad behavior in a nutshell.

Now, here's the issue behind the behavior IMO. The trick of having unabashed Strings littered throughout config, xml and POJO files which have to mirror the names of , variously classes, packages and in this case, something I'm not sure what it is (owing to lack of recent experience with servlets no doubt- that second MySampleApplication)
is a Bad Idea that Rules The World.

It defeats compile-time checking and it defeats tools that automatically process your code in some way, as we see here.

Add to that the requirement that many entities have to have the same or similar names, and the ability to comprehend the mandatory associations which need to be maintained between that String and other entities goes towards zero.

the package named mySampleApplication
the mysterious (to me) something in the class path of the Servlet: MySampleApplication

and no less than 10 instances of the String "mySampleApplication" in some form scattered about in classes, config files and xml files .

Now, a programmer is faced with having to debug an application in which any of these Strings may be in a dependency relationship with any other entity. Programmers look to the code to try to understand what went wrong, but unless you already understand perfectly all the relationships, you can't deduce anything when things break.

Something gets a letter off or capitalized incorrectly in a String ... or a refactoring fails or the way a mapping is expressed changes in a new release...you see what happens.

Just something to think about for those inclined to do so.

Message was edited by:

Please sign in to leave a comment.