*
The moose likes Java in General and the fly likes localesdata.jar Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "localesdata.jar" Watch "localesdata.jar" New topic
Author

localesdata.jar

Swapnil Shroff
Ranch Hand

Joined: Mar 07, 2006
Posts: 58
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


SCJP 5, SCDJWS<br /> <br />It's amazing how premature optimisation is both seductive and destructive; even when you know
Taariq San
Ranch Hand

Joined: Nov 20, 2007
Posts: 192
Rather reformat the date before you store it.
Maneesh Godbole
Saloon Keeper

Joined: Jul 26, 2007
Posts: 10167
    
    8

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).


[How to ask questions] [Donate a pint, save a life!] [Onff-turn it on!]
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19651
    
  18

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.


  • SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
    How To Ask Questions How To Answer Questions
    Swapnil Shroff
    Ranch Hand

    Joined: Mar 07, 2006
    Posts: 58
    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
    Rob Spoor
    Sheriff

    Joined: Oct 27, 2005
    Posts: 19651
        
      18

    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.
    Swapnil Shroff
    Ranch Hand

    Joined: Mar 07, 2006
    Posts: 58
    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.
    Rob Spoor
    Sheriff

    Joined: Oct 27, 2005
    Posts: 19651
        
      18

    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.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: localesdata.jar
     
    Similar Threads
    Sun classes.
    internationalization - date format
    Problem using Calendar class
    java.text.ParseException: Unparseable date
    How to determine Data Format while we are getting Data from Excel Sheet