“MIDlet not constructed by createMIDlet.” ?

This is a bit of a meta or recursive post in a way because it is prompted by my curiousity as to why the phrase

MIDlet not constructed by createMIDlet.

keeps turning up in the list of search terms used by people who have ended up here.

It is not really a generic term like some of the others which bring people here. For example

MIDP3

or

MIDlets on Android

or variations thereof.

It is pretty specific, and it is the same phrase everytime, but It is not one I’ve ever used here. So what does it match here and what is everyone looking for ?

Finding out what the search engines are matching here is easy enough. Type it in and see what they reference. The answer is this post

      What’s New In MIDP 3.0 ? Part 10: The MIDlet Lifecycle

which contains the terms “constructed”. “create”, and “MIDlet()”. Hence the match, but obviously not very useful given the actual search term.

Where does the search term itself originate ? Judging from some of the other search results it is an error message associated with a SecurityException thrown by Sun’s MIDP implementatation, so I’m guessing that people are seeing this exception and want to know what causes it.

The answer I suspect is that they are trying to create a MIDlet programatically and you are not allowed to do that as it says in the Throws clause of the documentation for the javax.microedition.midlet.MIDlet constructor

java.lang.SecurityException – unless the application management software is creating the MIDlet.

There are a good reasons for not allowing this. It would be very hard if not impossible to implement MIDP and ensure the correct lifecycle behaviour if MIDlets could be constructed programmatically.

Ironically it is actually pretty tricky to prevent it happening as well. As an implementor the only hook you have is the javax.microedition.midlet.MIDlet constructor which is in what is effectively a sealed package, but it can be done.

If you want to see exactly how Sun did it you can download their MIDP implementation as part of Phoneme Feature or Phoneme Advanced.

If you want to see how we (Symbian) did it, well unfortunately currently you can’t, which is a shame, because it was quite clever. Well at least I thought so, but then I would.

What’s New In MIDP 3.0 ? Part 38: Tied Operator MIDlets

At installation time a MIDlet Suite can be tied to a specific country and network using the

    MIDlet-Operator-Allowed

attribute.

The value must be a blank separated list of MCC/MNC pairs, where an MCC/MNC pair is a three digit MCC separated from a two or three digit MNC by a hyphen.

For example,

        234-15

Following a successful installation, MIDlets in the MIDlet Suite will not be excutable unless the current MCC and MNC correspond to one of the specified pairs.

This attribute only applies to MIDlet Suites bound to the Operator protection domain.

---

Copyright (c) 2009 By Simon Lewis. All Rights Reserved

What’s New In MIDP 3.0 ? Part 37: ScreenSaver MIDlets

The ScreenSaver MIDlet Model

• A ScreenSaver MIDlet is any MIDlet which has been declared with a type of screensaver at installation time.

• A ScreenSaver MIDlet may be selected by the user as the current screen saver.

• A ScreenSaver MIDlet is responsible for determining when it should be acting as the screen saver.

  • To do this it must determine

    1. whether it is the currently selected screen saver

    2. when the device enters and leaves screensaver mode

• A MIDlet can determine whether it is the currently selected screen saver by calling it’s isSelectedScreenSaver() method.

• A MIDlet can determine when the device enters and leaves screensaver mode by listening for EventData.SCREENSAVER_MODE events.

• A ScreenSaver MIDlet will be started automatically if it is is the currently selected screen saver and it is not running when the device enters screen saver mode.

Notes

1. It is not clear what behaviour is expected of a ScreenSaver MIDlet if it has access to multiple Displays.

2. Although there is apparently a potential race-condition if a ScreenSaver MIDlet is started automatically when the device enters screen saver mode, the semantics of the EventManager.addEventListener() methods should help avoid this. As the EventManager class documentation says

   For system events, as soon as a listener is added or an application is registered to be launched the current value is checked. If the current value is matched, the listener MUST be immediately notified or the application is launched.

   If the ScreenSaver MIDlet uses the EventManager.addEventListener(String, EventDataListener, boolean) variant of the method to register for the EventData.SCREENSAVER_MODE eventthen it will be notified of current state of the device’s screen saver mode

3. Listening for the EventData.SCREENSAVER_MODE requires an EventPermission for that event with an action of read. A MIDlet Suite containing a Screensaver MIDlet needs to ensure it requests that permission.

