What’s New In MIDP 3.0: Redux – &rest

And that is it. Those are the only substantive changes that have been made since the proposed final draft that I have managed to find.

I did consider producing a post detailing the changes corresponding to each of my original posts but that would simply result in a string of posts saying

Changes Since Proposed Final Draft

None

Issues

As before

and I am not feeling sufficiently Samuel Beckett like for that kind of thing at the moment.

All the other issues I have raised are apparently not really issues after all, or they are still there. I guess we’ll just have to wait and see.

---

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

What’s New In MIDP 3.0: Redux – Security For MIDP Applications

Changes Since Proposed Final Draft

The Security For MIDP Applications chapter, now only available as chapter six of the PDF version of the documentation, has acquired an entirely new section entitled Combined usage of MIDP 2.0 and MIDP 3.0 security models

This states that a MIDP 3.0 MIDlet Suite can use both the new

• MIDlet-Permission-<n>, and
• MIDlet-Permission-Opt-<n>

attributes, and the legacy MIDP 2.0

• MIDlet-Permissions, and
• MIDlet-Permissions-Opt

attributes.

Similarly a LIBlet can use the use

• LIBlet-Permission-<n>, and
• LIBlet-Permission-Opt-<n>

attributes, and the newly defined

• LIBlet-Permissions
• LIBlet-Permissions-Opt

attributes.

This addition is presumably motivated by the fact that currently the vast majority of auxiliary MIDP compliant JME JSRs have not been updated to define fine-grained permissions for use with MIDP 3.0.

Issues

Underspecification

The new section says nothing more than that the attributes can all be used together. As such the feature is a tad underspecified. There are a number of possible use cases which need to be addressed. For example

1. Can a MIDP 3.0 MIDlet Suite use only the legacy attributes ?

2. Can a MIDP 3.0 MIDlet Suite use named permissions to request fine-grained permissions ?

Runtime Named Permission Checking

Although a MIDP 3.0 MIDlet Suite can now request named permissions, as the specification stands, at runtime, a MIDlet contained in such a MIDlet Suite has no way of checking the named permissions since it cannot use the deprecated MIDlet.checkPermission(String) method. The specification still
states that

For MIDP 3.0 applications, calling checkPermission throws an exception.

Legacy MIDlet Suites Can Use Either Pair Of Attributes But Not Both

The section entitled Security for MIDP 2.x MIDlet Suites, which is now only available as Section 9.2.2 of the PDF version of the documentation has not been changed.

It still states that

• If there exists one or more instances of the MIDlet-Permission-<n> or MIDlet-Permission-Opt-<n> attribute in the JAD or JAR Manifest, then the Permission classes associated with these attribute values MUST be used, and any instances of MIDlet-Permissions or MIDlet-Permissions-Opt MUST be ignored.

• If there exists no instances of MIDlet-Permission-<n> or MIDlet-Permission-Opt-<n> attribute in JAD or JAR Manifest, then the following MIDP 2.0 specific attributes MUST be processed when they appear in the JAD or JAR Manifest :

  • MIDlet-Permissions — attribute contains a list of one or more permissions. Multiple permissions are separated by a comma (Unicode U+002C). Leading and trailing whitespace (Unicode U+0020) and tabs (Unicode U+0009) are ignored. The permissions are critical to the function of the MIDlet suite and it will not operate correctly without them.
  • MIDlet-Permissions-Opt — attribute contains a list of one or more permissions. Multiple permissions are separated by a comma (Unicode U+002C). Leading and trailing whitespace (Unicode U+0020) and tabs (Unicode U+0009) are ignored. The permissions are not critical to the function of the MIDlet suite and it will operate correctly without them.

The motivation for defining this functionality was never entirely obvious. As it stands a MIDP 2.x MIDlet Suite can continue to use named permissions in which case it can also use any MIDP compliant auxiliary JME JSR, or use fine-grained permissions in which case it can only use those MIDP compliant auxiliary JME JSRs which have defined fine-grained permissions. Currently, it is diffcult to see why any developer would make the second choice

Given that an implementation now has to support a hybrid fine-grained/named permission model for MIDP 3.0 MIDlet Suites it is unclear why it cannot support it for MIDP 2.x MIDlet Suites as well. Either that or not allow them to use the MIDP 3.0 permissions in the first place.

---

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

What’s New In MIDP 3.0: Redux – LCDUI – Notification

Original Post

Changes Since Proposed Final Draft

Removing the NotificationListener via the Notification.setListener(NotificationListener) method no longer removes the Notification as well.

