localesdata.jar

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?

Please reply..Thanks

Rather reformat the date before you store it.

Do I understand you correctly that the DB is storing formatted data strings instead of java.sql.Date or am I missing something here?

Locale specific formatting is the View part and should not be mixed up with the actual data (model).

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.

Use a PreparedStatement and use its setDate or setTimestamp method.

reformatting the date and not to use locale dependent dateformat seems the ideal solution.
But the problem is that the code is in production and would need a long cycle of dev and fix.

setting a different locale doesn't work as I changes the japaneese string on the screen to english.

Maneesh is correct, the app makes dynamic query based on the input and executes on db so no java.sql.Date.

As a short term solution we have removed the localedata.jar from the ext folder. Java says that it is a optional api so I am hoping that it works

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.

I am hoping that it doesn't cause me my job

.
But the fact that it is a ext api libraries which are optional(as per sun)
http://java.sun.com/javase/6/docs/technotes/guides/extensions/

suggests me that the base installation is not dependent on the packages in jre/lib/ext dir.

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.