The CLDC (the base of which i-appli’s and Midlets are built upon) specification discusses these issues. Basically RMI is not supported, because that requires Reflection, which is not supported. Also every class that is successfully loaded into a handset must first have passed through a preverifier, which modifies the classfiles and is used to help offload work from the handset in verifying the integrity of a class. Nor can you make your own Class Loader. These are all done for reasons of making the JVM lightweight and keeping security in such a lightweight environment.
But there might be a way to load your own bytecode over the network, I can’t say I have tried. A good place to get some technical discussions on this is Sun’s KVM mailing list.
Zev
----------------------------
Date: Sun, 10 Feb 2002 19:48:11 +0900 (JST)
From: Curt Sampson <cjs@cynic.net>
Subject: Re: i-appli tweaking
On Thu, 7 Feb 2002, Michael Turner wrote:
> I must be getting old. I popped "iAppli" and "classLoader" into
> Google, and got ... something I translated not so terribly long ago:
>
> http://www.idiom.com/‾turner/JEvaHz/JEvaHz1339-1353.html
>
> ... in which it's implied that you CAN do this after all, but that
> compression will screw things up for you.
AFIK, that was just in an emulator.
In these phones, there just *has* to be the ability to build class
objects from bytecode; that's the basis of downloading and running
Java, after all! Why they make it completely inaccessable to the
user through any means but including the bytecode in a downloaded
jar file, I have no idea.
At any rate, you might be able to use RMI. Maybe. But I wouldn't
be surprised if even that didn't work, since again it's related to
moving class information between machines while the VM is running.
What a dumb thing to kill!
cjs
Received on Mon Feb 11 17:48:19 2002