Just An Application

December 12, 2009

What’s New In MIDP 3.0: Redux – RMS

Filed under: Java, JME, MIDP, MIDP3, MIDP3Issues, RMS — Tags: , , , , , , — Simon Lewis @ 12:16 pm

Original Post

Changes Since Proposed Final Draft

RecordStore.openRecordStore(String,boolean,int,boolean,String)

This new variant of the RecordStore.openRecordStore() method now throws a SecurityException

if the recordStoreName corresponds to an existing RecordStore in the current MIDlet Suite and the password does not match that of the existing RecordStore

This change addresses the issue descibed in my original post. It mandates that the implementation be capable of determining whether the supplied password is correct.

If this change had not been made it would have been necessary for each MIDlet using an encrypted RecordStore to try and determine whether the user supplied password was invalid in some ad-hoc manner.

  • Note

    The words

    in the current MIDlet Suite

    are superflous as this variant of the method can only be used to open RecordStores owned by the MIDlet Suite which contains the calling MIDlet.

RecordStore.openRecordStore(String,String,String,String)

This new variant of the RecordStore.openRecordStore() method now also throws a SecurityException

if the recordStoreName corresponds to an existing RecordStore in the current MIDlet Suite and the password does not match that of the existing RecordStore

This change is identical to the one above and is probably intended to have the same effect. Unfortunately in this context repeating the text verbatim is unnecessarily ambiguous.

Since this method can be used to open RecordStores owned by MIDlet Suites other than that containing the calling MIDlet, and RecordStores owned by LIBlets, presumably the behaviour is not actually intended to be confined to RecordStores

in the current MIDlet Suite

RecordStore.addRecord(byte[],int,int)

The documentation for this method now specifies that it throws an ArrayIndexOutOfBoundsException

if either offset or numBytes is negative, or if offset + numBytes > data.length

This change mandates that an implementation throw an ArrayIndexOutOfBoundsException in these circumstances, which certainly tightens up the specification.

This is never a bad thing, and if this was just one of a large number of such changes it would be unremarkable, but it is actually one of a very small number of changes to the proposed final draft, and arguably there are far more important issues that should have been addressed first.

RecordStore.addRecord(byte[],int,int,int)

The documentation for this method now specifies that it throws an ArrayIndexOutOfBoundsException

if either offset or numBytes is negative, or if offset + numBytes > data.length

See the comments made above.

RecordStore.getRecord(int,byte[],int)

The documentation for this method now specifies that it also throws an ArrayIndexOutOfBoundsException

if offset is negative or greater than or equal to the buffer length

See the comments made above.

RecordStore.setRecord(int,byte[],int,int)

The documentation for this method now specifies that it throws an ArrayIndexOutOfBoundsException

if either offset or numBytes is negative, or if offset + numBytes > data.length

See the comments made above.

RecordStore.setRecord(int,byte[],int,int,int)

The documentation for this method now specifies that it throws an ArrayIndexOutOfBoundsException

if either offset or numBytes is negative, or if offset + numBytes > data.length

See the comments made above.

Issues

RecordStore.exportRecordStore(OutputStream,String,String,String)

When exporting a RecordStore encrypted, the caller of this method still has no control over ths encryption parameters to be used. for example, key length.

The change to the variants of the RecordStore.openRecordStore() method which operate on an encrypted RecordStore, which requires the implementation to detect an invalid password, has not been made to this method. Hence, it is not possible for the caller to determine whether the password for an encrypted RecordStore which is to be exported is invalid, other than by calling one of those RecordStore.openRecordStore() methods first.

RecordStore.importRecordStore(InputStream,String,String)

It is still not possible for the caller of this method to determine whether the method failed because the supplied password was invalid or the supplied data was not in the correct format.

RecordStore.setMode(int,boolean)

The documentation for this method still says

This method can only be called if this recordstore is NOT open by a MIDlet in this suite or in a different MIDlet suite. If this recordStore is open by any MIDlet, an IllegalStateException will be thrown by the method.

Since this method is not static, a literal reading of the text implies that it is actually not possible to ever call it successfully, since to call it you have to have the RecordStore open.

If the intention is that the text should be interpreted as saying

This method can only be called if this recordstore is NOT open by any other MIDlet in this suite or in a different MIDlet suite. If this recordStore is open by any other MIDlet, an IllegalStateException will be thrown by the method.

then it should have been changed to say exactly that.

After all, this is intended to be a technical specification, not material for a case study in hermeneutics.


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

Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: