----- Original Message -----
From: "Egor Pasko" <[EMAIL PROTECTED]>
To: <dev@harmony.apache.org>
Sent: Monday, March 03, 2008 10:12 AM
Subject: Re: JRE Lite
On the 0x3FC day of Apache Harmony Johnny Kewl wrote:
----- Original Message -----
From: "Tim Ellison" <[EMAIL PROTECTED]>
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
OK. So, the project is to make a tiny-self-downloadable-almost-java?
So, just to make sure, the TODO is like:
* divide JSE in small packages
* make an easily set-up server infrastructure for package hosting and
mirroring (torrent?)
* tweak classloader to download packages if they are not available on
the system
* make things work :)
More or less yes... but I dont think it will be easy, possibly not even
doable.
I think size and speed tradeoffs, and the intelligence required will make it
really
interesting... if we get there a lot of fun.
Java currently is a pain to deliver... can we take that away, and why hasnt
anyone done
that yet.... is wots on my mind.
or... you got a 50k application, but dont even bother trying to send it via
email, or contemplate
the user starting it froma browser.... because there is a big lump of
concrete attached to it.
Its like making a ferrari and towing a truck... more verbosity ;)
Sorry for my dummy question, I am just having major difficulties
reading through your verbosity level ;)
> 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;)
>
--
Egor Pasko
