java.util

Team-Fly

---

MIDP includes only a dozen classes from J2SE's java.util package. Many of the missing classes are part of the Collections API, which is too bulky for small devices. Table 4-3 lists the classes and interfaces of java.util in both J2SE and CLDC/MIDP.

Table 4-3: The java.util Package

INTERFACES
J2SE	MIDP
Collection	-
Comparator	-
Enumeration	Enumeration
EventListener	-
Iterator	-
List	-
ListIterator	-
Map	-
Map.Entry	-
Observer	-
Set	-
SortedMap	-
SortedSet	-

CLASSES
J2SE	MIDP
AbstractCollection	-
AbstractList	-
AbstractMap	-
AbstractSequentialList	-
AbstractSet	-
ArrayList	-
Arrays	-
BitSet	-
Enumeration	Enumeration
Collections	-
Date	Date
Dictionary	-
EventObject	-
GregorianCalendar	-
HashMap	-
HashSet	-
Hashtable	Hashtable
LinkedList	-
ListResourceBundle	-
Locale	-
Observable	-
Properties	-
PropertyPermission	-
PropertyResourceBundle	-
Random	Random
ResourceBundle	-
SimpleTimeZone	-
Stack	Stack
StringTokenizer	-
Timer	Timer
TimerTask	TimerTask
TimeZone	TimeZone
TreeMap	-
TreeSet	-
Vector	Vector
WeakHashMap	-

Collections

Although the full J2SE Collections API is not supported by MIDP, the old familiar Vector and Hashtable classes remain, as well as the lesser-known Stack. If you are familiar with the JDK 1.0 Vector and Hashtable classes, you should have no trouble with them in MIDP.

Timers

MIDP includes the Timer and TimerTask classes that were introduced into J2SE in the 1.3 version of the SDK. This is one of the few examples of J2SE classes that are not included in the CLDC but are included in MIDP.

Timer's API is identical to the J2SE version with one exception. The constructor that specifies whether the thread is a daemon is missing, as daemon threads are not supported in MIDP. The TimerTask API is exactly the same in J2SE SDK 1.3 and MIDP.

Telling Time

J2SE has an impressive array of classes that can be used for specifying dates and times and translating to and from human-readable representations of dates and times. The J2SE time classes have four distinct responsibilities:

• Points in time are represented by instances of java.util.Date. If you think of time as a line graph, then an instance of Date is just a point on the line.

• Calendars are used for representing points in time with calendar fields like year, month, and day. If you're using a Gregorian calendar, for example, then you can translate from a single point in time to a set of calendar values like month, day, and hours, minutes, and seconds. In J2SE, java.util.Calendar is a parent class for calendars, while the java.util.GregorianCalendar class represents the Gregorian calendar system that is familiar to most of the world.

• Formatting classes translate between points in time and human-readable strings. In J2SE, java.text.DateFormat is the parent for classes that can both generate and parse human-readable strings representing points in time. Formatting classes are very likely to make use of a calendar. For example, a typical DateFormat implementation might use a GregorianCalendar to translate a point in time to a set of calendar values, which it would then format in a string.

• Time zone classes represent the time zones of the world. The calendar and format classes use a time zone to create a localized representation of a particular point in time. In J2SE, java.util.TimeZone is the parent class of all time zones, with java.util.SimpleTimeZone as a concrete implementation.

Understanding these classes and their interactions is a little tricky, and it's complicated by the fact that it changed considerably between JDK 1.0 and JDK 1.1. The java.util.Date class used to have extra functionality in it; although the methods are deprecated, they're still present and may be confusing. Fortunately, you don't have to deal with this in the CLDC/MIDP world.

The situation is somewhat simpler in CLDC/MIDP. There are fewer classes, for one thing, and the Date class API has been cleaned up. In MIDP, the four responsibilities we just discussed are assigned to classes as follows:

• Points in time are represented by instances of java.util.Date, just like before. The Date class, in essence, is just a wrapper for a long value that indicates the number of milliseconds since midnight on January 1, 1970. (This is a standard way of representing time. It will work for about another 290 million years, so don't worry about another millennium bug.)

• Calendars are still represented by instances of java.util.Calendar. However, the GregorianCalendar class is no longer part of the public API. To get a Calendar instance, you can use the getInstance() factory method. Chances are you won't need to do this.

• Formatting classes are hidden from view in MIDP. One of the user interface classes, javax.microedition.lcdui.DateField, can convert a Date to a human-readable display, eliminating the need for you to mess around with date formatters yourself. DateField, essentially, is a graphic wrapper around a Date instance. It also allows the user to edit calendar and clock fields to produce a new Date value. See Chapter 6 for a full discussion of DateField.

• Time zones are still represented by instances of java.util.TimeZone. TimeZone_offers several static methods for examining the available time zones and getting an instance representing a particular time zone.

---

Team-Fly