harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: JRE Lite
Date Sun, 02 Mar 2008 19:02:01 GMT
Your ideas sound quite reasonable to me.  I bet you are surprised about 
how much code is run just to invoke main(String[]) in a Java program, 
but I see your idea.

If you get it working we'd be delighted to create you a branch!

Regards,
Tim

Johnny Kewl wrote:
> TIm... you right too much in one topic so split...
> 
> You know when you discovering something, its not a science, its exploration, and I havent
even got
> the dev env going yet so still very low on the learning curve... but this is what I'm
thinking..
> 
> The basic JRE engine must be completely plugable... dynamic loading as you call it.
> At a quick glance the really big components are things like the JIT compiler,
> The fonts, all the "base" classes and the Unicode... I think its a unicode module.
> 
> Now here is what I'm thinking... the JRE gets stripped right down...
> So for example it looks for JIT but if it cant find it is doesnt crash.
> 
> Then instead of making users download... there is a Harmony site and on this site, are
all the fonts, all the classes... optional UTF modules etc etc.
> 
> The initial download is just a bootstrap... it can either be downloaded or included with
the software...
> If it needs a Comic font and UTF module... it fetches it, just enuf to get that application
running.
> So if the users runs a series of small applications they all very quick installs, but
the JRE is growing...
> So by the time the user installs a heavy application, the JRE will probably do it all.
> 
> In this scheme there is also no concept of versioning... if a class is loaded that needs
a new JRE lite module
> it will just happen.... the user is hassle free.
> 
> So there is still a installation server somewhere.... but the user doesnt even have to
know about it.
> That kind of dynamic loading means the JRE must fit together like a jigsaw puzzle..
> 
> For example the first run of an application may run without JIT, but the JRE's background
loader starts to pull
> it down... the next run will be fast....
> 
> The reason I asked about the interchangability is because if one has a small engine that
can get only what it has to... then that gets very interesting.
> For example, if a machine already has classpaths all over the place.... and a JavaLite
hits the machine.... it gets only what it needs, ie it gets
> a few core classes, maybe a few fonts, maybe its own multimedia engine.... but it does
not have to get anything else... it does not have
> to tell the users to setup xerces again... it see's wots on the machine already and uses
it... so theres the compatability side... the creativity
> side is that the Java application downloaded, may also be able to suck down a native
module, or custom class modules that do stuff like play
> Flash Video... now thats a JRE ;)
> 
> So... when I get going I'm going to break Harmony into tini weenie pieces.... ha ha.
> In this model, one does not even care about classes.... its just that engine that must
be able to discover and use whats there, or pull it from a installation server.
> Apps have the choice of using there own JRE Lite... or the systems JRE ;) but I think
if that JRELite is small enuf... it will go out with every application.
> Installers will use that... for sure, it makes life very easy.
> 
> ... so thats the idea... whether it will pan out, and the idea is possible, I dont know...
I cant see why not....
> 
> Some application will be unlucky... they internationalized the developer has gone mad
with XML, use JPA, JMX, JWhatever... and yes that
> apps JRE will have to build itself up to 10 megs before it will run... but a game using
JNI and doing its own drawing will probably run on a 500k JRE
> 
> Developers will very quickly learn what make the JRE take a big hit.... I think thats
a good thing, all the technology is there but depending on what
> system they targeting.... they will design accordingly, possibly using property files
instead of XML parsing...
> 
> So... once I get going thats my hobby for the next 4 months ;)
> If it works... you'll have to make another SVN fork;)

Mime
View raw message