On 3/5/08, Johnny Kewl <[EMAIL PROTECTED]> wrote: > > This is how I see it happening... I always talk from the point of view of > Windows users... they must be able to use it. > > BOOTSTRAP > ========== > > There is a small bootstrap program it is called JRELite... its a native app > probaby 80k > > When this is installed on a system it does a file association with "JreLite" > > THE JAVA APPLICATION > =================== > > To use this system a user will reaname their execuatable jar from MyApp.jar > to > MyApp.JreLite > > The above is all a user needs to know about and its how a user see's it. > > SCENARIO > ========= > > A programmer put their JreLite application on a web page, or emails it to a > freind or its on a flash stick... > ... anything > > The user clicks on it... > The system effectively runs JRELite MyApp.JreLite > > > INITIAL HIT > ======== > > The bootstrap see's there is no Java on tha machine... it gets the JVMLite > Engine... > Approx 3 meg HIT... > >
Do you expect any security issues here? How you are going to verify that dynamically downloaded bits are 'original' bits (i.e. not cracked) ? Thanks, Stepan. > STARTUP > ======== > > The Bootstrap place JVMLite in its special folder location... > Start... JVMLite -jar MyApp.JreLite > > > RUNNING BOOTSTRAP > ================== > > The application starts and it needs a swing... the JVM's resolver can > determine this... > It loads it. > > So the thing to really understand is that the application starts almost > immediately but its "still" > loading from the remote server, AS THE USER IS USING IT.... > > It feels like Java started in 20 seconds and remember this is only the first > (one time hit)... > After that programs start "instantly" > > Also think about this.... if a user never goes to a part of the application > that is not used... that never has to be loaded. > > Bottom Line > ========= > If we can strip the JRE down to somewhere around 3 megs.... make the classes > and fonts late binding... and put them on a deliver server. > JRELite exists... > > The JVMLite work... is mainly in bridging the resolver with the ability to > pull the require component down from the server. > Where ever that font engine is hiding... it too has to bridged with the > ability to pull a font down. > > The rest of the work... is in making the downloads fine grained... you let > the JVM pull the classes it needs... NOT the whole Jar. > So those Jars live on the server as a file structure... > > If the font needed is Gothic A, and that needs a Unicode DLL.... ONLY that > moves over the wire... > > Yes... oh boy... they all packed into humongeuos file now.... that has to be > fine grained on the server. > > This works so well... you going to be shocked at how efficient Java becomes ;) > > Harmony is not far from this already.... the packaging just has to change. > > For now... just that needs to be done... complex optimizations can come later. > > ... I think ;) >
