Damian Hamill wrote:
> Stefano Mazzocchi wrote:
>> Damian Hamill wrote:
>>>
>>> The problem is that before you start to run your applet you have to
>>> download and install everything that makes up the JRE including
>>> classes, programs and dlls that your applet will never use. A better
>>> solution would be to download and install the core JVM and the classes
>>> your applet uses only. Everything else should be downloaded on
>>> demand e.g.
>>>
>>>
>>> package javax.sql.rowset;
>>>
>>> public abstract class BaseRowSet implements Serializable, Cloneable {
>>>
>>> public static String classSourceURL =
>>> "http://www.mydistribution-server.com/cgi-bin/classServer.cgi";;
>>>
>>> // nothing else defined in this stub class. }
>>>
>>> The class loader finds a class with only the classSourceURL field and
>>> uses the URL in the field to download the real class passing the fully
>>> qualified class name as an argument. The class server can return a
>>> zip file with the named class and all the classes it depends on.
>>>
>>> If most/all of the classes were like this then the class library zip
>>> file would be very small. The same goes for the other programs and
>>> dlls, if they are not part of the JVM core and needed by every
>>> applet/application that runs then make them stubs that download the
>>> real thing when they are used the first time.
>>>
>>
>> And who's going to pay for that bandwidth?
> Although that is a problem it is a different problem and the answer may
> arise in due course (benefactors please step forward).
>
> When this JRE is ready for prime time how will it be distributed ?
>
> At the moment when I embed an Applet in a web page I specify
> http://java.sun.com/path... as the codebase. At some time in the future
> will I be able to change that to use the Harmony JRE and if so what will
> I change it to ?
>
> This proposal isn't limited to the JRE, it can work for userland classes
> as well so I would pay for the on-demand delivery of any classes that I
> create in my projects.
>
> As an Applet developer my goal is to embed my Applet in web pages and
> have them run with the minimum of fuss for the end user, otherwise I may
> be forced to switch to alternative technologies. If the innovation is
> done here in Harmony then it may be picked up by the other JRE vendors.
We are making modest steps in that direction within the Harmony classlib
code base by having modules with well-defined dependencies between them,
so, while the granularity may not be at the individual type level, you
can see how a given module can be loaded 'on demand' and drag in just
the pre-requisities for its implementation rather than all JSE.
If you see opportunities for reducing the module coupling further (i.e.
by reimplementing something that removes an import dependency on another
module) without undue cost to speed/complexity/size etc. then please
send it along. This is an area I'm very interested in.
> BTW the other thing that needs fixing is security. Java security was
> designed to stop malicious software writers from corrupting a users
> machine, the rest of us pay the price for this.
...and have benefited from this.
> Right now it means I
> can't do certain useful things in Applets unless the user modifies their
> security policy file. Asking them to edit c:/Program
> Files/Java/jre-{version}/lib/security.policy with notepad is not a
> serious option. So to do certain useful things like connect to other
> hosts I am forced to use JNLP. I would like to be able to ask the user
> for permission (via the security manager) to do things like connect to
> other hosts, disk access to a sandbox local directory etc.
Applets have a well-defined security model we wouldn't want to break,
but I understand what you are saying. Perhaps some other delivery
mechanism that can ask for broader permissions from the JRE either
through user interaction, or presenting a trusted signature, etc.
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