This eliminates the inconsistency between its behaviour and the documentation describing the Notification life-cycle which I noted in the original post.

Issues

The other minor issues noted in my original post still exist.

---

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

What’s New In MIDP 3.0: Redux – LCDUI – Fonts

Original Post

Changes Since Proposed Final Draft

Font.FONT_IDLE_TEXT and Font.FONT_IDLE_HIGHLIGHTED_TEXT

Links fixed to point at the right versions of the static getFont method, i.e.,

    Font.getFont(int)

Font.createFont(InputStream)

Scope of the Font created is now limited to the MIDlet that created it.

Implementations MUST insure that the availability and use of fonts created using createFont method is limited to the execution environment of a [sic] MIDlet that instantiated the font.

Changed from MIDlet Suite.

Font.getFont(String,int,int), Font.getFont(int,int,int) AndFont.deriveFont(int,int)

Documentation for all three methods has been updated to explicitly specify that the constant STYLE_UNDERLINED is supported in their respective style arguments.

The specification of the static method Font.getStyle(String) however, has not been updated to match. Possibly it does not need to be. Who knows ?

Font.hashCode()

Font now has a hashCode, which of course it should since it over-rides the equals method.

Unfortunately how the hash code should be computed is apparently a secret, since all the specification says is

the hashcode is computed from the font face name, style, pixelSize, ascent and descent

Issues

None apart from the secret hash code algorithm and that only affects implementors.

---

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

What’s New In MIDP 3.0: Redux – LCDUI – Command Layout

Original Post

Changes Since Proposed Final Draft

javax.microedition.lcdui.Display

The following has been added to the end of the Exact Placement of Commands section
of the Display class documentation.

On each callback of CommandLayoutPolicy.onCommandLayout(Displayable), implementation MUST first disassociate Command and Menu
with their respective previous placements. At the beginning of each callback of CommandLayoutPolicy.onCommandLayout(Displayable) method,
Displayable.getCommand(int) or Displayable.getMenu(int) will return null for every placement.

As I said in my original post

1. The specification does not contain an explicit definition of the state of a Display’s placements when the onLayout(Displayable)[sic] method is called, that is, whether Commands and/or Menus previously placed on the current Display by the Displayable are still present or whether all Commands and/or Menus must be explicitly placed each time the method is called. This makes implementing the method perhaps more interesting than it ought to be.

Well now it does. Every time you layout a Displayable’s Commands you start with a clean slate.

javax.microedition.lcdui.Displayable

The setCommand(Command,int) method no longer throws an IllegalArgumentException when the placement

is associated with a placement that does not support commands

possibly because it is actually not possible for a placement not to support Commands.

It is hard to be sure because the Item.setCommand(Command,int) method will apparently still throw an IllegalArgumentException when the placement

is associated with a placement that does not support commands

The CommandLayoutPolicy Example

The CommandLayoutPolicy now looks like this. Actually it doesn’t because I have re-formatted it. In Chrome, Firefox and Safari the formatting is all over the place, as it is in the PDF version.

class MyCanvas extends Canvas implements CommandLayoutPolicy {
    MyCanvas() {
        setCommandLayoutPolicy(this);
    }

    void sort(Command[] commands, int[] positions) {
        // sort the commands in the correct order depending on the positions available.
        // Implementation can use Display's getCommandPreferredPlacements to get the recommended 
        // placement for each Command.
    }
 
    public void onCommandLayout(Displayable displayable) {
        Display display = displayable.getCurrentDisplay();
      
        final int border = Display.SOFTKEY_BOTTOM;
     
        int[] positions = display.getExactPlacementPositions(border);
     
        int numOfPositions = positions.length;
           
        Command[] cmd = displayable.getCommands();
     
        sort(cmd, positions);
     
        if (cmd.length <= numOfPositions) {
            for (int i = 0; i < cmd.length; ++i) {
                displayable.setCommand(cmd[i], positions[i]);
            }
        } else {
            for (int i = 0; i < numOfPositions ; ++i) {
                displayable.setCommand(cmd[i], positions[i]);
            }
       
            int[] menuSupportedPlmts = display.getMenuSupportedPlacements();
            if( menuSupportedPlmts != null ) {
                Menu options = new Menu("More", null, null);
                // first add the remaining commands in the Menu
                for (int i = numOfPositions; i < cmd.length; ++i) {
                    options.append(cmd[i]);
                }
                // Get the first preferred placement of Menu
                int menuPlmt = menuSupportedPlmts[0];
                // check if this placement already occupied by Command
                if( displayable.getCommand(menuPlmt) != null ) {
                    //add the existing Command in Menu, otherwise the existing
                    // Command will be removed from the Displayable according to
                    //setMenu() method
                    //
                    options.append(displayable.getCommand(menuPlmt));
                }
                displayable.setMenu(options, menuPlmt);                    
            }
        }    
    }
 }

This is an improvement on the previous version which was flat-out broken. Note that it still doesn’t check the return value of the call to Display.getExactPlacementPositions(int).

Issues

The changes above are the only ones that I have found. Of the original issues I raised they address two if you are being charitable.

1. What is the state of the Displayable with respect to Command layout when the CommandLayoutPolicy.onCommandLayout(Displayable) method is invoked ? It is a clean slate

2. Can there be placements which do not support Commands ? Probably not.

Everything else is still up for grabs. Developers, assuming there are going to be any, are going to have to try it and see what happens, and then hope it happens the same way everywhere, which is the past has not been a guaranteed recipe for success.

Possibly if somebody had attempted to write a real-world example for the specification the Command layout feature itself would have been better specified. The example provided effectively does no more than provide the existing default behaviour.

---

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

What’s New In MIDP 3.0: Redux – LCDUI – Menus

Original Post

Changes Since Proposed Final Draft

The semantics of the depth returned by the method Menu.getMenuDepth() have been changed.

The method now

Returns this menu’s depth within its menu tree. The top menu is of depth 0, the menus attached to it are of depth 1, 2, etc. The top menu is the menu in the menu tree that has no parent menu . If a menu is attached to both a Displayable and another menu, its depth is calculated based on the menu to which it is attached. For instance, a menu A is a sub-menu of menu B and is also attached to a Displayable. If menu B is of depth 3, then menu A will return a depth of 4.

Previously, as I observed in my original post, the specification was both contradictory, and seemed to imply, amongst other things, that a Menu could effectively have two depths.

Issues

Although it is not a particularly serious issue, despite the changes, it is not exactly clear what having the ability to obtain the depth of a given Menu is actually for.

The depth of a Menu is only significant in the context of the maximum limit on Menu depth.

If you know that a Menu is at the maximum permitted depth then it is true that you know that you definitely cannot add a sub-Menu to it.

If you know that a Menu is not at the maximum permitted depth however, you do not know that you can add a given Menu as a sub-Menu with out knowing whether the Menu you wish to attach itself has any sub-Menus, and if so what the maximum depth of the sub-Menu tree, and you are going to have to compute that.

As I say it is not serious but some use-cases might have helped.

This is also true of the eternally enigmatic Menu.onParentEnabled(true). What is it for ?

---

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

What’s New In MIDP 3.0: Redux – Appendix A: Application Attributes

Technically this is not a case of redux as I have not written about it here before although I did comment upon it in the public review.

In the proposed final draft Appendix A – Application Attributes looked, in part, this is not all of it, like this. This is actually the start of the HTML version.

Application Attributes

This appendix specifies all Application Attributes and the allowed locations for each attribute (JAD, Manifest, or both), along with information about the specification version.

In Table A-1 below, <locale> represents a valid value of the microedition.locale system property.

Status :
● = MUST appear
❍ = MAY appear
in manifest and/or JAD file as indicated in the respective columns.

Manifest and JAD :
● = to be placed in this location
– = not allowed in this location.

Table A-1 : Application Descriptor Attributes
Attribute Name	Status	Manifest	JAD	Since
MIDlet-Name	●	●	●	1.0
MIDlet-Version	●	●	●	1.0
MIDlet-Vendor	●	●	●	1.0
MIDlet-<n>	●	●	●	1.0
MicroEdition-Profile	●	●	●	1.0
MicroEdition-Configuration	●	●	●	1.0
LIBlet-Name	●	●	●	3.0
LIBlet-Version	●	●	●	3.0
LIBlet-Vendor	●	●	●	3.0
MIDlet-Jar-URL	●	–	●	1.0
MIDlet-Jar-Size	●	–	●	1.0

Changes Since Proposed Final Draft

Appendix A now only appears in the PDF version of the documentation, and it looks like this. The only visible difference in this part being a minor difference in the wording in the key, but in fact a number of attributes that were marked as not being allowed in the JAD in the proposed final draft are now allowed there. I have no idea what the motivation for this change was.

