This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
When you define a class called String you're not overriding anything, you've just happened to give your class the same name as a class in another package, namely java.lang.String.
Now *is it a good idea* to do this? Most programmers have such universal classes hardwired into their brains: String == java.lang.String, so I'd suggest calling your class something else, like MyString...
This reminds me of the time I was trying to help a student of mine who had a mysterious error in his cloning code -- the interface Cloneable just didn't seem to be working right. Then I discovered he had inadvertantly (?) define his own interface Cloneable!
Also note, by the way, that you can't subclass java.lang.String, not matter what you call the subclass -- String is final. [ December 15, 2005: Message edited by: Jeff Albrechtsen ]
and then make sure that java/lang/String.class was in "c:/mydir".
The longer answer is that if you're writing a special tool -- a debugger, or profiler, or something else that has to do weird things -- then this might be called for. Or if you're doing this temporarily while hacking on a program to instrument something to help you understand what's going on, then that's fine: I've done that kind of thing myself.
But in normal programming, it's terrible style; and of course in many environments you won't even be able to do it, because you won't have access to the boot classpath.