The CLDC (the base of which i-appli$_at_!G(Js 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$_at_!G(Jt say I have tried. A good place to get some technical discussions on this is Sun$_at_!G(Js KVM mailing list.
Date: Sun, 10 Feb 2002 19:48:11 +0900 (JST)
From: Curt Sampson <cjs_at_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:
> ... 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!
Received on Mon Feb 11 17:48:19 2002