Although this is not the major issue here it is also worth noting that a number of the sections which previously appeared as both HTML and in the PDF in the proposed final draft, are now present only in the PDF, with the result that the remaining HTML documentation now features a number of broken links. See the javax.microedition.midlet package documentation for a particularly fine selection.

Issues

As I argued in my comments in the public review, the table in the form it was then, and still is, is remarkably unhelpful.

Take the

    MIDlet-Name

attribute as an example.

Looking at the table, the solid bullet in the Status column indicates that the attribute

    MUST appear

and the solid bullets in the Manifest and JAD columns indicate that the attribute

    can be placed in this location

As we know from MIDP 2.0 and from the current specification, the MIDlet-Name attribute is in fact

1. mandatory, and

2. MUST appear in both the JAD AND the Manifest

That is it mandatory is apparent from the table. That it MUST appear in both the JAD and the Manifest simply is not.

Now consider the

    MicroEdition-Configuration 

attribute.

From MIDP 2.0 and the current specification we know that the attribute is

1. mandatory, and

2. MUST appear in either the JAD OR the Manifest, and MAY appear in both

but the entry for it in the table is identical to that of the MIDlet-Name attribute.

In short the table cannot be used for anything very much in the absence of the text which describes the constraints on the individual attributes which the table does not link to.

I put forward versions of the following as being a possible alternative approach. These have been updated to reflect the current status of the various attributes as I currently understand them.

Although the tables are a bit verbose in this form they can at least be used standalone.

MIDlet Suite Attributes

Name	Status	Location	Since
MIDlet-Name	Mandatory	JAD AND Manifest	1.0
MIDlet-Vendor	Mandatory	JAD AND Manifest	1.0
MIDlet-Version	Mandatory	JAD AND Manifest	1.0
MIDlet-<n>	Mandatory	JAD OR Manifest OR Both	1.0
MicroEdition-Configuration	Mandatory	JAD OR Manifest OR Both	1.0
MicroEdition-Profile	Mandatory	JAD OR Manifest OR Both	1.0
MIDlet-Jar-URL	Mandatory	JAD ONLY	1.0
MIDlet-Jar-Size	Mandatory	JAD ONLY	1.0
MIDlet-Name-<locale>	Optional	JAD OR Manifest OR Both	3.0
MIDlet-Description	Optional	JAD OR Manifest OR Both	1.0
MIDlet-Description-<locale>	Optional	JAD OR Manifest OR Both	3.0
MIDlet-Info-URL	Optional	JAD OR Manifest OR Both	1.0
MIDlet-<n>-<locale>	Optional	JAD OR Manifest OR Both	3.0
MIDlet-Update-URL	Optional	JAD OR Manifest OR Both	1.0
MIDlet-Data-Size	Optional	JAD OR Manifest OR Both	1.0
MIDlet-Minimum-Canvas-Size	Optional	JAD OR Manifest OR Both	3.0
MIDlet-Maximum-Canvas-Size	Optional	JAD OR Manifest OR Both	3.0
MIDlet-Push-<n>	Optional	JAD OR Manifest OR Both	2.0
MIDlet-Install-Notify	Optional	JAD OR Manifest OR Both	2.0
MIDlet-Required-IP-Version	Optional	JAD OR Manifest OR Both	2.0
MIDlet-<n>-Type	Optional	JAD OR Manifest OR Both	3.0
MIDlet-<n>-Category	Optional	JAD OR Manifest OR Both	3.0
MIDlet-<n>-UserDenied	Optional	JAD OR Manifest OR Both	3.0
MIDlet-UserDenied	Optional	JAD OR Manifest OR Both	3.0
MIDlet-Operator-Allowed	Optional	JAD OR Manifest OR Both	3.0
MIDlet-Dependency-<n>	Optional	JAD OR Manifest OR Both	3.0
MIDlet-Icon	Optional	JAD OR Manifest OR Both	1.0
MIDlet-Icon-<locale>	Optional	JAD OR Manifest OR Both	3.0
MIDlet-Scalable-Icon	Optional	JAD OR Manifest OR Both	3.0
MIDlet-Scalable-Icon-<locale>	Optional	JAD OR Manifest OR Both	3.0
MIDlet-<n>-Scalable-Icon	Optional	JAD OR Manifest OR Both	3.0
MIDlet-<n>-Scalable-Icon-<locale>	Optional	JAD OR Manifest OR Both	3.0
MIDlet-Font	Optional	JAD OR Manifest OR Both	3.0
MIDlet-Splash-Screen-Image	Optional	JAD OR Manifest OR Both	3.0
MIDlet-Event-Launch-<n>	Optional	JAD OR Manifest OR Both	3.0
MIDlet-Delete-Notify	Optional	JAD OR Manifest OR Both	2.0
MIDlet-Delete-Confirm	Optional	JAD OR Manifest OR Both	2.0
MIDlet-Delete-Confirm-<locale>	Optional	JAD OR Manifest OR Both	3.0
MIDlet-Persistent-Data-URL-<n>	Optional	JAD OR Manifest OR Both	3.0
MIDlet-Dependency-JAD-URL-<n>	Optional	JAD ONLY	3.0
MIDlet-Permission-<n>	Optional	JAD OR Manifest OR BOTH	3.0
MIDlet-Permission-Opt-<n>	Optional	JAD OR Manifest OR BOTH	3.0
MIDlet-Access-Auth-Type-<n>	Optional	JAD OR Manifest OR BOTH	3.0
MIDlet-Access-Auth-Cert-<n>	Optional	JAD OR Manifest OR BOTH	3.0
MIDlet-Permissions	Optional	JAD OR Manifest OR BOTH	2.0
MIDlet-Permissions-Opt	Optional	JAD OR Manifest OR BOTH	2.0
MIDlet-Dependency-Jar-SHA1-<n>	Optional	JAD OR Manifest OR BOTH	3.0
MIDlet-Certificate-<n>-<m>	Optional	JAD ONLY	2.0
MIDlet-Jar-RSA-SHA1-<n>	Optional	JAD ONLY	3.0
MIDlet-Jar-RSA-SHA1	Optional	JAD ONLY	2.0
MIDlet-Profile-Request;	Optional	JAD ONLY	3.0

LIBlet Attributes

Name	Status	Location	Since
LIBlet-Name	Mandatory	JAD AND Manifest	3.0
LIBlet-Vendor	Mandatory	JAD AND Manifest	3.0
LIBlet-Version	Mandatory	JAD AND Manifest	3.0
LIBlet-Jar-URL	Mandatory	JAD ONLY	3.0
LIBlet-Jar-Size	Mandatory	JAD ONLY	3.0
LIBlet-Jar-SHA1	Mandatory	JAD ONLY	3.0
LIBlet-Description	Optional	JAD AND Manifest	3.0
LIBlet-Description-<locale>	Optional	JAD AND Manifest	3.0
LIBlet-Icon	Optional	JAD AND Manifest	3.0
LIBlet-NonShared-Data-Size	Optional	JAD AND Manifest	3.0
LIBlet-Shared-Data-Size	Optional	JAD AND Manifest	3.0
LIBlet-Install-Notify	Optional	JAD AND Manifest	3.0
LIBlet-Delete-Notify	Optional	JAD AND Manifest	3.0
LIBlet-Persistent-Data-URL-<n>	Optional	JAD AND Manifest	3.0
LIBlet-Dependency-JAD-URL-<n>	Optional	JAD ONLY	3.0
LIBlet-Font	Optional	JAD AND Manifest	3.0
LIBlet-Permissions	Optional	JAD AND Manifest	3.0
LIBlet-Permissions-Opt;	Optional	JAD AND Manifest	3.0
LIBlet-Permission-<n>	Optional	JAD AND Manifest	3.0
LIBlet-Permission-Opt-<n>	Optional	JAD AND Manifest	3.0

---

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

What’s New In MIDP 3.0: Redux – The MIDlet Lifecycle

Original Post

Changes Since Proposed Final Draft

None

Issues

No changes, so the MIDlet lifecycle diagram remains, and there really is no positive way to put this, utter and total gibberish.

---

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

What’s New In MIDP 3.0: Redux – MIDletIdentity

Original Post

Changes Since Proposed Final Draft

None.

Issues

No change in the specification, so javax.microedition.midlet.MIDletIdentity still isn’t.

It is still, either

• the identity of a MIDlet Suite, or
• the partial identity of a MIDlet

and on the basis of the specification alone it is effectively impossible to tell which.

For added obfuscation the PDF version of the documentation omits the class description altogether.

As I said originally, this would have been incredibly easy to fix, why wasn’t it ?

---

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

What’s New In MIDP 3.0: Redux – javax.microedition.midlet.MIDlet

Original Post

Changes Since Proposed Final Draft

None

Issues

No changes in the specification means no changes in the issues.

The HTML version of the documentation for the method MIDlet.destroyApp(boolean) still looks like this.

and the PDF version still looks like this.

Go figure …

---

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