How to get J2ME RecordStore functionality in J2SE Applet?

[Roar Lauritzsen]

The javax.microedition.rms.RecordStore provides a way for a MIDlet to
store data persistently and later retrieve it while still operating
without any privileges inside its "sandbox".

I have created an Applet that emulates a MIDlet, but I am unable to
implement RecordStore functionality for an Applet. I simply want to save
a small amount of data when the applet dies, and then when you restart
the Applet, it has access to the data and can update it.

Any ideas on how to achieve this? It is not especially important that
the data survives for all eternity, only that it is available if you
return to the applet within a reasonable time. I would rather not have
to sign the applet, and I would like to avoid putting a file in a
specific location, such as "C:\TEMP\myapplet.dat" or "/home/user/.myapplet".

I am aware of java.io.File.createTempFile(), and I like the the
semantics, if only the created temporary file could be reopened later.
But I suspect that an applet is not even allowed to do createTempFile()
with default privileges.

Regards,
Roar Lauritzsen

 

[Raymond DeCampo]

The javax.microedition.rms.RecordStore provides a way for a MIDlet to
store data persistently and later retrieve it while still operating
without any privileges inside its "sandbox".

I have created an Applet that emulates a MIDlet, but I am unable to
implement RecordStore functionality for an Applet. I simply want to save
a small amount of data when the applet dies, and then when you restart
the Applet, it has access to the data and can update it.

Try the java.util.prefs.Preferences API (available in 1.4 and beyond,
IIRC). I haven't ever examined if it is allowed within an applet, but I
would imagine it is.

HTH,
Ray

 

[Andrew Thompson]

Try the java.util.prefs.Preferences API (available in 1.4 and beyond,
IIRC). I haven't ever examined if it is allowed within an applet, but I
would imagine it is.

Not an unsigned applet..

<sscce>
import java.util.prefs.Preferences;

public class PreferencesApplet extends java.applet.Applet {
public void init() {
Preferences pref = Preferences.systemRoot();
}
}
</sscce>

AppletViewer ->
java.security.AccessControlException:
access denied (java.lang.RuntimePermission preferences)
at ....

..I simply want to save
a small amount of data when the applet dies, and then when you restart
the Applet, it has access to the data and can update it.

Unfortunately, there are reports that you cannot rely on
the applet stop()/destroy() methods being invoked by the
browser.

 

[Raymond DeCampo]

Not an unsigned applet..

<sscce>
import java.util.prefs.Preferences;

public class PreferencesApplet extends java.applet.Applet {
public void init() {
Preferences pref = Preferences.systemRoot();
}
}
</sscce>

AppletViewer ->
java.security.AccessControlException:
access denied (java.lang.RuntimePermission preferences)
at ....

I would point out that you attempted to access system level preferences
instead of user level preferences. However, the user level access
methods have the same security issue. Pity, it made so much sense.

Ray

 

[Andrew Thompson]

...
I would point out that you attempted to access system level preferences
instead of user level preferences.

Ehhh.. (shrugs) ..it was the first 'prefs' method I struck
that was static and got me a Preferences object (barring security).
Short and sweet.

..However, the user level access
methods have the same security issue. Pity, it made so much sense.

All is not lost, this applet could be signed.

Also, if my vague recollections serve me well, there
is also a webstart API that can store and recall prefs..

 

[JScoobyCed]

I have created an Applet that emulates a MIDlet, but I am unable to
implement RecordStore functionality for an Applet. I simply want to save
a small amount of data when the applet dies, and then when you restart
the Applet, it has access to the data and can update it.

What about storing a Cookie?

 

[Andrew Thompson]

What about storing a Cookie?

There are a couple of distinct parts to this problem.
1) Detecting when the applet dies.
2) Doing something about it (save the options).

If the developer can make a signed applet and expect a 1.4+
installation, Preferences would probably be the way to go.