4. In the javax.microedition.midlet package documentation, when describing the sequence of events that the screen saver MIDlet MAY expect it says

   The MIDlet’s Display capabilities are changed to indicate no further user input events will be delivered to the screen saver MIDlet.

   It is not clear whether capabilities in this context means the values returned by the Display.getCapabilities() method. The reference to Display and the use of the word indicate seem to imply that it does, but if so then it contradicts the Display documentation where it says

   A given Display’s capabilities are static; that is, they do not change over time or in response to the state of the device.

   If not then this should be made clear.

---

Copyright (c) 2009 By Simon Lewis. All Rights Reserved

What’s New In MIDP 3.0 ? Part 36: IdleScreen MIDlets

The IdleScreen MIDlet Model

• An Idlescreen MIDlet is any MIDlet which has been declared with a type of idlescreen at installation time.

• A user may choose to add an Idlescreen MIDlet to the idle screen of a Display.

  • If the chosen MIDlet is not running when added then it will be started automatically.

• An Idlescreen MIDlet can access the idle screen of a Display using an IdleItem.

• An Idlescreen MIDlet which has been added to the idle screen of a Display but which does not access it using an IdleItem may be removed from the idle screen and terminated

• A MIDlet which is not declared to be an Idlescreen MIDlet cannot access the idle screen of any of its Displays

Notes

1. Should it have access to the idle screens of multiple Displays it is not clear how an Idlescreen MIDlet is supposed to determine which of them,
   if any, it is supposed to be responsible for displaying on.

2. The javax.microedition.lcdui documentation says

   If a MIDlet that has not announced itself as an idle screen MIDlet with the JAD or JAR Manifest attribute
   tries to add content to the idle screen, the system MUST ignore this request.

   Presumably this means that any calls to Display.setIdleItem(IdleItem) will simply have no effect.

---

Copyright (c) 2009 By Simon Lewis. All Rights Reserved.

What’s New In MIDP 3.0 ? Part 35: AutoStart MIDlets

An AutoStart MIDlet is any MIDlet which has been declared with a type of autostart at installation time.

An AutoStart MIDlet is started automatically at device start-up, and re-started automatically should it terminate, subject to resource limitations.

To declare a MIDlet as an AutoStart MIDlet the MIDlet Suite must have been granted the AutoStart permission. The default MIDP3 security policy does not permit MIDlet Suites bound to the Identified Third-Party protection domain or the Unidentified Third-Party protection domain to have this permission. By default therefore, only manufacturers and operators are going to be able to take advantage of the AutoStart MIDlet feature.

---

Copyright (c) 2009 By Simon Lewis. All Rights Reserved

What’s New In MIDP 3.0 ? Part 34: MIDlet Splash Screens

1. Specifying A Splash Screen

At installation time it is possible to specify an image to be used as a splash screen during the launch of any MIDlet in the MIDlet Suite.

This is done by using the

    MIDlet-Splash-Screen-Image

attribute to specify a comma separated list of file names. Each name should be the absolute path of a file within the MIDlet Suite JAR containing an Image.

At runtime the list is traversed in the order specified and the first image, if any, that is successfully loaded is used as the splash screen.

Alternatively the value of the attribute can be specified as

    suppress

in which case there will be no visual indication that the MIDlet is being started.

2. Splash Screen Behaviour

The splash screen image is displayed automatically on the primary Display when the MIDlet is started by the user, and is guaranteed to be visible to the user by the time the MIDlet’s startApp() method is called.

It then remains visible until the MIDlet’s startApp() method returns, or the MIDlet shows a Displayable on the primary Display if this occurs first, or if the MIDlet’s primary Display is no longer in the foreground state.

The amount of time for which the splash screen has been visible to the user can be determined by calling the MIDlet’s getSplashScreenTime() method.

---

Copyright (c) 2009 By Simon Lewis. All Rights Reserved

What’s New In MIDP 3.0 ? Part 18: LCDUI – Displays

1. The Display Model

• A device has one or more physical displays.

• Each physical display may support sharable and non-sharable functionality.

• The supported functionality may differ between physical displays.

• A Display gives a MIDlet access to a fixed set of the functionality of a corresponding physical display.

• A MIDlet will always have access to a primary display corresponding to the main physical display of the device.

• If a device has additional physical displays a MIDlet will have access to corresponding secondary Displays.

• If a physical display has two or more operating modes each with a discrete set of functionality a MIDlet will have access to those
  modes via two or more Displays.

2. Display Characteristics

2.1 Getting The Display’s Height

A Display’s height in pixels can be obtained by calling its

    public int getHeight()

method.

The value returned is the maximum height available for the display of a Displayable including its Title, Ticker, Commands and Menus, if present.

2.2 Getting The Display’s Width

A Display’s width in pixels can be obtained by calling its

    public int getWidth()

method.

The value returned is the maximum width available for the display of a Displayable including its Title, Ticker, Commands and Menus, if present.

2.3 Getting The Display’s Dot Pitch

A Display’s dot pitch can be obtained by calling its

    public int getDotPitch()

method.

The value returned is the distance between adjacent pixels in micrometers (1 x 10^-6m).

2.4 Does The Display Support Pointer Events ?

Whether or not a Display supports Pointer events can be determined by calling its

    public boolean hasPointerEvents()

method.

The method returns true if the Display is capable of reporting Pointer pressed and released events.

Notes

1. This method effectively supercedes the Canvas.hasPointerEvents() method. Whether Pointer events are supported by a Canvas is actually dependent upon the Display on which the Canvas is currently visible.
2. It is not clear why, other than for convenience, this functionality is not implemented using the capabilites mechanism.

2.5 Does The Display Support Pointer Motion Events ?

Whether or not a Display supports Pointer Motion events can be determined by calling its

    public boolean hasPointerMotionEvents()

method.

The method returns true if the Display is capable of reporting Pointer motion eventst.

Note

1. This method effectively supercedes the Canvas.hasPointerMotionEvents() method. Whether Pointer motion events are supported by a Canvas is actually dependent upon the Display on which the Canvas is
   currently visible.
2. It is not clear why, other than for convenience, this functionality is not implemented using the capabilites mechanism.

2.6 Is The Display Built-in ?

Whether or not the corresponding physical of a Display is built-in can be determined by calling its

    public boolean isBuiltIn()

method.

The method returns true if the corresponding physical display is built-in, that is, if it is an integral part of the device. If it is then the corresponding Display will never become unusable as the result of the removal of the corresponding physical display.

3. Display Capabilities

The functionality supported by a given Display is specified at runtime using capabilities, where a capability typically represents a discrete LCDUI feature.

The following capabilities are defined as constants in the Display class.

• SUPPORTS_ALERTS
• SUPPORTS_COMMANDS
• SUPPORTS_FILESELECTORS
• SUPPORTS_FORMS
• SUPPORTS_IDLEITEM
• SUPPORTS_INPUT_EVENTS
• SUPPORTS_LISTS
• SUPPORTS_MENUS
• SUPPORTS_ORIENTATION_LANDSCAPE
• SUPPORTS_ORIENTATION_LANDSCAPE180
• SUPPORTS_ORIENTATION_PORTRAIT
• SUPPORTS_ORIENTATION_PORTRAIT180
• SUPPORTS_TABBEDPANES
• SUPPORTS_TEXTBOXES
• SUPPORTS_TICKER
• SUPPORTS_TITLE

The constants are bit-flags and can be combined using bit-wise OR.

A MIDlet’s primary Display will support all LCDUI features but a secondary Display may not.

All Displays provides basic Canvas support.

The capabilities of a Display are fixed.

3.1 Getting A Display’s Capabilities

A Display’s capabilities can be obtained using its

 public int getCapabilities()

method.

The return value will either be the bit-wise OR’ed combination of the supported capabilities, or 0 indicating that the Display only provides basic Canvas support.

3.2 DisplayCapabilityException

A DisplayCapabilityException is thrown when an attempt is made to perform an operation which directly or indirectly involves a Display which does not support the functionality required for the operation. For example, passing an instance of Form to the setCurrent() method of a Display which does not support Forms.

4. Display State

A Display can be in one of three states

• Foreground,
• Background, or
• Visible

depending upon its current level of access to the functionality of the corresponding physical display.

4.1 Foreground

If a Display is in the Foreground state then it currently has exclusive access to all non-sharable functionality of the corresponding physical display, and first-call on any sharable functionality.

4.2 Background

If a Display is in the Background state then it currently has no access to the functionality of the corresponding physical display.

4.3 Visible

If a Display is in the Visible state then it has access to at least one pixel of the corresponding physical display, but it has no access to any of the non-sharable functionality.

4.4 Runtime Constants

The possible display states are represented by the following constants defined in the Display class

• STATE_BACKGROUND
• STATE_FOREGROUND
• STATE_VISIBLE

4.5 Getting The Current Display State

The current state of the Display can be obtained using the Display’s

    public int getDisplayState()

method which will return one of the constants listed above.

5. Hardware State

The hardware state of a Display is equivalent to the state of the corresponding physical display.
The physical display may be

• Enabled,
• Disabled, or
• Absent

The hardware state of a MIDlet’s primary display will never be Absent.

5.1 Enabled

If the hardware state of a Display is Enabled then the functionality of the corresponding physical display is available to the Display.

5.2 Disabled

If the hardware state of a Display is Disabled then the functionality of the corresponding physical display is not available to the Display.

5.3 Absent

If the hardware state of a Display is Absent then the corresponding physical display is no longer available and the Display itself is no longer usable.

5.4 Runtime Constants

The possible hardware states are represented by the following constants defined in the Display class

• DISPLAY_HARDWARE_ABSENT
• DISPLAY_HARDWARE_DISABLED
• DISPLAY_HARDWARE_ENABLED

5.5 Getting The Current Hardware State

The current hardware state of a given Display can be obtained used the Display’s

    public int getHardwareState()

method which will return one of the constants listed above.

6. Activity Mode

The activity mode of a Display may be either Normal or Active.

If a Display is in the Foreground state and its activity mode is Normal then the corresponding physical display may enter a reduced functionality power-saving state if the current power management policies of the device allow it.

If a Display is in the Foreground state and its activity mode is Active then the corresponding physical display should remain in a fully functional state.

If a Display in the Foreground state changes its activity mode from Normal to Active and the corresponding physical display is in a power-saving state it should return to a fully functional state.

The possible activity modes are represented by the following constants defined in the Display class.

• MODE_ACTIVE
• MODE_NORMAL

6.1 Getting The Current Activity Mode

The current activity mode of a Display can be obtained by calling it’s

    public int getActivityMode()

method which will return one of the runtime constants listed above.

6.2 Setting The Current Activity Mode

The current activity mode of a Display can be set by calling it’s

    public void setActivityMode(int mode)

method.

The mode argument must be one of the constants listed above.

7. Display Orientation

A Display may support more than one orientation.

Possible orientations are

Landscape	-	Display’s width is greater than its height
Landscape 180	-	Landscape with content rotated through 180 degrees
Portrait	-	Display’s height is greater than its width
Portrait 180	-	Portrait with content rotated through 180 degrees

The orientations supported by a Display can be determined by calling its getCapabilities() method.

7.1 Runtime Constants

The possible orientatations are represented by the following constants defined in the Display class

• ORIENTATION_LANDSCAPE
• ORIENTATION_LANDSCAPE180
• ORIENTATION_PORTRAIT
• ORIENTATION_PORTRAIT180

7.2 Getting The Orientation

The current orientation of the Display can be obtained by calling its

    public int getOrientation()

method which will return one of the constants listed above.

7.3 Setting The Preferred Orientation

The preferred orientation of a Display can be set using its

    public void setPreferredOrientation(int orientation)

method where orientation must be one of the constants listed above.

Note

It is not clear from the specification exactly what setPreferredOrientation() does. It states

This call may not have an effect on the actual orientation of the display if the specified orientation is not supported on the device.

It then goes on to say

The application may use getOrientation() to detect the actual orientation of the display after this call.

which would seem to imply that it is not guaranteed to do anything even if the specified orientation is supported by the Display.

More generally it is not clear what it means for a Display to support a given orientation. One possible interpretation is that if a Display supports more than one orientation, then, if the orientation of the Display changes it will automatically re-render all visible UI elements appropriately. This would seem to make sense as there is no API by which a MIDlet could achieve the same effect. Other aspects of the UI such as the size of the UI elements are potentially under the control of the MIDlet and are presumably, therefore, its responsibility.

8. Display Events

A MIDlet can listen for the addition of secondary Displays, and for changes in the

• display state
• hardware state
• orientation
• size

of individual Displays using an instance of the DisplayListener interface.

All Display events are serialized with respect to other LCDUI events.

Note

An orientation change may also result in a size change, but the specification does not explicitly state that the resulting events must occur in a particular order.

8.1 Adding A DisplayListener

A MIDlet can begin listening by using the Display method

    public static void addDisplayListener(DisplayListener l)

to add a DisplayListener.

8.2 Removing A DisplayListener

A MIDlet can stop listening using the Display method

    public static void removeDisplayListener(DisplayListener l)

to remove a DisplayListener added previously.

8.3 DisplayListener

Events are reported to a DisplayListener using event specific methods as follows.

8.3.1 Addition

The addition of secondary display is reported via the

    public void displayAdded(Display d)

method.

8.3.2 State Changes

Changes to the state of a Display are reported via the

    public void displayStateChanged(Display d, int newState)

