harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johnny Kewl" <j...@kewlstuff.co.za>
Subject Re: JRE Lite
Date Mon, 03 Mar 2008 01:10:28 GMT

----- Original Message ----- 
From: "Tim Ellison" <t.p.ellison@gmail.com>
To: <dev@harmony.apache.org>
Sent: Sunday, March 02, 2008 9:02 PM
Subject: Re: JRE Lite


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

Heres to hoping it pans out, I do realize that this burger may be bigger 
than my bite ;)
Expect a lot of questions in the beginning, if it starts to work as a rough 
prototype
I'll yell.
You would also have to consider carefully who sponsors the project, what lic 
it
should have, and whether or not it should have a harmonious sounding name.
As you know most OS projects are marketing statements with very little 
unpaid community.
This one would have to be a real community driven effort, even at ownership 
level.... I think.
... worth thinking about I think ;)
I'm going to need all the help I can get... thanks

> 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