Of course, there are still browsers out there without 1.4,
so in a JS enabled browser, the 'cookie alternative' may
well be the way to go. Though note that
a) some browsers that support Java might not support JS,
or might have JS disabled. I imagine the number of users
that allow Java but not JS to be *vanishingly* small, though
I have never been able to confirm it with any hard data.
I do not know of a browser that will recognize/act on an
<applet> element while not recognising the <script> element.
b) The cookie handling needs to be done in robust JS
(which excludes 90%+ of the badly hacked out script
available on the internet)

What was my point.. I'm sure, I had one.. Oh yeah!

But coming back to point 1) 'Detecting when the applet dies.'
*That* is the really tricky and unreliable aspect to this.
Unfortunately some browsers just do not invoke the relevant
applet methods that would allow either method to work
reliably.

<musing>
We have an advantage here.

The user *wants* their prefs to be stored, so we can
actively enlist their help. The developer might take
a different strategy to ensure 'prefs save' is invoked.
Here's one idea..

Pop-up a dialog at start-up.
"Be sure to click 'Save Prefs' before leaving to save your work!"

Also invoke the savePrefs() on applet.destroy() or whatever,
but this way it is possible to leave the ultimate responsibility
with the end user..

Just a thought.
</musing>

 

[Andrew Thompson]

..in a JS enabled browser, the 'cookie alternative' may
well be the way to go. Though note that
a) some browsers ... might not support JS, ....
b) The cookie handling needs to be done in robust JS ..

c) Many cookies die short, cruel deaths in this day and age.
- User settings have long allowed the end user to refuse cookies,
which is (seems to be) a much more common thing than disabling
Java/JS.
- Most pop-up blockers either interfere with, or prevent them.
(Google toolbar, IE SP 2..).
- (At least some) SpyWare software can target and destroy them as well.

 

[Darryl Pierce]

I am aware of java.io.File.createTempFile(), and I like the the
semantics, if only the created temporary file could be reopened later.
But I suspect that an applet is not even allowed to do createTempFile()
with default privileges.

Unless your applet is signed and has permission from the user, it cannot
create any file on the user's system. Do you have a digital signature
you can use to sign your applet?

 

[Darryl Pierce]

Try the java.util.prefs.Preferences API (available in 1.4 and beyond,
IIRC). I haven't ever examined if it is allowed within an applet, but I
would imagine it is.

Not without permission from the user.

 

[Roar Lauritzsen]

This works just swell! It is exactly what I need.

I don't care about such browsers, it's just a demo of an actual MIDLet
after all. It doesn't have to be bullet-proof

Why? What is wrong with this code?:

public int addRecord(byte[] data, int offset, int numBytes) {
try {
JSObject.getWindow(ral.CalcApplet.getCurrentApplet()).
eval("document.cookie='MIDPCalcState="+
encodeByteArray(data,offset,numBytes)+
"; expires=01-Jan-2020 GMT';");
} catch (Throwable e) {
}
return 0;
}

c) Many cookies die short, cruel deaths in this day and age.

If people don't want to set the cookie or exit the demo Applet in the
recommended fashion, they don't get to save the state of the demo. It's
up to them.

Anyway, thanks for the tips everybody,

-Roar Lauritzsen

 

[Andrew Thompson]

I don't care about such browsers, it's just a demo of an actual MIDLet
after all. It doesn't have to be bullet-proof

Why? What is wrong with this code?:

public int addRecord(byte[] data, int offset, int numBytes) {
try {
JSObject.getWindow(ral.CalcApplet.getCurrentApplet()).
eval("document.cookie='MIDPCalcState="+
encodeByteArray(data,offset,numBytes)+
"; expires=01-Jan-2020 GMT';");
} catch (Throwable e) {
}
return 0;
}

Their are some quirks in the ways that browsers interact
with LiveConnect. I was dealiing with one recently that
resulted in a Sun bug report - ..but was solved with a bit
of robust JS.

OTOH - if it works well enough for ..your users (make sure
you test it on a variety of JS enabled browsers) then I don't
see it matters that much, I would stick with what you have.

Glad you got it sorted!