Visualizing JreLite

[Johnny Kewl <jo...@kewlstuff.co.za>]

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... 

 
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 ;)

Re: Visualizing JreLite

[Johnny Kewl <jo...@kewlstuff.co.za>]

----- Original Message ----- 
From: "Egor Pasko" <eg...@gmail.com>
To: <de...@harmony.apache.org>
Sent: Wednesday, March 05, 2008 11:31 PM
Subject: Re: Visualizing JreLite


>> There will be certified (well known servers), these are precoded into
>> the JRELite bootstrap....
>> If a third party wants to add a well known server, they need to ask.... 
>> (now
>> my
>> imagination is taking off ha ha) google can allocate
>> a specific site (I have a feeling they will be interested ;) for the 
>> JreLite
>> bootstrap... if someone wants to add a server, they have to
>> ask IGI (IntelGoogleIbm) for permission for it to be added.... this means
>> that if a server fails, the JreLiteBoot or JVM Resolver
>> can retry a few servers before giving up....
>> (now my imagination is flying) ... the servers contain PURE JAVA 
>> classes...
>> BUT, if an organization wants to add more API
>> to the server... say the ability for a programmer to program 911 calls 
>> into
>> their programs... then IGI has to approve them
>> .... an so the world is safe ;)
>
> they approve what? do "they" need to approve each binary release of
> each package? make sure there are no viruses, troyans, spyware?

Only if someone wanted to append to or change the API, would that become an 
issue.
Thats not so strange... phone Sun up and ask them to include your game Api 
in the JRE... you'll get the picture.

The guardians of the API, have to be there... but remember, these servers do 
NOT hold your application, they holding
the core API.... they have to be there, they (IGI) spend millions setting up 
servers, and so they get the priviledge of guarding the API..
So that someone cant make System.out... format a hardrive... so yes at that 
level they guarding everything...

But dont think the screwed up symbian model that makes people pay for 
applications, you know, if they dont sign, it doesnt run.
In this scheme... the application is free, and it can be ANYWHERE.... its 
*not* on the delivery servers, "java" is.

Except this will be J(V8 Turbo Charged)SE ;)

Re: Visualizing JreLite

[Alexei Fedotov <al...@gmail.com>]

I believe signing is a must for self-installing systems. From the
other side for a light Java hosting which might be Johnny's use case
signing is not as important as SSL.

On 06 Mar 2008 00:31:23 +0300, Egor Pasko <eg...@gmail.com> wrote:
> On the 0x3FE day of Apache Harmony Johnny Kewl wrote:
>  > > Do you expect any security issues here? How you are going to verify
>  > > that dynamically downloaded bits are 'original' bits (i.e. not
>  > > cracked) ?
>  >
>  > Software does not have to be signed... its not like an applet, its no more
>  > dangerous than a user deciding to download Harmony.
>
>  I disagree with you here. Security is still a matter of trust, right?
>  To install Harmony on my computer I need to trust the community, the
>  measure of trust might be different depending on what kind of machine
>  I would install it on.
>
>
>  > ie its a conscious click... besides, its someone elses application, the JRE
>  > cant do anything about that.
>  > If the primary supplier of the application wants to protect the user, they
>  > will make a SSL web page for instance.
>
>  no, SSL is damn slow, people will continue to prefer signing their packages
>
>
>  > As for the JVMLite pulling components from the server... the bootstrap can
>  > give the user the choice of SSL, or not.
>  > It must be a choice because if the server is used internal to a company,
>  > they dont need SSL.
>
>  there can be men-in-the-middle even inside companies
>
>
>  > There will be certified (well known servers), these are precoded into
>  > the JRELite bootstrap....
>  > If a third party wants to add a well known server, they need to ask.... (now
>  > my
>  > imagination is taking off ha ha) google can allocate
>  > a specific site (I have a feeling they will be interested ;) for the JreLite
>  > bootstrap... if someone wants to add a server, they have to
>  > ask IGI (IntelGoogleIbm) for permission for it to be added.... this means
>  > that if a server fails, the JreLiteBoot or JVM Resolver
>  > can retry a few servers before giving up....
>  > (now my imagination is flying) ... the servers contain PURE JAVA classes...
>  > BUT, if an organization wants to add more API
>  > to the server... say the ability for a programmer to program 911 calls into
>  > their programs... then IGI has to approve them
>  > .... an so the world is safe ;)
>
>  they approve what? do "they" need to approve each binary release of
>  each package? make sure there are no viruses, troyans, spyware?
>
>
>
>  > The application itself comes from whoever makes it and is placed on any
>  > medium... so what the servers are really serving
>  > is API, and so this must be safe.
>  >
>  > Uses I think must not be charged to use the servers, thats stupid... but
>  > there can be premuim services that come into
>  > play thru special API.... if you click, gimme a pitza in an app... you
>  > expect to pay ;)
>  >
>  > The signed sofware CA model is old and boring, please no... these servers
>  > fund themselves by selling
>  > API.... :)
>  > And then lets get the IT biz back to normal human biz models... they make
>  > extra money
>  > threw cool derivative services... that come from the API.
>  > Programmers can add a emergency help number to their code, if the user
>  > clicks it, a gorgeous
>  > blonde arrives at the door ;) etc etc
>  >
>  > .... and I'm sending IGI my consulting bill ;)
>  >
>  >
>  > > 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 ;)
>  > >>
>  > >
>  >
>  >
>
>  --
>  Egor Pasko
>
>



