----- Original Message -----
From: "Tim Ellison" <[EMAIL PROTECTED]>
To: <[email protected]>
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;)
