Internationalization Support in J2ME MIDP

By: Henry Emailed: 1768 times Printed: 2516 times    

Latest comments
By: rohit kumar - how this program is work
By: Kirti - Hi..thx for the hadoop in
By: Spijker - I have altered the code a
By: ali mohammed - why we use the java in ne
By: ali mohammed - why we use the java in ne
By: mizhelle - when I exported the data
By: raul - no output as well, i'm ge
By: Rajesh - thanx very much...
By: Suindu De - Suppose we are executing

Realistically, an i18n solution on any platform is somewhat constrained by the resources and API mechanisms available to applications. The ease with which a programmer can implement i18n support—and the comprehensiveness of that support—depends largely on the level of explicit support for the major areas of i18n development. The MIDP platform provides the following elements in support of i18n development:

• Calendar, Date, and TimeZone classes: java.util package
• system properties: microedition.encoding, microedition.locale
• conversion between character encoding sets: package
• user-defined MIDlet suite attributes: application descriptor file (JAD file)
• retrieval of resources (files) from the MIDlet suite JAR file:
Class.getResourceAsStream(String resourceName)

The MIDP java.util package contains three classes that are related to i18n, namely Calendar, Date, and TimeZone. These classes, however, are not themselves internationalized. That is, their concrete implementations don't support operations in multiple locales. For example, Calendar doesn't perform calculations according to a particular locale's calendar. The Date class doesn't do locale-sensitive date and time formatting. Neither do they present localized resources themselves. These classes do, however, present basic definitions that can be subclassed.

The Calendar and TimeZone classes are abstract. MIDP implementations must provide at least one concrete subclass for each of them. Although not internationalized, their implementations will be compatible with the locale supported by the MIDP implementation. For instance, in the United States, an implementation would most likely support a Gregorian calendar. The majority of MIDP implementations support only one locale. In fact, the MIDP specification only requires an implementation to support a single locale and only requires implementations to support the Greenwich Mean Time (GMT) time zone.

Note: The MIDP specification only requires that implementations support one locale. MIDP implementations currently don't define adequate support for internationalization and localization, which require too many resources.

Realistically, application developers who hope to deliver applications to multiple platforms must build support for locales other than the one supported by the manufacturer's implementation. To support true i18n and l10n, developers must build application level APIs that support multiple time zones, calendars, and so forth. Manufacturers may provide some of this support in the form of native APIs and Java libraries that sit on top of their MIDP implementation. Developers must be aware of the level of i18n and l10n support provided, if any, and they must plan their application design accordingly.

Support for a single time zone and a single calendar implementation might suffice in the majority of cases. Manufacturers may, however, provide additional calendar and time zone resources for an implementation. The motivation for this kind of additional support would be to support multilingual computing.

Device manufacturers typically support the locale associated with the device's target market. An implementation that supports only one locale need not be internationalized. Although this approach may work in the majority of markets for now, things could change. Single locale support does not support multilingual computing. Applications may need to do messaging in one locale, monetary formatting in another, and so forth.

Readers who are familiar with i18n support on the J2SE platform will notice that the MIDP has a comparatively distinct lack of comprehensive i18n support (see the J2SE java.text package). The reason, once again, is the constrained environment of mobile devices. The MIDP has no java.text package. In fact, MIDP has no API support for i18n features such as resource bundles, message formatting, number formatting, locale-sensitive date and time formatting, and so forth. The MIDP is also missing the new i18n features in version 1.4 of the JDK java.text package, such as collation, bidirectional text support, annotations, attributes, and so forth.

I18N Frameworks

Basically, the crux of all i18n designs is the mechanism that enables applications to retrieve the right version of localized resources at runtime. Unlike J2SE, the MIDP has no real API or classes that support general retrieval of localized resources. There's no ResourceBundle class or any of its subclasses. MIDP applications must create their own mechanisms for l10n resource definition and retrieval. Realistically, the most viable approaches are:

• Retrieve l10n resources from the JAD file.
• Retrieve l10n resources from a text file that's part of the application JAR file.
• Retrieve l10n resources from a Java class file, such as an application-defined, J2SE-style resource bundle mechanism.


Unfortunately, the MIDP also lacks explicit support for messaging. Unlike J2SE, the MIDP offers no messaging API, and there's no MessageFormat class. In designing a messaging solution for MIDP applications, designers should consider the following issues:

  • location of the localized data
  • mechanism for accessing the localized data
  • format of the localized data and character encoding set used
  • footprint of localized resources
  • runtime performance
  • localization process issues such as management of development resources, maintenance,
    and so forth
  • real wireless network environments, application provisioning environments, and
    deployment issues

String Collation

The MIDP has no support for string collation. If your applications need to perform lexicographic sorting of any kind, you'll have to design and implement your own mechanism to do it. Although this support exists in J2SE, the classes consume too many resources for a MIDP device environment at the present time.

Date, Time, and Numeric Formatting

The MIDP provides no support for formatting date, time, numeric, or monetary values. The MIDP has none of the J2SE platform classes that support this formatting; there are no DateFormat, NumberFormat, and DecimalFormat classes. Manufacturers may provide implementationspecific classes to support these formatting capabilities, however.