-- 
With best regards,
Alexei

Re: Visualizing JreLite

[Egor Pasko <eg...@gmail.com>]

On the 0x3FE day of Apache Harmony Johnny Kewl wrote:
> > Do you expect any security issues here? How you are going to verify
> > that dynamically downloaded bits are 'original' bits (i.e. not
> > cracked) ?
> 
> Software does not have to be signed... its not like an applet, its no more
> dangerous than a user deciding to download Harmony.

I disagree with you here. Security is still a matter of trust, right?
To install Harmony on my computer I need to trust the community, the
measure of trust might be different depending on what kind of machine
I would install it on.

> ie its a conscious click... besides, its someone elses application, the JRE
> cant do anything about that.
> If the primary supplier of the application wants to protect the user, they
> will make a SSL web page for instance.

no, SSL is damn slow, people will continue to prefer signing their packages

> As for the JVMLite pulling components from the server... the bootstrap can
> give the user the choice of SSL, or not.
> It must be a choice because if the server is used internal to a company,
> they dont need SSL.

there can be men-in-the-middle even inside companies

> There will be certified (well known servers), these are precoded into
> the JRELite bootstrap....
> If a third party wants to add a well known server, they need to ask.... (now
> my
> imagination is taking off ha ha) google can allocate
> a specific site (I have a feeling they will be interested ;) for the JreLite
> bootstrap... if someone wants to add a server, they have to
> ask IGI (IntelGoogleIbm) for permission for it to be added.... this means
> that if a server fails, the JreLiteBoot or JVM Resolver
> can retry a few servers before giving up....
> (now my imagination is flying) ... the servers contain PURE JAVA classes...
> BUT, if an organization wants to add more API
> to the server... say the ability for a programmer to program 911 calls into
> their programs... then IGI has to approve them
> .... an so the world is safe ;)

they approve what? do "they" need to approve each binary release of
each package? make sure there are no viruses, troyans, spyware?

> The application itself comes from whoever makes it and is placed on any
> medium... so what the servers are really serving
> is API, and so this must be safe.
> 
> Uses I think must not be charged to use the servers, thats stupid... but
> there can be premuim services that come into
> play thru special API.... if you click, gimme a pitza in an app... you
> expect to pay ;)
> 
> The signed sofware CA model is old and boring, please no... these servers
> fund themselves by selling
> API.... :)
> And then lets get the IT biz back to normal human biz models... they make
> extra money
> threw cool derivative services... that come from the API.
> Programmers can add a emergency help number to their code, if the user
> clicks it, a gorgeous
> blonde arrives at the door ;) etc etc
> 
> .... and I'm sending IGI my consulting bill ;)
> 
> 
> > 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 ;)
> >>
> >
> 
> 

-- 
Egor Pasko

Re: Visualizing JreLite

[Johnny Kewl <jo...@kewlstuff.co.za>]

----- Original Message ----- 
From: "Stepan Mishura" <st...@gmail.com>
To: <de...@harmony.apache.org>
Sent: Wednesday, March 05, 2008 7:28 AM
Subject: Re: Visualizing JreLite


> On 3/5/08, Johnny Kewl <jo...@kewlstuff.co.za> 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) ?

Software does not have to be signed... its not like an applet, its no more
dangerous than a user deciding to download Harmony.
ie its a conscious click... besides, its someone elses application, the JRE
cant do anything about that.
If the primary supplier of the application wants to protect the user, they
will make a SSL web page for instance.

As for the JVMLite pulling components from the server... the bootstrap can
give the user the choice of SSL, or not.
It must be a choice because if the server is used internal to a company,
they dont need SSL.

There will be certified (well known servers), these are precoded into
the JRELite bootstrap....
If a third party wants to add a well known server, they need to ask.... (now
my
imagination is taking off ha ha) google can allocate
a specific site (I have a feeling they will be interested ;) for the JreLite
bootstrap... if someone wants to add a server, they have to
ask IGI (IntelGoogleIbm) for permission for it to be added.... this means
that if a server fails, the JreLiteBoot or JVM Resolver
can retry a few servers before giving up....
(now my imagination is flying) ... the servers contain PURE JAVA classes...
BUT, if an organization wants to add more API
to the server... say the ability for a programmer to program 911 calls into
their programs... then IGI has to approve them
.... an so the world is safe ;)

The application itself comes from whoever makes it and is placed on any
medium... so what the servers are really serving
is API, and so this must be safe.

Uses I think must not be charged to use the servers, thats stupid... but
there can be premuim services that come into
play thru special API.... if you click, gimme a pitza in an app... you
expect to pay ;)

The signed sofware CA model is old and boring, please no... these servers
fund themselves by selling
API.... :)
And then lets get the IT biz back to normal human biz models... they make
extra money
threw cool derivative services... that come from the API.
Programmers can add a emergency help number to their code, if the user
clicks it, a gorgeous
blonde arrives at the door ;) etc etc

.... and I'm sending IGI my consulting bill ;)


> 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 ;)
>>
>

Re: Visualizing JreLite

[Stepan Mishura <st...@gmail.com>]

On 3/5/08, Johnny Kewl <jo...@kewlstuff.co.za> 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 ;)
>