I am working on a legacy swing application that I have recently migrated to java 1.6 from 1.3. The application is simple client/server app with clients in tok but db server in london. My problem is, when client launches the app in ja_JP locale it formats the date vale to dd MM yyyy. Now this format is not recognized by database and hence throws an error. The same code works fine if the locale is set to en_GB as the date format is dd MMM yyyy.
I have debugged this and found that java6 uses extention jars(ext/localedata.jar) to get the default date format for each locale. So I tried to remove this jar and the app seems to be working fine.
However, I have a doubt if the removal will fail at some other place?Should I watch for any other possibility?
SCJP 5, SCDJWS<br /> <br />It's amazing how premature optimisation is both seductive and destructive; even when you know
To prevent the problem, you should not have to remove any locale data.
There are three quite simple, and definitely better, solutions:
Use Locale.setDefault to change the locale from your code.
Use the YYYY-MM-DD format for storing the date. The problem with a lot of systems is that XX-XX-YYYY can be recognized as both DD-MM-YYYY (European) and MM-DD-YYYY (American). For instance, 01-02-2008 is often not February 1st but January 2nd.
Unfortunately, the American way seems to be the default for a lot of database systems. Using YYYY-MM-DD removes that ambiguity.
So you're saying that changing something in code will take too long to test et all, but removing a JAR file from the base installation that could very well affect all code that uses locales (not only code you've written but also in the Java core libraries) is not a problem?
If I would do something like that at my job I would get yelled at, if not worse. Probably worse yes.
Still, technically you will have to go through the entire testing procedure again, since your setup has changed. I doubt your employer will be happy if this does break some code. Of course you can hope it doesn't but I myself wouldn't count on it.