The MIDP defines Date and TimeZone classes in its java.util package, but these classes aren't really internationalized. That is, their interfaces don't define any capabilities that address locale-sensitive processing.

The Date class simply represents a specific instance of time in Coordinated Universal Time (UTC). There's no MIDP support for conversion of a Date quantity to represent a time value in any other time zone, or to format time values for display to users. This behavior is consistent with the J2SE platform's definition of Date objects. The J2SE platform, however, has related classes (such as DateFormat) that can format date quantities in a locale-sensitive manner. The MIDP has no such support classes.

The MIDP supports time zones with its java.util.TimeZone class. This class is abstract. Your MIDP implementation will provide at least one concrete subclass that represents the GMT time zone. The MIDP specification only requires support for the GMT time zone; however, your implementation might support others as well.

The TimeZone.getDefault() method returns a TimeZone object that represents the default time zone for the host on which your application is running. Be aware that it might define the GMT time zone, even if that's not the time zone in which your host application operates. The TimeZone.getTimeZone(String id) method returns a TimeZone object for the threeletter time zone argument specified in the call. Be forewarned that the object returned might not represent the time zone you requested because the implementation might not support it. Clearly, it's important that you, the application developer, be aware of which time zones your platform support. 

Calendar and Time Zone Support

Again, unlike the J2SE platform, the MIDP has only limited calendar support. The java.util.Calendar class is abstract. Therefore, every MIDP platform will provide at least one concrete implementation. Most likely, it won't be internationalized.

The platform's concrete Calendar subclass will most likely implement one particular calendar, such as a Gregorian or lunar calendar. This might or might not be an appropriate calendar for the locale contexts in which you deploy your applications. The Calendar.getInstance(TimeZone zone) method returns a Calendar object that uses the specified time zone and the platform's default locale. Note that this factory method doesn't make Calendar a fully internationalized class. It still doesn't return an appropriate calendar based on the locale context. For example, if you specify Chinese Standard Time, you won't get an object that represents a lunar calendar as used in China with all MIDP implementations. This means that you need to be aware of what calendar is supported

J2ME Home | All J2ME Tutorials | Latest J2ME Tutorials

Sponsored Links

If this tutorial doesn't answer your question, or you have a specific question, just ask an expert here. Post your question to get a direct answer.

Bookmark and Share


Be the first one to add a comment

Your name (required):

Your email(required, will not be shown to the public):

Your sites URL (optional):

Your comments:

More Tutorials by Henry
Generating Your Key Pair example using keytool in Java
Summary of Operators in Java
JDBC Basics and JDBC Components
The IterationTag Interface in JSP
Trigonometric, Hyperbolic, Exponential and Logarithmic Functions in C
Using Bit-field in C
Java Beans and the Expression Language
Initialization of Variables in C
Creating Struts Modules
else if statement in C
Line Counting sample program in C
Accessing Context Data in Beans using JSF
Using peek() and putback() with cin in C++
Internationalization Support in J2ME MIDP
java.lang.SecurityException: MIDP lifecycle does not support system exit.

More Tutorials in J2ME
Code sample to Send SMS from a J2ME application.
Adding your own Application icon for your J2ME application (jar file)
Play a multimedia file in J2ME Program (Audio/Video) using MMAPI
Datagrams in J2ME (UDP Programming sample)
Client Server in J2ME (Socket Programming sample)
Using HttpConnection in J2ME (Retrieve web content from a website to a phone)
Using HTTP vs UDP vs Socket in J2ME
RMSCookieConnector - Using Cookies in J2ME
POST UTF-8 encoded data to the server in J2ME
lists, forms, choices, gauges, text fields, text boxes in J2ME
Using List to create a Menu and Menu items in J2ME
Using alerts and tickers in J2ME
J2ME Canvas sample to show games programming in J2ME
Timer and TimerTask example in J2ME
List of GPRS Access points for all countries

More Latest News
Most Viewed Articles (in J2ME )
Gauge sample program in J2ME
The MIDP Networking Model in J2ME
Internationalization Support in J2ME MIDP
Types of Profiles in J2ME
What is J2ME?
What is J2ME?
Download a file over a network in J2ME midlet
How to load J2ME applications to the IDEN handsets
Y.S. Sun Green Building Research Center
'LINK.EXE' is not recognized as an internal or ext
Sample Java program shows how to Read a file over a network using J2ME midlet
Sample J2ME code that shows various functionality of RMS.
A sample J2ME midlet that shows an example of using a Timer and a TimerTask.
GUI components and menu based J2ME Applications.
Your first J2ME program and a midlet lifecycle explained.
Most Emailed Articles (in J2ME)
A sample J2ME midlet that shows an example of using a Timer and a TimerTask.
A sample J2ME Auto-resume program.
Timer and TimerTask example in J2ME
How to load J2ME applications to the IDEN handsets
paint() sample program to draw a line in J2ME
Sample program to draw text in J2ME
'double buffering' Sample program in J2ME
RMS Basics in J2ME
UDP Datagram sample in J2ME
Types of configurations in J2ME
Types of Profiles in J2ME
What is J2ME?
Download a file over a network in J2ME midlet
Y.S. Sun Green Building Research Center
'LINK.EXE' is not recognized as an internal or ext