method.

The newState argument will be one of the Display state runtime constants.

8.3.3 Hardware State Changes

Changes to the hardware state of a Display are reported via the

    public void hardwareStateChanged(Display d, int newState)

method.

The newState argument will be one of the Hardware state runtime constants.

8.3.4 Orientation Changes

Changes to the orientation of a Display are reported via the

     public void void orientationChanged(Display d, int newOrientation)

method.

The newOrientation argument will be one of the Orientation runtime constants.

8.3.5 Size Changes

Changes to the size of a Display are reported via the

    void sizeChanged(Display d, int w, int h)

method.

The arguments w and h are the new width and height of the Display respectively.

9. Getting Displays

9.1 Getting The Primary Display

The existing Display method

    public static Display getDisplay(MIDlet m)

will return the primary Display for the given MIDlet.

9.2 Getting Displays With Specific Capabilities

The new Display method

    public static Display[] getDisplays(int capabilities)

can be used to obtain a list of all the Displays currently available, or a list of those which support a specified set of capabilities.

If capabilities is 0 then a list available Displays will be returned, with the primary Display first.

If capabilities is a bit-wise ORed combination of the runtime constants representing capabilities, then the list of Displays supporting those capabilities will be returned, with the primary Display first.

Note

The method documentation states

Since the Primary Display must support all capabilities, it is always returned as the first element regardless of the capabilities requested.

For this to be true the Primary display must not only support all the LCDUI features, but all the possible orientations as well. It is not clear what supporting all possible orientations entails nor whether it is necessarily feasible on every device.

10. Transient Secondary Displays

The physical display corresponding to a secondary Display can become unavailable. In this case the hardware state of the secondary Display will change to Absent. Once this happens the secondary Display is no longer usable, and calls to methods such as setCurrent(Displayable) will throw an IllegalStateException.

If the physical display corresponding to the secondary Display becomes available again it
will be reported as a new Display via a call to the DisplayaListener.displayAddedd(Display) method.

12. Backwards Compatibility

Some existing methods now throw new exceptions. For example, Display.setCurrent(Displayable) can now throw a DisplayCapabiltyException or an IllegalStateException. However, as required to ensure binary compatibility, all new exceptions thrown are RuntimeExceptions. In addition these exceptions cannot occur when using the Primary display which is the only Display that a legacy MIDlet has access to,

---

Copyright (c) 2009 By Simon Lewis. All Rights Reserved.

What’s New In MIDP 3.0 ? Part 17: Preventing Users From Starting And Stopping MIDlets

A user can be prevented from starting and/or stopping a given MIDlet.

This can be done by using a

    MIDlet-<n>-UserDenied

attribute corresponding to the

    MIDlet-<n>

attribute used to declare the MIDlet itself.

It is an error if a MIDlet-<n>-UserDenied attribute is specified without a corresponding MIDlet-<n> attribute and installation will fail.

The value of the attribute must be a comma separated list of actions, where an action is one of

• run
• stop

If the run action is specified then a user will not be able to start the MIDlet using the device’s application launcher.

If the stop action is specified and a device supports application management level functionality for stopping applications then the user will not be able to use that functionality to stop the MIDlet. It does not affect the user’s ability to stop the MIDlet using functionality provided by the MIDlet itself via the UI, if any.

To specify a MIDlet-<n>-UserDenied attribute or attributes a MIDlet Suite must have been granted the ActionsDeniedPermission.

The specified MIDP 3 security policy does not make it possible for MIDlet Suites bound to either the Identified Third Party or the Unidentifed Third Party protection domains to be granted the ActionsDeniedPermission under any circumstances.

What’s New In MIDP 3.0 ? Part 16: Scalable MIDlet Icons

A scalable image in SVG Tiny format can be specified as the icon for a MIDlet.

This can be done at installation time by using a

    MIDlet-<n>-Scalable-Icon

attribute corresponding to the

    MIDlet-<n>

used to specify the MIDlet itself.

The value of the attribute should be the relative pathname of a file in the MIDlet Suite JAR containing the image.

The MIDlet-<n>-Scalable-Icon is a localizable attribute, so a locale specific scalable icon can be specified using a

	MIDlet-<n>-Scalable-Icon-<locale>

attribute.

Note

If icons are specified using both a MIDlet-<n>-Scalable-Icon attribute and the corresponding MIDlet-<n>, attribute, then whether the scalable icon should be used in preference to the non-scalable icon, or vice-versa, is unspecified, as is whether it is actually legal to specify both.

