This method was added as part of an ill-considered internationalization effort in JDK 1.1. It's probably the wrong approach to internationalizing exceptions. The right localization information isn't available at the point the exception is thrown, nor at the point where this message is generated (see JDK-4125164).

Instead of localizing messages from the actual exception, the handler of the exception (which is much more likely to be closer to the user) should analyze the exception's type and exception-specific data and construct a reasonable message from that information.

Throwable::toString was changed to use getLocalizedMessage by JDK-4059406 in JDK 1.2. The specification of Throwable::toString wasn't updated to reflect this until JDK-4642378 was fixed in JDK 6.

In JDK-4298805 (which was closed as Won't Fix, because of incompatibility) the submitter complained that toString() using getLocalizedMessage() is incorrect, because:

"A stack trace is not something you would generally show directly to a user.
More than likely, the application would display a localized error message to
the user while the stack trace would get written to an exception log of some
sort. At least that's how we are doing things. Therefore, the
printStackTrace method should use the getMessage() method so it is in the
same language as the trace. The stack trace would be used by a support
organization to help track down problems for resolution be development.
Application users have no need for, nor would they want the stack trace,
therefore there is no need to localize a piece of it."

That comports with our current view that the exception data itself shouldn't be localized.

Recommended actions:

* Throwable::toString should be changed back to use getMessage(), and its spec should be updated correspondingly. The other exception-printing facilities (such as printStackTrace) run through toString so this should cover everything.

* Calls to and overrides of getLocalizedMessage() should be removed from the JDK.

* The getLocalizedMessage() method should be deprecated. It's unclear whether it should be terminally deprecated and subsequently removed. A corpus search should be done to determine whether its use is widespread. If removing it would be too disruptive, its specification should be updated to explain that doing anything other than returning the result of getMessage() is not useful.