Dynamically downloading code on KVM + MIDP

I came accross this interesting question on Sun's site, anyone have any comments/solutions? See the whole thing here: http://developer.java.sun.com/developer/qow/archive/109/index.html
"On a KVM + MIDP device I would like to do the following:
Have a JavaTM program (installed) which can download other Java classes and run them. Preferably the download would work over the wireless connection, but a wired installation is an option (albeit less desirable).
I went to talks at JavaOneSM which suggested on a KVM + MIDP device, the security manager would prevent the dynamic downloading and running of code. But I was new to all the different J2METM, KVM, MIDP, CLDC terms then, so I might have been confused. Can I do what I described above? Is there any way to come close to it?"
------------------
Best Regards,
Matt Midcap

I didn't realize this when I posted it, but this question was submitted to Sun by Mark Herschberg, one of our regulars here at the Ranch!
I think that since Sun posted this question as a "Question of the Week" it definately has validity (I thought that anyway). However, the answer is a little ambiguous. Please post any ideas or comments you might have to this question as it would be very helpful.
Want to add anything Mark?

------------------
Best Regards,
Matt Midcap
[This message has been edited by Matt Midcap (edited December 20, 2000).]

Dynamic downloading of classes is expressly forbidden, for security reasons. There's basically no way to do it because there's no way to install a class loader, which is what you'd have to do. All classes must be installed via the application management software that the device provides....
Eric

Hi Eric,
Thanks for the response. Where exactly in the spec does it talk about this? (I read it, but didn't see it explicitly mentioned.)
--Mark
hershey@vaultus.com

CLDC spec, section 5.2.2, reads as follows:
----
A JVM supporting CLDC does not support user-defined, Java-level class loaders (see JVMS �5.3, �2.17.2.) A JVM supporting CLDC shall have a built-in class loader that cannot be overridden, replaced, or reconfigured by the user. The actual class loading
implementation as well as any error conditions occurring during class loading are implementation-dependent. The elimination of user-defined class loaders is part of the security restrictions presented in Section 3.4.2.1, �Sandbox model.�
----
Remember that reading the MIDP spec isn't enough, you have to read both the MIDP and the CLDC specs to get the complete picture.

------------------
Eric Giguere
author of:
Java 2 Micro Edition : A Professional Developer's Guide
PalmTM Database Programming: The Complete Developer's Guide

Thanks for the rpely. I've looked through both specs. The snippet you posted from the CLDC spec just says you can't override the classloader. I am looking for a specific prohibition of any of the following:
1) MIDlets from being in more than one jar. While this is implied, I think think it is ever strictly required. The closest I've seen is 8.3 "A single JAR file contains all of the MIDlet's classes." However, the "MUST" word was not used here.
2) Having one MIDlet access classes in another MIDlet. This goes back to one, since it is not clear what all of a MIDlet's classes are. Is this all the classes it may ever use?
3) Runtime modification (possible off the device) of the jar file, specifically the midlet suite within the jar file. Even if I'm restricted by 1 and 2, I can still modify the jar, changing the definition of the MIDlet and it's included classes.
Are any of these prohibited? Where? I realize that it also not specified, and so implementations may not support such operations. But that's a different issue.
--Mark
hershey@vaultus.com

I don't have the specs in front of me, but the MIDP spec does define a MIDlet suite and states that only MIDlets within the same suite can interact. What defines a suite is the JAR manifest, which lists the MIDlets in the JAR, and from there you can see that one JAR defines one MIDlet suite.
As for off-device modification, that is definitely allowed, because it's one way you can do internationalization/localization -- i.e. examine the "Accept-XXX" headers from the HTTP request for a specific JAR file and make sure you send it back a JAR file for the given locale.
Eric

Matt:
I just posted an article on MIDP from Javaworld.
in case you haven't come across it...........
regds.

- satya