What’s New In MIDP 3.0 ? Part 15: Localized MIDlet Attributes

The MIDlet-<n> attribute is now a localizable attribute. It is possible for a MIDlet to have a locale specific name and icon, and also, apparently, class.

A locale specific variant of a given

    MIDlet-<n>

attribute can be specified using a corresponding

    MIDlet-<n>-<locale>

attribute.

The value of the attribute must be of the form

    [<name>] "," [<icon>] "," [<class>]

where, as for a MIDlet-<n> attribute, <name> is the name of the MIDlet, <icon> the icon with which to represent the MIDlet, and <class> the MIDlet class, and the same constraints apply.

The name, icon, and class that are used for the n‘th MIDlet are defined to be the values specified by the MIDlet-<n>-<locale> attribute whose <locale> matches the current locale. In each case if there is no locale specific version, then the value specified by the corresponding MIDlet-<n> attribute is used instead.

If there is no matching MIDlet-<n>-<locale> attribute then the values default to those specified by the MIDlet-<n> attribute.

Example

Assuming the following MIDlet-<n> and MIDlet-<n>-<locale> attributes are specified

    MIDlet-1:       SwatchMIDlet, SwatchMIDlet.png, example.midlet.SwatchMIDlet
    MIDlet-1-en-UK: ColourSwatchMIDlet
    MIDlet-1-en-US: ColorSwatchMIDlet, ColorSwatchMIDlet.png

then the possible values for the MIDlet name, icon and class are as follows

Locale	MIDlet Name	MIDlet Icon	MIDlet Class
en-UK	ColourSwatchMIDlet	SwatchMIDlet.png	example.midlet.SwatchMIDlet
en-US	ColorSwatchMIDlet	ColorSwatchMIDlet.png	example.midlet.SwatchMIDlet
Any other locale	SwatchMIDlet	SwatchMIDlet.png	example.midlet.SwatchMIDlet

Issues

On the basis of the documentation for the MIDlet-<n>-<locale> attribute it would appear that a MIDlet class can be locale specific.
It is certainly not explicitly forbidden. If this is true then it has implications for other supported features.

For example, push connections. The MIDlet-Push-<n> attribute specifies the class of the MIDlet to launch. The documentation states

The named MIDlet MUST be registered in the application descriptor or the JAR manifest with a MIDlet-<n> record.

The same constraint applies to the dynamic registration of alarms

The named MIDlet MUST be registered in the application descriptor or the JAR manifest with a MIDlet-<n> record. This parameter has the same semantics as the MIDletClassName in the Push registration attribute defined above in the class description.

using the PushRegistry.registerAlarm() method, and push connections

The named midlet MUST be registered in the application descriptor or the JAR manifest with a MIDlet-<n> record. This parameter has the same semantics as the MIDletClassName in the Push registration attribute defined in the class description.

using the PushRegistry.registerConnection() method.

The use of a MIDlet class to identify a MIDlet is not unique to alarm and push connection registration. Event Handler registration also requires the use of a class name.

For static registration the MIDlet-Event-Launch-<n> does not explicitly require that the class has been registered via a MIDlet-<n> attribute, which is in itself an issue, but dynamic registration does. Documentation for all variants of the EventHandler.registerApplication() method states

For MIDP, the named application class MUST be registered in the JAD or JAR Manifest for the MIDlet suite of the calling MIDlet with a MIDlet-<n> application attribute, and MUST extend javax.microedition.midlet.MIDlet.

Outside MIDP there is the Content Handler API (JSR211) which also uses class names for static and dynamic registration of content handlers as well as for generating Application IDs.

If a MIDlet class can be locale specific then the specification really needs to explain what the semantics of MIDlet classes now are and how the features mentioned above should work in this case.

If a MIDlet class cannot be locale specific then this needs to be made explicit.

There is one possible further complication. In discussing whether localized attributes should be
discarded at installation time the specification states

Usually one or more localized attribute versions end up being retained …

It is not clear why any localized attributes other than those matching the current locale actually
need to be retained. One possibility is that is is expected that if the current locale changes
subsequently then the appropriate localized attributes should be used. For most attributes this
is fairly innocuous, the MIDlet Suite description, for example, would simply be in language A
rather than language B. If MIDlet classes can be locale specific however things get very
complicated indeed: push connections, event handlers and content handlers could all end up
registered to the wrong MIDlet class. I assume that this is not what is intended.

---

Copyright (c) 2009 By Simon Lewis. All Rights Reserved.