Re: Rhino and applet issues
Qu0ll wrote:
"Lew" <noone@lewscanon.com> wrote in message
news:gssbto$ipa$2@news.albasani.net...
Qu0ll wrote:
Thinking about this, if it were possible to do this then the server
could feasibly compile any class it wanted, transmit the byte codes
to the applet and then have objects of that class instantiated in the
applet even when the applet initially knows nothing about that
class. Although that would obviously be extremely useful, I have
never heard that such a technique was feasible and therefore I assume
it can't be done.
I have never heard that such a technique was infeasible and therefore
I assume it can be done.
It's just standard class loading. How do you think applets obtain
bytecode from their servers?
What research did you do into this matter?
I have had a lot to do with applets over the last few years,
participated in the Sun applet forum and this forum, spoken to
colleagues and read many books on the subject but have never heard of
such a technique in practice. If feasible it would mean that you could
load entire modules of your applet on an as-required basis simply by
having the server transmit the class files when you need them.
Isn't that exactly what applets already do?
Whilst it is possible to dynamically load JARs to some extent, it is
problematic and for some reason the code that is loaded in this way
seems to execute a lot slower than code in the applet JAR. This has
been discussed a number of times.
Isn't it true that applets can load classes on demand from their server and
always have been able to do so?
Slow does not mean infeasible. I wonder about the claim of slow running,
though. Once code is loaded, how in the world would the JVM distinguish it to
run it slower? Is there a "recent immigrant" prejudice against newly
enfranchised bytecode?
Can you point us to any data on these matters? What you are saying
contradicts what I've heard about applets for the last ten-plus years.
--
Lew